librelist archives

Application routes

From:

Dejan Noveski

Date:

2010-09-20 @ 22:20

Hello fellow flaskers,

Recently i started making a skeleton for a large Flask project. I had some
extra time on my hands and I experimented a bit. I tried to make modular
project where each application (Flask Module) is a package inside an apps
folder.
The only thing that bugged me was the circular import when importing app
object from __init__.py in views.py, and importing views in __init__.py. I
forked Flask and checked out the app.route decorator, so I made a file
called urls.py:
*------------------------------------------------------*
*import views*
*
*
*routes = (*
*    ('/', 'index', views.index),*
*    ('/second', 'second', views.second)*
*)*
*------------------------------------------------------*

views.py looks like this:
*------------------------------------------------------*
*def index():*
*    return "Hello world from index"*
*
*
*def second():*
*    return "Hello world from second"*
*
*
*#Note: there is no app object imported hence no circular import*
*------------------------------------------------------*

and __init__.py looks like this:
*------------------------------------------------------*
*from flask import Flask*
*from urls import routes*
*
*
*app = Flask(__name__)*
*
*
*for url in routes:*
*    app.add_url_rule(*url)*
*
*
*#Note: views module is not imported here.*
*------------------------------------------------------*

I've tried this setup with several applications, looks like it works pretty
good. My question is: Is this setup good? Are there any issues that might
arise using this configuration?
I do this just for the sake to avoid the circular import in multi-app setup.
Also, it looks more tidy when working with big project tree.

-- 
--
Dejan Noveski
Web Developer
dr.mote@gmail.com
Twitter: http://twitter.com/dekomote | LinkedIn:
http://mk.linkedin.com/in/dejannoveski

Atomidata http://www.atomidata.com

Hi,

On 9/21/10 12:20 AM, Dejan Noveski wrote:
> I've tried this setup with several applications, looks like it works
> pretty good. My question is: Is this setup good? Are there any issues
> that might arise using this configuration?
Nope, should work fine.

> I do this just for the sake to avoid the circular import in multi-app
> setup. Also, it looks more tidy when working with big project tree.
I have a few local branches where I experiment with a couple of possible 
setups for modules that work well for larger applications that also 
don't break existing ones and continues to work with modules.  I 
definitively want to see some improvement there.

My main motivation is not exactly getting rid of the circular import, 
which works out when used properly, but to find a pattern in general 
that does not require importing all the application upfront.

Also my plan is to find a nicer way to handle static files which are 
currently automagically exported based on the presence of a static 
folder which was a huge mistake in the hindsight :(


Regards,
Armin

On Sep 20, 2010, at 6:00 PM, Armin Ronacher wrote:

> Hi,
> 
> On 9/21/10 12:20 AM, Dejan Noveski wrote:
>> I've tried this setup with several applications, looks like it works
>> pretty good. My question is: Is this setup good? Are there any issues
>> that might arise using this configuration?
> Nope, should work fine.
> 
>> I do this just for the sake to avoid the circular import in multi-app
>> setup. Also, it looks more tidy when working with big project tree.
> I have a few local branches where I experiment with a couple of possible 
> setups for modules that work well for larger applications that also 
> don't break existing ones and continues to work with modules.  I 
> definitively want to see some improvement there.
> 
> My main motivation is not exactly getting rid of the circular import, 
> which works out when used properly, but to find a pattern in general 
> that does not require importing all the application upfront.
> 
> Also my plan is to find a nicer way to handle static files which are 
> currently automagically exported based on the presence of a static 
> folder which was a huge mistake in the hindsight :(
> 
> 
> Regards,
> Armin

Why do you think it was a huge mistake?
Because of the scenarios when you have your static files on S3?

Regards,
Juan-Pablo

> My main motivation is not exactly getting rid of the circular import,
> which works out when used properly, but to find a pattern in general
> that does not require importing all the application upfront.

OTOH this is an advantage of Flask; it's conceptually simple, in that
you have an app instance you attach routes etc to. It's kind of
"inside out" compared to e.g. Django where the setup is hidden.

>
> Also my plan is to find a nicer way to handle static files which are
> currently automagically exported based on the presence of a static
> folder which was a huge mistake in the hindsight :(
>

What would be useful are "named" static handlers that you can attach
to your app. For example, I have this:

app = Flask(__name__)
app.add_static_handler('images', '/images/', path_to_images)

In your template:

<img src="{{ url_for('images', filename="icon.jpg") }}">

This is fine for development, but in production you are serving your
images in nginx or a completely different domain such as S3. You can
change the URL and/or path in configuration, but still use the
'images' handler name.

On Tue, Sep 21, 2010 at 1:11 AM, Dan Jacob <danjac354@gmail.com> wrote:
>> My main motivation is not exactly getting rid of the circular import,
>> which works out when used properly, but to find a pattern in general
>> that does not require importing all the application upfront.
>
> OTOH this is an advantage of Flask; it's conceptually simple, in that
> you have an app instance you attach routes etc to. It's kind of
> "inside out" compared to e.g. Django where the setup is hidden.
>
>>
>> Also my plan is to find a nicer way to handle static files which are
>> currently automagically exported based on the presence of a static
>> folder which was a huge mistake in the hindsight :(
>>
>
> What would be useful are "named" static handlers that you can attach
> to your app. For example, I have this:
>
> app = Flask(__name__)
> app.add_static_handler('images', '/images/', path_to_images)
>
> In your template:
>
> <img src="{{ url_for('images', filename="icon.jpg") }}">
>
> This is fine for development, but in production you are serving your
> images in nginx or a completely different domain such as S3. You can
> change the URL and/or path in configuration, but still use the
> 'images' handler name.

+1 for static handler. It looks really clean and straightforward.

Alex

Hi,

On 9/21/10 1:11 AM, Dan Jacob wrote:
> What would be useful are "named" static handlers that you can attach
> to your app. For example, I have this:
>
> app = Flask(__name__)
> app.add_static_handler('images', '/images/', path_to_images)

That kinda already works:

from flask import send_from_directory
app.add_url_rule('/images/<path:filename>', 'images',
                  lambda request, filename:
                  send_from_directory(path_to_images, filename))


Regards,
Armin

Can I use a completely different domain with add_url_rule ? If so,
then yes, that fixes the problem. For example, I might want to switch
all my static URLs to an Amazon S3 account later on; I don't want to
go through all my templates and change the URLs.

On 21 September 2010 00:26, Armin Ronacher <armin.ronacher@active-4.com> wrote:
> Hi,
>
> On 9/21/10 1:11 AM, Dan Jacob wrote:
>> What would be useful are "named" static handlers that you can attach
>> to your app. For example, I have this:
>>
>> app = Flask(__name__)
>> app.add_static_handler('images', '/images/', path_to_images)
>
> That kinda already works:
>
> from flask import send_from_directory
> app.add_url_rule('/images/<path:filename>', 'images',
>                  lambda request, filename:
>                  send_from_directory(path_to_images, filename))
>
>
> Regards,
> Armin
>

Another +1 for by domain for this and for @route.

--
Thadeus





On Tue, Sep 21, 2010 at 2:14 AM, Dan Jacob <danjac354@gmail.com> wrote:
> Can I use a completely different domain with add_url_rule ? If so,
> then yes, that fixes the problem. For example, I might want to switch
> all my static URLs to an Amazon S3 account later on; I don't want to
> go through all my templates and change the URLs.
>
> On 21 September 2010 00:26, Armin Ronacher <armin.ronacher@active-4.com> wrote:
>> Hi,
>>
>> On 9/21/10 1:11 AM, Dan Jacob wrote:
>>> What would be useful are "named" static handlers that you can attach
>>> to your app. For example, I have this:
>>>
>>> app = Flask(__name__)
>>> app.add_static_handler('images', '/images/', path_to_images)
>>
>> That kinda already works:
>>
>> from flask import send_from_directory
>> app.add_url_rule('/images/<path:filename>', 'images',
>>                  lambda request, filename:
>>                  send_from_directory(path_to_images, filename))
>>
>>
>> Regards,
>> Armin
>>
>

I like the static handler idea. It's simple, you can either add 1 static
handler for e.g. /static folder or add several handlers for /static/js
/static/css etc.

On Tue, Sep 21, 2010 at 1:11 AM, Dan Jacob <danjac354@gmail.com> wrote:

> > My main motivation is not exactly getting rid of the circular import,
> > which works out when used properly, but to find a pattern in general
> > that does not require importing all the application upfront.
>
> OTOH this is an advantage of Flask; it's conceptually simple, in that
> you have an app instance you attach routes etc to. It's kind of
> "inside out" compared to e.g. Django where the setup is hidden.
>
> >
> > Also my plan is to find a nicer way to handle static files which are
> > currently automagically exported based on the presence of a static
> > folder which was a huge mistake in the hindsight :(
> >
>
> What would be useful are "named" static handlers that you can attach
> to your app. For example, I have this:
>
> app = Flask(__name__)
> app.add_static_handler('images', '/images/', path_to_images)
>
> In your template:
>
> <img src="{{ url_for('images', filename="icon.jpg") }}">
>
> This is fine for development, but in production you are serving your
> images in nginx or a completely different domain such as S3. You can
> change the URL and/or path in configuration, but still use the
> 'images' handler name.
>



-- 
--
Dejan Noveski
Web Developer
dr.mote@gmail.com
Twitter: http://twitter.com/dekomote | LinkedIn:
http://mk.linkedin.com/in/dejannoveski

Atomidata http://www.atomidata.com