librelist archives

« back to archive

Alternative routing and app structure - drawbacks?

Alternative routing and app structure - drawbacks?

From:
Cliff Kachinske
Date:
2013-08-21 @ 09:19
I am just starting out with Flask. I would like to use it for a fairly
complex app that will probably end up with a dozen or so main object tables
and numerous relation tables.

One approach would be to create a monolithic views.py containing all the
application logic. That would work, but I'm not a fan of navigating in huge
files.

So I'm thinking of something like this.  Please tell me if I'm missing
something.

Thank you,
Cliff Kachinske

myapp/
    runserver.py
    myapp/
         views.py
         views/
         templates/
         ....


# views.py snippet
# CRUD for an auth_user table to manage user info
# I really like routing this way
@app.route('/user')
@app.route('/user/<action>')
@app.route('/user/<action>/<id>')
def auth_user(*args, **kwargs):
    from views import auth_user
    return auth_user.index(args, kwargs)

# auth_user.py snippet
from flask import request, abort

def index(*args, **kwargs):
    action_dict = args[1]
    myaction = action_dict.get('action', None)
    myid = action_dict.get('id', None)
    if myaction == 'add':
        return 'adding a user'
    elif myaction == 'edit':
        if not myid:
            abort(404)
        else:
            return 'editing user %s' %myid
    elif myaction == 'view':
        if not myid:
            abort(404)
        else:
            return 'viewing user %s' %myid
    elif myaction == 'add':
        return 'adding a user'
    else:
        return 'list of users'

This may not be the typical Flask approach, but to me it seems simple and
straightforward.

Thoughts, anyone?
Thank you
Cliff Kachinske

Re: [flask] Alternative routing and app structure - drawbacks?

From:
Joshua Ma
Date:
2013-08-21 @ 09:47
Hi Cliff,

You might want to check out Blueprints instead:
http://flask.pocoo.org/docs/blueprints/. They'll let you namespace things
without a giant chain of if/else statements. So your new structure might
look like what's below. Is there a reason why you like using one giant *
index* method? You'll see in the sample below I've split 'add', 'edit' into
separate views.

Cheers,
Josh

myapp/
    runserver.py
    myapp/
         views.py
         *user.py*
         templates/
         ....

# views.py snippet
from myapp.user import user
app.register_blueprint(user)

# users.py snippet
user = Blueprint('user', __name__, template_folder='templates')

@user.route('/add')
def add_user():
    return 'adding a user'

@user.route('/edit/<user_id>')
def edit_user(user_id):
    return 'editing a user'

[more views as desired]


On Wed, Aug 21, 2013 at 2:19 AM, Cliff Kachinske <cjkske@gmail.com> wrote:

> I am just starting out with Flask. I would like to use it for a fairly
> complex app that will probably end up with a dozen or so main object tables
> and numerous relation tables.
>
> One approach would be to create a monolithic views.py containing all the
> application logic. That would work, but I'm not a fan of navigating in huge
> files.
>
> So I'm thinking of something like this.  Please tell me if I'm missing
> something.
>
> Thank you,
> Cliff Kachinske
>
> myapp/
>     runserver.py
>     myapp/
>          views.py
>          views/
>          templates/
>          ....
>
>
> # views.py snippet
> # CRUD for an auth_user table to manage user info
> # I really like routing this way
> @app.route('/user')
> @app.route('/user/<action>')
> @app.route('/user/<action>/<id>')
> def auth_user(*args, **kwargs):
>     from views import auth_user
>     return auth_user.index(args, kwargs)
>
> # auth_user.py snippet
> from flask import request, abort
>
> def index(*args, **kwargs):
>     action_dict = args[1]
>     myaction = action_dict.get('action', None)
>     myid = action_dict.get('id', None)
>     if myaction == 'add':
>         return 'adding a user'
>     elif myaction == 'edit':
>         if not myid:
>             abort(404)
>         else:
>             return 'editing user %s' %myid
>     elif myaction == 'view':
>         if not myid:
>             abort(404)
>         else:
>             return 'viewing user %s' %myid
>     elif myaction == 'add':
>         return 'adding a user'
>     else:
>         return 'list of users'
>
> This may not be the typical Flask approach, but to me it seems simple and
> straightforward.
>
> Thoughts, anyone?
> Thank you
> Cliff Kachinske
>

Re: [flask] Alternative routing and app structure - drawbacks?

From:
Cliff Kachinske
Date:
2013-08-22 @ 01:21
Joshua,
I looks like bluprint is the way to go. Thanks for the pointer.

The big index function is just a placeholder.
Thank you.
Cliff Kachinske
On Aug 21, 2013 5:50 AM, "Joshua Ma" <josh@benchling.com> wrote:

> Hi Cliff,
>
> You might want to check out Blueprints instead:
> http://flask.pocoo.org/docs/blueprints/. They'll let you namespace things
> without a giant chain of if/else statements. So your new structure might
> look like what's below. Is there a reason why you like using one giant *
> index* method? You'll see in the sample below I've split 'add', 'edit'
> into separate views.
>
> Cheers,
> Josh
>
> myapp/
>     runserver.py
>     myapp/
>          views.py
>          *user.py*
>          templates/
>          ....
>
> # views.py snippet
> from myapp.user import user
> app.register_blueprint(user)
>
> # users.py snippet
> user = Blueprint('user', __name__, template_folder='templates')
>
> @user.route('/add')
> def add_user():
>     return 'adding a user'
>
> @user.route('/edit/<user_id>')
> def edit_user(user_id):
>     return 'editing a user'
>
> [more views as desired]
>
>
> On Wed, Aug 21, 2013 at 2:19 AM, Cliff Kachinske <cjkske@gmail.com> wrote:
>
>> I am just starting out with Flask. I would like to use it for a fairly
>> complex app that will probably end up with a dozen or so main object tables
>> and numerous relation tables.
>>
>> One approach would be to create a monolithic views.py containing all the
>> application logic. That would work, but I'm not a fan of navigating in huge
>> files.
>>
>> So I'm thinking of something like this.  Please tell me if I'm missing
>> something.
>>
>> Thank you,
>> Cliff Kachinske
>>
>> myapp/
>>     runserver.py
>>     myapp/
>>          views.py
>>          views/
>>          templates/
>>          ....
>>
>>
>> # views.py snippet
>> # CRUD for an auth_user table to manage user info
>> # I really like routing this way
>> @app.route('/user')
>> @app.route('/user/<action>')
>> @app.route('/user/<action>/<id>')
>> def auth_user(*args, **kwargs):
>>     from views import auth_user
>>     return auth_user.index(args, kwargs)
>>
>> # auth_user.py snippet
>> from flask import request, abort
>>
>> def index(*args, **kwargs):
>>     action_dict = args[1]
>>     myaction = action_dict.get('action', None)
>>     myid = action_dict.get('id', None)
>>     if myaction == 'add':
>>         return 'adding a user'
>>     elif myaction == 'edit':
>>         if not myid:
>>             abort(404)
>>         else:
>>             return 'editing user %s' %myid
>>     elif myaction == 'view':
>>         if not myid:
>>             abort(404)
>>         else:
>>             return 'viewing user %s' %myid
>>     elif myaction == 'add':
>>         return 'adding a user'
>>     else:
>>         return 'list of users'
>>
>> This may not be the typical Flask approach, but to me it seems simple and
>> straightforward.
>>
>> Thoughts, anyone?
>> Thank you
>> Cliff Kachinske
>>
>
>

Re: [flask] Alternative routing and app structure - drawbacks?

From:
greatghoul
Date:
2013-08-21 @ 09:57
I read an article last days,  How I Structure My Flask

Applications<http://mattupstate.com/python/2013/06/26/how-i-structure-my-flask-applications.html>
I think it's a good practice.


On Wed, Aug 21, 2013 at 5:47 PM, Joshua Ma <josh@benchling.com> wrote:

> Hi Cliff,
>
> You might want to check out Blueprints instead:
> http://flask.pocoo.org/docs/blueprints/. They'll let you namespace things
> without a giant chain of if/else statements. So your new structure might
> look like what's below. Is there a reason why you like using one giant *
> index* method? You'll see in the sample below I've split 'add', 'edit'
> into separate views.
>
> Cheers,
> Josh
>
> myapp/
>     runserver.py
>     myapp/
>          views.py
>          *user.py*
>          templates/
>          ....
>
> # views.py snippet
> from myapp.user import user
> app.register_blueprint(user)
>
> # users.py snippet
> user = Blueprint('user', __name__, template_folder='templates')
>
> @user.route('/add')
> def add_user():
>     return 'adding a user'
>
> @user.route('/edit/<user_id>')
> def edit_user(user_id):
>     return 'editing a user'
>
> [more views as desired]
>
>
> On Wed, Aug 21, 2013 at 2:19 AM, Cliff Kachinske <cjkske@gmail.com> wrote:
>
>> I am just starting out with Flask. I would like to use it for a fairly
>> complex app that will probably end up with a dozen or so main object tables
>> and numerous relation tables.
>>
>> One approach would be to create a monolithic views.py containing all the
>> application logic. That would work, but I'm not a fan of navigating in huge
>> files.
>>
>> So I'm thinking of something like this.  Please tell me if I'm missing
>> something.
>>
>> Thank you,
>> Cliff Kachinske
>>
>> myapp/
>>     runserver.py
>>     myapp/
>>          views.py
>>          views/
>>          templates/
>>          ....
>>
>>
>> # views.py snippet
>> # CRUD for an auth_user table to manage user info
>> # I really like routing this way
>> @app.route('/user')
>> @app.route('/user/<action>')
>> @app.route('/user/<action>/<id>')
>> def auth_user(*args, **kwargs):
>>     from views import auth_user
>>     return auth_user.index(args, kwargs)
>>
>> # auth_user.py snippet
>> from flask import request, abort
>>
>> def index(*args, **kwargs):
>>     action_dict = args[1]
>>     myaction = action_dict.get('action', None)
>>     myid = action_dict.get('id', None)
>>     if myaction == 'add':
>>         return 'adding a user'
>>     elif myaction == 'edit':
>>         if not myid:
>>             abort(404)
>>         else:
>>             return 'editing user %s' %myid
>>     elif myaction == 'view':
>>         if not myid:
>>             abort(404)
>>         else:
>>             return 'viewing user %s' %myid
>>     elif myaction == 'add':
>>         return 'adding a user'
>>     else:
>>         return 'list of users'
>>
>> This may not be the typical Flask approach, but to me it seems simple and
>> straightforward.
>>
>> Thoughts, anyone?
>> Thank you
>> Cliff Kachinske
>>
>
>


-- 
 *greatghoul <http://www.g2w.me> - Ask and Learn!*

Re: [flask] Alternative routing and app structure - drawbacks?

From:
Cliff Kachinske
Date:
2013-08-22 @ 01:23
That's a great blog post. Thank you.

Cliff Kachinske
On Aug 21, 2013 6:00 AM, "greatghoul" <greatghoul@gmail.com> wrote:

> I read an article last days,  How I Structure My Flask 
Applications<http://mattupstate.com/python/2013/06/26/how-i-structure-my-flask-applications.html>
> I think it's a good practice.
>
>
> On Wed, Aug 21, 2013 at 5:47 PM, Joshua Ma <josh@benchling.com> wrote:
>
>> Hi Cliff,
>>
>> You might want to check out Blueprints instead:
>> http://flask.pocoo.org/docs/blueprints/. They'll let you namespace
>> things without a giant chain of if/else statements. So your new structure
>> might look like what's below. Is there a reason why you like using one
>> giant *index* method? You'll see in the sample below I've split 'add',
>> 'edit' into separate views.
>>
>> Cheers,
>> Josh
>>
>> myapp/
>>     runserver.py
>>     myapp/
>>          views.py
>>          *user.py*
>>          templates/
>>          ....
>>
>> # views.py snippet
>> from myapp.user import user
>> app.register_blueprint(user)
>>
>> # users.py snippet
>> user = Blueprint('user', __name__, template_folder='templates')
>>
>> @user.route('/add')
>> def add_user():
>>     return 'adding a user'
>>
>> @user.route('/edit/<user_id>')
>> def edit_user(user_id):
>>     return 'editing a user'
>>
>> [more views as desired]
>>
>>
>> On Wed, Aug 21, 2013 at 2:19 AM, Cliff Kachinske <cjkske@gmail.com>wrote:
>>
>>> I am just starting out with Flask. I would like to use it for a fairly
>>> complex app that will probably end up with a dozen or so main object tables
>>> and numerous relation tables.
>>>
>>> One approach would be to create a monolithic views.py containing all the
>>> application logic. That would work, but I'm not a fan of navigating in huge
>>> files.
>>>
>>> So I'm thinking of something like this.  Please tell me if I'm missing
>>> something.
>>>
>>> Thank you,
>>> Cliff Kachinske
>>>
>>> myapp/
>>>     runserver.py
>>>     myapp/
>>>          views.py
>>>          views/
>>>          templates/
>>>          ....
>>>
>>>
>>> # views.py snippet
>>> # CRUD for an auth_user table to manage user info
>>> # I really like routing this way
>>> @app.route('/user')
>>> @app.route('/user/<action>')
>>> @app.route('/user/<action>/<id>')
>>> def auth_user(*args, **kwargs):
>>>     from views import auth_user
>>>     return auth_user.index(args, kwargs)
>>>
>>> # auth_user.py snippet
>>> from flask import request, abort
>>>
>>> def index(*args, **kwargs):
>>>     action_dict = args[1]
>>>     myaction = action_dict.get('action', None)
>>>     myid = action_dict.get('id', None)
>>>     if myaction == 'add':
>>>         return 'adding a user'
>>>     elif myaction == 'edit':
>>>         if not myid:
>>>             abort(404)
>>>         else:
>>>             return 'editing user %s' %myid
>>>     elif myaction == 'view':
>>>         if not myid:
>>>             abort(404)
>>>         else:
>>>             return 'viewing user %s' %myid
>>>     elif myaction == 'add':
>>>         return 'adding a user'
>>>     else:
>>>         return 'list of users'
>>>
>>> This may not be the typical Flask approach, but to me it seems simple
>>> and straightforward.
>>>
>>> Thoughts, anyone?
>>> Thank you
>>> Cliff Kachinske
>>>
>>
>>
>
>
> --
>  *greatghoul <http://www.g2w.me> - Ask and Learn!*
>