librelist archives

Re: [flask] Question on MVC/"Module" Pattern

From:

Michael Chambliss

Date:

2010-11-04 @ 23:35

Ok, looks like your example runs into the same issue I was working around -
basically, there's no simple way around the circular dependency between the
Flask application and the modules.  This was touched on in the documentation
here: http://flask.pocoo.org/docs/patterns/packages/#simple-packages

Using your code, in order to reference the Flask 'app' in your modules, I
had to make 'app' global (IE, removed the create_app function) and imported
skeleton<-->modules.

I'm guessing everything is in the Flask class to keep things simple and
accessible, but it could be interesting to pull out the various url, config,
logging, etc methods to better expose those in a more modular application
without the circular dependency.

Again, if I'm missing something, please let me know :)

Thanks!
-Mike

On Thu, Nov 4, 2010 at 3:33 PM, Michael Chambliss <
mailing-lists@mchambliss.com> wrote:

> Thanks, Anton.  I'll work with your example to see if I can wedge in my
> current approach.
>
> Mike
>
>
> On Thu, Nov 4, 2010 at 2:40 PM, Anton Khodakivskiy <
> akhodakivskiy@gmail.com> wrote:
>
>> Flask allows to separate parts of your application into modules. I think
>> it's a good idea to associate MVC controllers with corresponding Flask
>> modules. Then there are lots of ways to structure the application. I prefer
>> to separate modules and all the associated files (templates, models, queries
>> in your case) into separate directories, Django style. Take a look at my
>> skeleton application if you are interested:
>>
>> https://github.com/akhodakivskiy/flask/tree/master/skeleton/
>>
>> But it really depends on the size of your application. If it is something
>> really small, then you are probably better of to stick to the layout
>> presented in Flask tutorial.
>>
>> Thanks
>> Anton
>>
>> On Nov 4, 2010, at 10:21 PM, Michael Chambliss wrote:
>>
>>
>> First, a little background.  My application is currently structured as
>> follows:
>>
>> /webapp
>>   runserver.py
>>   /webapp
>>     /controllers  -- Managing routes/controller logic
>>     /database     -- SQLAlchemy related wrappers
>>      /model        -- Models
>>     /queries      -- Queries (plain .sql files)
>>     /static
>>      /templates    -- Synonymous with "view"
>>     __init__.py
>>
>> The bits of code relevant to my question follow:
>>
>> ::runserver.py::
>> from webapp import app
>> from webapp.controllers import employee_controller
>>
>> app.run(debug=app.config['DEBUG'],host='0.0.0.0')
>> ::end runserver.py::
>>
>>
>> ::/webapp/webapp/__init__.py::
>> from flask import Flask, Markup, request, g
>> from database import connection
>> import config
>>
>> app = Flask(__name__)
>> app.config.from_object(config)
>> db = connection.Connection(app.config['DATABASE'])
>>
>> @app.before_request
>> def start_session():
>>     g.session = db.get_session()
>>
>> @app.after_request
>> def shutdown_session(response):
>>     g.session.close()
>>     return response
>>
>> ::end /webapp/webapp/__init__.py::
>>
>>
>> ::../controllers/employee_controller.py::
>> from flask import g, render_template, Module
>> from webapp.model import employee
>> from webapp import app
>>
>> @app.route("/")
>> def index():
>>     return "Index Page"
>>
>> @app.route("/print_employees")
>> def show_employees(employee_id=None):
>>     with app.open_resource('./queries/select_all_employee.sql') as q:
>>         employees =
>> g.session.query(employee.Employee).from_statement(q.read())
>>     return render_template("test_template.html",employees=employees)
>> ::end ../controllers/employee_controller.py::
>>
>>
>> I was initially trying to follow the "Working with Modules" approach (
>> http://flask.pocoo.org/docs/patterns/packages/#working-with-modules) but
>> had a number of problems with this.  My biggest issue was with mixing view
>> and controller concerns within the "view" modules because they were now my
>> entry point for functionality, hence the current approach.  My other issue
>> is with circular dependencies, as I'd like access to "app" throughout my
>> controllers.  This is fine the way I've implemented it, but I'm now leaving
>> the "Module" functionality on the table.
>>
>> Is there a better way to structure this, such that I'm not opting out of
>> framework functionality but also not causing dependency issues?
>>
>> Thanks!
>> -Mike
>>
>>
>

Hi,

On 2010-11-05 12:35 AM, Michael Chambliss wrote:
> Ok, looks like your example runs into the same issue I was working
> around - basically, there's no simple way around the circular dependency
> between the Flask application and the modules.
At compile time / import time one has to add.  If you only need 
references to the application at runtime you can use current_app.  This 
- I have to add - is not a Flask limitation, that's pretty much how 
Python works.  I do acknowledge that it's ugly and I plan on improving 
on that for future Flask versions, but I don't know yet how I can do 
that with preserving current behavior.

To be honest, I don't think it's much of a deal because once you know 
how the Python import system works there are nice ways to deal with 
circular imports.

Regards,
Armin

<facepalm> - current_app is the answer.  My mistake, I didn't realize flask
provided this proxy.  I've been staring at this too long and read
danjac354's response as referring to Anton's "create_app" function.

In any case, I think if I implement Anton's module loader approach and
utilize the current_app reference I'll be in good shape.  All I'm really
interested in from the controllers are the app helper methods as Module
should take care of my routes.

Thanks for the assistance, and thanks for your work on the framework, Armin!

Mike

On Thu, Nov 4, 2010 at 6:54 PM, Armin Ronacher
<armin.ronacher@active-4.com>wrote:

> Hi,
>
> On 2010-11-05 12:35 AM, Michael Chambliss wrote:
> > Ok, looks like your example runs into the same issue I was working
> > around - basically, there's no simple way around the circular dependency
> > between the Flask application and the modules.
> At compile time / import time one has to add.  If you only need
> references to the application at runtime you can use current_app.  This
> - I have to add - is not a Flask limitation, that's pretty much how
> Python works.  I do acknowledge that it's ugly and I plan on improving
> on that for future Flask versions, but I don't know yet how I can do
> that with preserving current behavior.
>
> To be honest, I don't think it's much of a deal because once you know
> how the Python import system works there are nice ways to deal with
> circular imports.
>
> Regards,
> Armin
>

Hey Michael, since your starting point of view is separation of
concerns, which is something a lot of us take into consideration, I
would suggest a couple of additional things.

Focusing on separation of concerns on a function level. Keeping code
inside the functions at one level of abstraction only (e.g.
show_employees that you show is doing too many things). When that is
achieved, the module organization will build itself in a natural way
and everything will get into their respective places as in the
original package/module structure you showed. This will minimize the
circular imports issue naturally as well.

Additionally keeping functions short and doing one thing only. This
way the code will be easily read and tested.

Thanks,
Zahari

On Fri, Nov 5, 2010 at 3:26 AM, Michael Chambliss
<mailing-lists@mchambliss.com> wrote:
> <facepalm> - current_app is the answer.  My mistake, I didn't realize flask
> provided this proxy.  I've been staring at this too long and read
> danjac354's response as referring to Anton's "create_app" function.
> In any case, I think if I implement Anton's module loader approach and
> utilize the current_app reference I'll be in good shape.  All I'm really
> interested in from the controllers are the app helper methods as Module
> should take care of my routes.
> Thanks for the assistance, and thanks for your work on the framework, Armin!
> Mike
>
> On Thu, Nov 4, 2010 at 6:54 PM, Armin Ronacher <armin.ronacher@active-4.com>
> wrote:
>>
>> Hi,
>>
>> On 2010-11-05 12:35 AM, Michael Chambliss wrote:
>> > Ok, looks like your example runs into the same issue I was working
>> > around - basically, there's no simple way around the circular dependency
>> > between the Flask application and the modules.
>> At compile time / import time one has to add.  If you only need
>> references to the application at runtime you can use current_app.  This
>> - I have to add - is not a Flask limitation, that's pretty much how
>> Python works.  I do acknowledge that it's ugly and I plan on improving
>> on that for future Flask versions, but I don't know yet how I can do
>> that with preserving current behavior.
>>
>> To be honest, I don't think it's much of a deal because once you know
>> how the Python import system works there are nice ways to deal with
>> circular imports.
>>
>> Regards,
>> Armin
>
>

Thanks, Zahari, I appreciate that kind of advice.  I'll definitely split out
the data fetching logic from the rendering logic as I refactor things into
the Module approach.

Thanks!
Mike

On Fri, Nov 5, 2010 at 2:20 AM, Zahari Petkov <zarchaoz@gmail.com> wrote:

> Hey Michael, since your starting point of view is separation of
> concerns, which is something a lot of us take into consideration, I
> would suggest a couple of additional things.
>
> Focusing on separation of concerns on a function level. Keeping code
> inside the functions at one level of abstraction only (e.g.
> show_employees that you show is doing too many things). When that is
> achieved, the module organization will build itself in a natural way
> and everything will get into their respective places as in the
> original package/module structure you showed. This will minimize the
> circular imports issue naturally as well.
>
> Additionally keeping functions short and doing one thing only. This
> way the code will be easily read and tested.
>
> Thanks,
> Zahari
>
> On Fri, Nov 5, 2010 at 3:26 AM, Michael Chambliss
> <mailing-lists@mchambliss.com> wrote:
> > <facepalm> - current_app is the answer.  My mistake, I didn't realize
> flask
> > provided this proxy.  I've been staring at this too long and read
> > danjac354's response as referring to Anton's "create_app" function.
> > In any case, I think if I implement Anton's module loader approach and
> > utilize the current_app reference I'll be in good shape.  All I'm really
> > interested in from the controllers are the app helper methods as Module
> > should take care of my routes.
> > Thanks for the assistance, and thanks for your work on the framework,
> Armin!
> > Mike
> >
> > On Thu, Nov 4, 2010 at 6:54 PM, Armin Ronacher <
> armin.ronacher@active-4.com>
> > wrote:
> >>
> >> Hi,
> >>
> >> On 2010-11-05 12:35 AM, Michael Chambliss wrote:
> >> > Ok, looks like your example runs into the same issue I was working
> >> > around - basically, there's no simple way around the circular
> dependency
> >> > between the Flask application and the modules.
> >> At compile time / import time one has to add.  If you only need
> >> references to the application at runtime you can use current_app.  This
> >> - I have to add - is not a Flask limitation, that's pretty much how
> >> Python works.  I do acknowledge that it's ugly and I plan on improving
> >> on that for future Flask versions, but I don't know yet how I can do
> >> that with preserving current behavior.
> >>
> >> To be honest, I don't think it's much of a deal because once you know
> >> how the Python import system works there are nice ways to deal with
> >> circular imports.
> >>
> >> Regards,
> >> Armin
> >
> >
>



-- 
Michael Chambliss
email@mchambliss.com

Why not just access the current_app instead ?

On 4 November 2010 23:35, Michael Chambliss
<mailing-lists@mchambliss.com> wrote:
> Ok, looks like your example runs into the same issue I was working around -
> basically, there's no simple way around the circular dependency between the
> Flask application and the modules.  This was touched on in the documentation
> here: http://flask.pocoo.org/docs/patterns/packages/#simple-packages
> Using your code, in order to reference the Flask 'app' in your modules, I
> had to make 'app' global (IE, removed the create_app function) and imported
> skeleton<-->modules.
> I'm guessing everything is in the Flask class to keep things simple and
> accessible, but it could be interesting to pull out the various url, config,
> logging, etc methods to better expose those in a more modular application
> without the circular dependency.
> Again, if I'm missing something, please let me know :)
> Thanks!
> -Mike
> On Thu, Nov 4, 2010 at 3:33 PM, Michael Chambliss
> <mailing-lists@mchambliss.com> wrote:
>>
>> Thanks, Anton.  I'll work with your example to see if I can wedge in my
>> current approach.
>>
>> Mike
>>
>> On Thu, Nov 4, 2010 at 2:40 PM, Anton Khodakivskiy
>> <akhodakivskiy@gmail.com> wrote:
>>>
>>> Flask allows to separate parts of your application into modules. I think
>>> it's a good idea to associate MVC controllers with corresponding Flask
>>> modules. Then there are lots of ways to structure the application. I prefer
>>> to separate modules and all the associated files (templates, models, queries
>>> in your case) into separate directories, Django style. Take a look at my
>>> skeleton application if you are interested:
>>> https://github.com/akhodakivskiy/flask/tree/master/skeleton/
>>> But it really depends on the size of your application. If it is something
>>> really small, then you are probably better of to stick to the layout
>>> presented in Flask tutorial.
>>> Thanks
>>> Anton
>>> On Nov 4, 2010, at 10:21 PM, Michael Chambliss wrote:
>>>
>>> First, a little background.  My application is currently structured as
>>> follows:
>>> /webapp
>>>   runserver.py
>>>   /webapp
>>>     /controllers  -- Managing routes/controller logic
>>>     /database     -- SQLAlchemy related wrappers
>>>     /model        -- Models
>>>     /queries      -- Queries (plain .sql files)
>>>     /static
>>>     /templates    -- Synonymous with "view"
>>>     __init__.py
>>>
>>> The bits of code relevant to my question follow:
>>> ::runserver.py::
>>> from webapp import app
>>> from webapp.controllers import employee_controller
>>>
>>> app.run(debug=app.config['DEBUG'],host='0.0.0.0')
>>> ::end runserver.py::
>>>
>>> ::/webapp/webapp/__init__.py::
>>> from flask import Flask, Markup, request, g
>>> from database import connection
>>> import config
>>> app = Flask(__name__)
>>> app.config.from_object(config)
>>> db = connection.Connection(app.config['DATABASE'])
>>> @app.before_request
>>> def start_session():
>>>     g.session = db.get_session()
>>> @app.after_request
>>> def shutdown_session(response):
>>>     g.session.close()
>>>     return response
>>> ::end /webapp/webapp/__init__.py::
>>>
>>> ::../controllers/employee_controller.py::
>>> from flask import g, render_template, Module
>>> from webapp.model import employee
>>> from webapp import app
>>> @app.route("/")
>>> def index():
>>>     return "Index Page"
>>> @app.route("/print_employees")
>>> def show_employees(employee_id=None):
>>>     with app.open_resource('./queries/select_all_employee.sql') as q:
>>>         employees =
>>> g.session.query(employee.Employee).from_statement(q.read())
>>>     return render_template("test_template.html",employees=employees)
>>> ::end ../controllers/employee_controller.py::
>>>
>>> I was initially trying to follow the "Working with Modules" approach
>>> (http://flask.pocoo.org/docs/patterns/packages/#working-with-modules) but
>>> had a number of problems with this.  My biggest issue was with mixing view
>>> and controller concerns within the "view" modules because they were now my
>>> entry point for functionality, hence the current approach.  My other issue
>>> is with circular dependencies, as I'd like access to "app" throughout my
>>> controllers.  This is fine the way I've implemented it, but I'm now leaving
>>> the "Module" functionality on the table.
>>> Is there a better way to structure this, such that I'm not opting out of
>>> framework functionality but also not causing dependency issues?
>>> Thanks!
>>> -Mike
>
>

Sorry, yes, that would have produced the same result - I just had the global
on my brain from my previous experimentation.

Thanks,
Mike

On Thu, Nov 4, 2010 at 5:37 PM, danjac354@gmail.com <danjac354@gmail.com>wrote:

> Why not just access the current_app instead ?
>
> On 4 November 2010 23:35, Michael Chambliss
> <mailing-lists@mchambliss.com> wrote:
> > Ok, looks like your example runs into the same issue I was working around
> -
> > basically, there's no simple way around the circular dependency between
> the
> > Flask application and the modules.  This was touched on in the
> documentation
> > here: http://flask.pocoo.org/docs/patterns/packages/#simple-packages
> > Using your code, in order to reference the Flask 'app' in your modules, I
> > had to make 'app' global (IE, removed the create_app function) and
> imported
> > skeleton<-->modules.
> > I'm guessing everything is in the Flask class to keep things simple and
> > accessible, but it could be interesting to pull out the various url,
> config,
> > logging, etc methods to better expose those in a more modular application
> > without the circular dependency.
> > Again, if I'm missing something, please let me know :)
> > Thanks!
> > -Mike
> > On Thu, Nov 4, 2010 at 3:33 PM, Michael Chambliss
> > <mailing-lists@mchambliss.com> wrote:
> >>
> >> Thanks, Anton.  I'll work with your example to see if I can wedge in my
> >> current approach.
> >>
> >> Mike
> >>
> >> On Thu, Nov 4, 2010 at 2:40 PM, Anton Khodakivskiy
> >> <akhodakivskiy@gmail.com> wrote:
> >>>
> >>> Flask allows to separate parts of your application into modules. I
> think
> >>> it's a good idea to associate MVC controllers with corresponding Flask
> >>> modules. Then there are lots of ways to structure the application. I
> prefer
> >>> to separate modules and all the associated files (templates, models,
> queries
> >>> in your case) into separate directories, Django style. Take a look at
> my
> >>> skeleton application if you are interested:
> >>> https://github.com/akhodakivskiy/flask/tree/master/skeleton/
> >>> But it really depends on the size of your application. If it is
> something
> >>> really small, then you are probably better of to stick to the layout
> >>> presented in Flask tutorial.
> >>> Thanks
> >>> Anton
> >>> On Nov 4, 2010, at 10:21 PM, Michael Chambliss wrote:
> >>>
> >>> First, a little background.  My application is currently structured as
> >>> follows:
> >>> /webapp
> >>>   runserver.py
> >>>   /webapp
> >>>     /controllers  -- Managing routes/controller logic
> >>>     /database     -- SQLAlchemy related wrappers
> >>>     /model        -- Models
> >>>     /queries      -- Queries (plain .sql files)
> >>>     /static
> >>>     /templates    -- Synonymous with "view"
> >>>     __init__.py
> >>>
> >>> The bits of code relevant to my question follow:
> >>> ::runserver.py::
> >>> from webapp import app
> >>> from webapp.controllers import employee_controller
> >>>
> >>> app.run(debug=app.config['DEBUG'],host='0.0.0.0')
> >>> ::end runserver.py::
> >>>
> >>> ::/webapp/webapp/__init__.py::
> >>> from flask import Flask, Markup, request, g
> >>> from database import connection
> >>> import config
> >>> app = Flask(__name__)
> >>> app.config.from_object(config)
> >>> db = connection.Connection(app.config['DATABASE'])
> >>> @app.before_request
> >>> def start_session():
> >>>     g.session = db.get_session()
> >>> @app.after_request
> >>> def shutdown_session(response):
> >>>     g.session.close()
> >>>     return response
> >>> ::end /webapp/webapp/__init__.py::
> >>>
> >>> ::../controllers/employee_controller.py::
> >>> from flask import g, render_template, Module
> >>> from webapp.model import employee
> >>> from webapp import app
> >>> @app.route("/")
> >>> def index():
> >>>     return "Index Page"
> >>> @app.route("/print_employees")
> >>> def show_employees(employee_id=None):
> >>>     with app.open_resource('./queries/select_all_employee.sql') as q:
> >>>         employees =
> >>> g.session.query(employee.Employee).from_statement(q.read())
> >>>     return render_template("test_template.html",employees=employees)
> >>> ::end ../controllers/employee_controller.py::
> >>>
> >>> I was initially trying to follow the "Working with Modules" approach
> >>> (http://flask.pocoo.org/docs/patterns/packages/#working-with-modules)
> but
> >>> had a number of problems with this.  My biggest issue was with mixing
> view
> >>> and controller concerns within the "view" modules because they were now
> my
> >>> entry point for functionality, hence the current approach.  My other
> issue
> >>> is with circular dependencies, as I'd like access to "app" throughout
> my
> >>> controllers.  This is fine the way I've implemented it, but I'm now
> leaving
> >>> the "Module" functionality on the table.
> >>> Is there a better way to structure this, such that I'm not opting out
> of
> >>> framework functionality but also not causing dependency issues?
> >>> Thanks!
> >>> -Mike
> >
> >
>



-- 
Michael Chambliss
email@mchambliss.com