librelist archives

Re: [flask] Larger Applications, I'm trying to achieve this directory structure

From:

Dan Jacob

Date:

2010-09-03 @ 12:27

On 3 September 2010 13:09, Davide Muzzarelli <d.muzzarelli@dav-muz.net> wrote:
> In data venerdì 03 settembre 2010 13:24:54, Dan Jacob ha scritto:
>> > The SQLAlchemy extension. I use it because I suppose that it is used by
>> > most of Flask's developers.
>>
>> How do you know this ?
>
> I written that I suppose. I read comments from the Django community and
> Flask's one, SQLAlchemy is what I read 99% of the time. However I have to base
> the Admin and other future modules on a database.
>

This is the crux of the problem, as I stated earlier in this thread.

Why choose Django over Flask and vice versa ? Minor (in practical
terms) design differences aside, they have different philosophies.

Django is optimized to building large websites from large components
(apps). Some components (admin, auth) come with Django, some are 3rd
party, some you write yourself, plus a bit of glue code (settings,
templates etc). But the intention is to be able to wire together some
apps and you are done, bar the design phase.

This is a very powerful concept, and for certain projects it's ideal.
However the tradeoff is that you give up flexibility. You have to use
this template engine, that ORM, and (if you want to use admin and just
about every other app out there) an authentication model that
dictates, for example, that you shall have a username of 30
characters.

For other projects that's not ideal. You are not building a
cookie-cutter website but something different - maybe porting a legacy
application, maybe something quite new. You need the flexibility of
choosing Couch or Redis or some SQL backend; you need to be able to
build something from scratch with control over components. This is
where a framework like Flask (and others - Catalyst for example) is
most desirable.

If Flask where to have an "admin" app then it would simply be another
Django, with all the constraints of Django. We don't need that; we
already have Django. What we do need is a Python framework capable of
simplicity and flexibility, that allows you to use what you need and
discard the rest. One may argue that Pylons already does this, and
that Flask competes with Pylons; fine. But we don't need to just
re-write Django. Any admin app you make that assumes the same thing
the Django admin assumes would just make Flask into Django, which
seems to me rather pointless.

Now what would be clever, and I'm not sure it's doable but would love
to be proven wrong, is a framework built on top of Flask that would
allow different backends (database backends and
authentication/permissions), so you can create a CRUD interface using
SQLAlchemy or MongoDB or whatever, which allows OpenID authentication
and customizable permissions. That would be useful, but as I've said,
I'm not sure it's doable (in the sense that it wouldn't require a ton
of configuration and glue to get it working).


> It is still possible to use another because I leverage the
> SQLALCHEMY_DATABASE_URI that have the "SQLALCHEMY" word inside that do not
> clash with different database extensions.
>
>> > Without a fork it is impossible to:
>> > - create custom urls based on an existing module;
>>
>> Sorry ? You can do this:
>>
>> app.register_module(mod, url_prefix="/blah/")
>
> Probably I have not explained well.
>
> That you write is only a prefix.
> Very often, expecially for SEO intentions or for remove unuseful views, I have
> to change internal urls and also replace views with advanced or simpler ones.
>
> A simple case of a News module that have these urls: '/news/',
> '/news/archive/', '/news/detail/'.
> If I want to remove the archive I can't do it, or I have to modify the module
> hard coding.
> If I want to extend the view with more parameters I can't do it, or I have to
> modify the module hard coding.
> If I want to translate te url (like '/novita/', '/archivio/novita/', '/leggi-
> novita/') I can't do it, or I have to modify the module hard coding.
> If I want to use a module with two or more different manners in the same site
> (I do it sometime, like '/news/company/', '/news/archive/', '/news/events/',
> '/latest/news/', '/news/<id>/') I can't do it, or I have to modify the module
> hard coding.
>
> News is a really easy module, think about a eCommerce module.
>
> It is still possible that I completely misunderstood what actual modules do,
> so please tell me if there are solutions to these problems (that I have to
> solve everyday) without take the module, copy it and modify it everytime for
> many websites.
>
> The system is simple, very configurable like Django's one, but more configurable
> because it is possible to change how modules works for really bigger
> applications.
>
>> Not sure what this means. Modules can be shared; just import them from
>> a common package.
>
> I know it but it's not enough, the problem that I wish to solve is above.
>
>> Use the application factory pattern.
>
> I do it but this force me to fork Flask because these thing are impossible
> without. So I give the source on github.
>
> I'm also ready to see the Armin's new modules if those change somethings and
> to maintain my fork in sync with him. I just tell that before. I do not love
> to maintain a fork, is a waste of time, but I really need it in order to solve
> these problems.
>
> Actually I'm waiting for feedback if someones have the same needs.
>
> Davide Muzzarelli
> www.dav-muz.net
>

In data venerdì 03 settembre 2010 14:27:00, Dan Jacob ha scritto:
> Django is optimized to building large websites from large components
> (apps). Some components (admin, auth) come with Django, some are 3rd
> party, some you write yourself, plus a bit of glue code (settings,
> templates etc). But the intention is to be able to wire together some
> apps and you are done, bar the design phase.

Exactly, I actually need that components system because this save my business 
of an huge amount of days per month.

> This is a very powerful concept, and for certain projects it's ideal.
> However the tradeoff is that you give up flexibility. You have to use
> this template engine, that ORM, and (if you want to use admin and just
> about every other app out there) an authentication model that
> dictates, for example, that you shall have a username of 30
> characters.

Exactly, and this is the classic problem of Coupling and Cohesion.

I think that it's not avoidable, but there are manners to make it less 
problematic.

> For other projects that's not ideal. You are not building a
> cookie-cutter website but something different - maybe porting a legacy
> application, maybe something quite new. You need the flexibility of
> choosing Couch or Redis or some SQL backend; you need to be able to
> build something from scratch with control over components. This is
> where a framework like Flask (and others - Catalyst for example) is
> most desirable.

Flask is fantastic in this. But not for modules, because it suppose that all 
use a system in that way! I can't use a module in another manner without fork 
it!


The code that I writted permit to use Flask exactly like before, no 
differences! I only removed modules because are inflexible.
I expanded only the possibility of configuration of the things that was hard 
coded (like the static path, routers and template sources).

This open the possibility to use Flask for a developer that don't like Flask 
modules. No more.

> If Flask where to have an "admin" app then it would simply be another
> Django, with all the constraints of Django. We don't need that; we
> already have Django. What we do need is a Python framework capable of
> simplicity and flexibility, that allows you to use what you need and
> discard the rest. One may argue that Pylons already does this, and
> that Flask competes with Pylons; fine. But we don't need to just
> re-write Django. Any admin app you make that assumes the same thing
> the Django admin assumes would just make Flask into Django, which
> seems to me rather pointless.
> 
> Now what would be clever, and I'm not sure it's doable but would love
> to be proven wrong, is a framework built on top of Flask that would
> allow different backends (database backends and
> authentication/permissions), so you can create a CRUD interface using
> SQLAlchemy or MongoDB or whatever, which allows OpenID authentication
> and customizable permissions. That would be useful, but as I've said,
> I'm not sure it's doable (in the sense that it wouldn't require a ton
> of configuration and glue to get it working).

Fantastic! All what you write is exactly where I started! :)

I love Django for many thing but, unfortunately, it is impossible to extend 
over close limits. A classic example is the Django ORM: if you do not like it 
you cannot replace it because it is integrated in the system so much that you 
have to rewrite all (and not only the contrib apps that are the minor things).

What I wish is to create my custom create_app() function where configure Flask 
to use another type of modules like the Django one (or, for another developer, 
his particular module system).
Over this I can create my reusable modules and configure them outside Flask.

I do it and it is almost complete. Are only 144 lines of code.
It's only a scratch for testing and I'm sure that it could be done better, see 
the attachment. As you can see I added all outside Flask.

The basic app start with the following code, the settings are in settings.py 
as you can see but could be also in an object:

== manage.py ==
from frawz import create_app

if __name__ == '__main__':
    manager = create_app(__name__, 'settings')
    manager.run()

== Example of a settings.py file ==
DEBUG = True

STATIC_ROOT = 'www/static'
URLS = 'urls.get_url_map'
SQLALCHEMY_DATABASE_URI = 'postgres:///mydatabase'

CONTEXT_PROCESSORS = ('context_processors.default',)
MODELS = ('frawz.sites.models', 'frawz.flatpages', 'contacts')
FILTERS = ('frawz.utils.context_processors.markup',)

ADMINS = ('info@mysite.com',)
EMAIL_SUBJECT_PREFIX = '[mysite.com] '
EMAIL_SERVER = ('127.0.0.1', '1025')
TEMPLATES = (), ('flask.utils',)

BABEL_DEFAULT_LOCALE = 'it'
LANGUAGES = ('it', 'en', 'fr')
LOCALESELECTOR = 'frawz.i18n.get_locale_by_subdomain'

== Example of a urls.py file ==
from flask.wrappers import Map, Rule

def get_url_map(app):
    rules = [
        Rule(app.static_path + '/<path:filename>', \
            view_func=app.send_static_file, endpoint='media'),
        Rule('/', endpoint='views.index'),
        Rule('/<string(length=2):lang_code>', endpoint='views.locale_index'),
    ]
    return Map(rules)


Davide Muzzarelli
www.dav-muz.net

Ah, I forgotten, a simple app is still possible:

== Based on the Flask documentation ==
from flask import Flask
app = Flask(__name__)

@app.url_map.route('/')
def hello():
    return "Hello World!"

if __name__ = '__main__':
    app.run()


Davide Muzzarelli
www.dav-muz.net

We use MongoDB, with PyMongo. We used to use Django back when we used MySQL.
We eventually left Django because of the downsides mentioned prior - so much
of the framework now depends on the pre-packaged ORM and stuff. I'd imagine
this would be less of a problem if there were no Django Admin to make it
feel like you're missing out on something by not using their ORM. You also
lose authentication, sessions (i think?), etc.

We moved to Flask because it was so light weight, but allowed us to develop
much like we did while using Django. Jinja2 makes our templating the same,
WTForms gets our forms the same. We had to write our own authentication
mechanisms, but that turned out real cool.

I don't think I'll be going back to Django after using Flask, unless I plan
on using one of the supported SQL engines.

On Fri, Sep 3, 2010 at 8:23 AM, Davide Muzzarelli
<d.muzzarelli@dav-muz.net>wrote:

> Ah, I forgotten, a simple app is still possible:
>
> == Based on the Flask documentation ==
> from flask import Flask
> app = Flask(__name__)
>
> @app.url_map.route('/')
> def hello():
>    return "Hello World!"
>
> if __name__ = '__main__':
>    app.run()
>
>
> Davide Muzzarelli
> www.dav-muz.net
>

In data venerdì 03 settembre 2010 16:41:07, Ryan Cole ha scritto:
> We use MongoDB, with PyMongo. We used to use Django back when we used
> MySQL. We eventually left Django because of the downsides mentioned prior
> - so much of the framework now depends on the pre-packaged ORM and stuff.
> I'd imagine this would be less of a problem if there were no Django Admin
> to make it feel like you're missing out on something by not using their
> ORM. You also lose authentication, sessions (i think?), etc.

The Django ORM is coupled with a lot of things, also the forms! ^_^
A mess...

> We moved to Flask because it was so light weight, but allowed us to develop
> much like we did while using Django. Jinja2 makes our templating the same,
> WTForms gets our forms the same. We had to write our own authentication
> mechanisms, but that turned out real cool.
> 
> I don't think I'll be going back to Django after using Flask, unless I plan
> on using one of the supported SQL engines.

I think the same thing and I developed a similar system outside Flask in order 
to get what I like of Django (the configuration).

When I speak about an Admin module, I mean that I will develop it outside 
Flask because I need one for my clients and operators. I do not want absolutly 
standard modules or a module system like Django (or others) in Flask! I wish 
Flask free of that.

I tell this only for clearness.

Davide Muzzarelli
www.dav-muz.net