Hi,
For 0.7 we really need a extension container for Flask where extensions
can drop themselves into. I think for simplicity we should just add a
dictionary called "extensions" on the application object. For the
transition phase (stuff before 1.0) extensions should register
themselves like this:
def init_app(self, app):
if not hasattr(app, 'extensions'):
app.extensions = {}
app.extensions['foo'] = self
(In case of a flask extension called Flask-Foo)
Any objections?
Regards,
Armin
On Thu, 2010-09-02 at 13:59 +0200, Armin Ronacher wrote: > Hi, > > For 0.7 we really need a extension container for Flask where extensions > can drop themselves into. I think for simplicity we should just add a > dictionary called "extensions" on the application object. For the > transition phase (stuff before 1.0) extensions should register > themselves like this: > > def init_app(self, app): > if not hasattr(app, 'extensions'): > app.extensions = {} > app.extensions['foo'] = self > > (In case of a flask extension called Flask-Foo) > > Any objections? > > > Regards, > Armin +1 from me obviously. The key name should be the same as the package or module name in the flaskext namespace. I also propose the inclusion of this function: def flaskext(name): return current_app.extensions[name] It's just a small shortcut so not of great importance, but could be neat. How about we also rename Module, aliasing Module to the new name but throwing DeprecationWarning; for some versions until 1.0?
Hi, On 2010-09-02 2:27 PM, Dag Odenhall wrote: > +1 from me obviously. The key name should be the same as the package or > module name in the flaskext namespace. I also propose the inclusion of > this function: > > def flaskext(name): > return current_app.extensions[name] > > It's just a small shortcut so not of great importance, but could be > neat. Makes sense. > How about we also rename Module, aliasing Module to the new name but > throwing DeprecationWarning; for some versions until 1.0? Totally for that. But what would be the new name? I have a branch for that and the static file issue in new-modules on github. Regards, Armin
On Thu, 2010-09-02 at 14:55 +0200, Armin Ronacher wrote: > Hi, > > On 2010-09-02 2:27 PM, Dag Odenhall wrote: > > +1 from me obviously. The key name should be the same as the package or > > module name in the flaskext namespace. I also propose the inclusion of > > this function: > > > > def flaskext(name): > > return current_app.extensions[name] > > > > It's just a small shortcut so not of great importance, but could be > > neat. > Makes sense. > > > How about we also rename Module, aliasing Module to the new name but > > throwing DeprecationWarning; for some versions until 1.0? > Totally for that. But what would be the new name? I have a branch for > that and the static file issue in new-modules on github. > > > Regards, > Armin Component makes most sense, but sadly people instantly think of Zope and shiver. Mount, Mountable, MountableFlask, FlaskMount, Flasket, Flasklet? Node has also been suggested, but I think a node is not a mountable tree. Liquid, because you mix it in a Flask and because it provides the flexible reusability; liquid substances will go anywhere you poor it.
On Thu, Sep 2, 2010 at 9:53 AM, Dag Odenhall <dag.odenhall@gmail.com> wrote: >> > How about we also rename Module, aliasing Module to the new name but >> > throwing DeprecationWarning; for some versions until 1.0? >> Totally for that. But what would be the new name? > Component makes most sense, but sadly people instantly think of Zope and > shiver. > > Mount, Mountable, MountableFlask, FlaskMount, Flasket, Flasklet? > > Node has also been suggested, but I think a node is not a mountable > tree. > > Liquid, because you mix it in a Flask and because it provides the > flexible reusability; liquid substances will go anywhere you poor it. > Cups, glasses, and other containers for drinking are extensions of a flask. You pour from the flask and pass the glass around. Any name ideas in this theme? Cocktail, since your mixing from the Flask with other ingredients, built to order. -Ron
On 2 September 2010 15:03, Ron DuPlain <ron.duplain@gmail.com> wrote: > On Thu, Sep 2, 2010 at 9:53 AM, Dag Odenhall <dag.odenhall@gmail.com> wrote: >>> > How about we also rename Module, aliasing Module to the new name but >>> > throwing DeprecationWarning; for some versions until 1.0? >>> Totally for that. But what would be the new name? >> Component makes most sense, but sadly people instantly think of Zope and >> shiver. >> >> Mount, Mountable, MountableFlask, FlaskMount, Flasket, Flasklet? >> >> Node has also been suggested, but I think a node is not a mountable >> tree. >> >> Liquid, because you mix it in a Flask and because it provides the >> flexible reusability; liquid substances will go anywhere you poor it. >> > > Cups, glasses, and other containers for drinking are extensions of a > flask. You pour from the flask and pass the glass around. Any name > ideas in this theme? > > Cocktail, since your mixing from the Flask with other ingredients, > built to order. > > -Ron > We used to call them "Appliances". Ali
I like Component, but it is a loaded word (not because of Zope
necessarily, but it's so overused elsewhere).
Using cup, glass, flaggon or whatever is confusing, especially to new users.
Essentially a Module is a collection of views, or more precisely, a
set of routes. So how about a Routes object ?
So:
admin = Routes("admin")
app.register_routes(admin)
On 2 September 2010 15:25, Ali Afshar <aafshar@gmail.com> wrote:
> On 2 September 2010 15:03, Ron DuPlain <ron.duplain@gmail.com> wrote:
>> On Thu, Sep 2, 2010 at 9:53 AM, Dag Odenhall <dag.odenhall@gmail.com> wrote:
>>>> > How about we also rename Module, aliasing Module to the new name but
>>>> > throwing DeprecationWarning; for some versions until 1.0?
>>>> Totally for that. But what would be the new name?
>>> Component makes most sense, but sadly people instantly think of Zope and
>>> shiver.
>>>
>>> Mount, Mountable, MountableFlask, FlaskMount, Flasket, Flasklet?
>>>
>>> Node has also been suggested, but I think a node is not a mountable
>>> tree.
>>>
>>> Liquid, because you mix it in a Flask and because it provides the
>>> flexible reusability; liquid substances will go anywhere you poor it.
>>>
>>
>> Cups, glasses, and other containers for drinking are extensions of a
>> flask. You pour from the flask and pass the glass around. Any name
>> ideas in this theme?
>>
>> Cocktail, since your mixing from the Flask with other ingredients,
>> built to order.
>>
>> -Ron
>>
>
> We used to call them "Appliances".
>
> Ali
>
> Essentially a Module is a collection of views, or more precisely, a > set of routes. So how about a Routes object ? Routes to many == something to do with urls. http://routes.groovie.org/ Number one search on google. I even said "Routes? That's the name of that python url library right?"
Good point. On 3 September 2010 21:13, kevin beckford <chiggsy@lazyweb.ca> wrote: >> Essentially a Module is a collection of views, or more precisely, a >> set of routes. So how about a Routes object ? > > Routes to many == something to do with urls. > http://routes.groovie.org/ Number one search on google. I even said > "Routes? That's the name of that python url library right?" >
>> How about we also rename Module, aliasing Module to the new name but >> throwing DeprecationWarning; for some versions until 1.0? > Totally for that. But what would be the new name? I have a branch for > that and the static file issue in new-modules on github. > Flasklet ?
What benefit does this bring to the existing setup ? For example some extensions may not be registered at all, e.g. Flask-WTF. On 2 September 2010 12:59, Armin Ronacher <armin.ronacher@active-4.com> wrote: > Hi, > > For 0.7 we really need a extension container for Flask where extensions > can drop themselves into. I think for simplicity we should just add a > dictionary called "extensions" on the application object. For the > transition phase (stuff before 1.0) extensions should register > themselves like this: > > def init_app(self, app): > if not hasattr(app, 'extensions'): > app.extensions = {} > app.extensions['foo'] = self > > (In case of a flask extension called Flask-Foo) > > Any objections? > > > Regards, > Armin >
On Thu, 2010-09-02 at 13:02 +0100, Dan Jacob wrote: > What benefit does this bring to the existing setup ? For example some > extensions may not be registered at all, e.g. Flask-WTF. Extensions without an instance don't need to use this of course. Other extensions however might have an instance associated with an app, that extension functions need to know; this is a clean way to solve that consistently. Also makes it easy to access extension instances without importing them from wherever you set them up.
Just wondering if signals might be the answer here. You have a signal, emitted by the app (automatically or explicitly) at some point. An extension can connect a listener: register_extensions.connect(my_extension_setup) Your extension setup function would obviously take "app" as argument: def my_extension_setup(app): # do something with app Then a user would create e.g. a Flask-SQLAlchemy instance in their models.py file db = SQLAlchemy() and would not then need to worry about calling init_app() anywhere, as the signal would call init_app at the right time. On 2 September 2010 13:31, Dag Odenhall <dag.odenhall@gmail.com> wrote: > On Thu, 2010-09-02 at 13:02 +0100, Dan Jacob wrote: >> What benefit does this bring to the existing setup ? For example some >> extensions may not be registered at all, e.g. Flask-WTF. > > Extensions without an instance don't need to use this of course. Other > extensions however might have an instance associated with an app, that > extension functions need to know; this is a clean way to solve that > consistently. > > Also makes it easy to access extension instances without importing them > from wherever you set them up. > >
On Thu, 2010-09-02 at 13:41 +0100, Dan Jacob wrote: > Just wondering if signals might be the answer here. > > You have a signal, emitted by the app (automatically or explicitly) at > some point. An extension can connect a listener: > > register_extensions.connect(my_extension_setup) > > Your extension setup function would obviously take "app" as argument: > > def my_extension_setup(app): > # do something with app > > Then a user would create e.g. a Flask-SQLAlchemy instance in their > models.py file > > db = SQLAlchemy() > > and would not then need to worry about calling init_app() anywhere, as > the signal would call init_app at the right time. I don't think this is relevant; the point is that whatever and whenever init_app (or __init__) is called, some extensions might want to associate themselves with the app somehow. They can add themselves on an attribute of the app or keep an app registry themselves somehow, but an extensions dictionary on the app is cleaner and more consistent. In Flask-Genshi I have e.g. render_template that needs to get its Genshi() instance from current_app somehow. I could just have render_template be a function on the genshi object, or pass the function the instance, but it's cumbersome and not very Flasky. So in the extension init I do app.genshi_instance = self, and render_template et al then do current_app.genshi_instance.template_loader etc. This isn't very clean and lack convention with other extensions.
I see your point. Basically there are some extensions that need to register themselves with the current app, and monkeypatching them on is not very elegant. On 2 September 2010 13:48, Dag Odenhall <dag.odenhall@gmail.com> wrote: > On Thu, 2010-09-02 at 13:41 +0100, Dan Jacob wrote: >> Just wondering if signals might be the answer here. >> >> You have a signal, emitted by the app (automatically or explicitly) at >> some point. An extension can connect a listener: >> >> register_extensions.connect(my_extension_setup) >> >> Your extension setup function would obviously take "app" as argument: >> >> def my_extension_setup(app): >> # do something with app >> >> Then a user would create e.g. a Flask-SQLAlchemy instance in their >> models.py file >> >> db = SQLAlchemy() >> >> and would not then need to worry about calling init_app() anywhere, as >> the signal would call init_app at the right time. > > I don't think this is relevant; the point is that whatever and whenever > init_app (or __init__) is called, some extensions might want to > associate themselves with the app somehow. They can add themselves on an > attribute of the app or keep an app registry themselves somehow, but an > extensions dictionary on the app is cleaner and more consistent. > > In Flask-Genshi I have e.g. render_template that needs to get its > Genshi() instance from current_app somehow. I could just have > render_template be a function on the genshi object, or pass the function > the instance, but it's cumbersome and not very Flasky. So in the > extension init I do app.genshi_instance = self, and render_template et > al then do current_app.genshi_instance.template_loader etc. This isn't > very clean and lack convention with other extensions. > > > >
Maybe, for registering jinja2 extensions that would work. 2010/9/2 Dan Jacob <danjac354@gmail.com> > What benefit does this bring to the existing setup ? For example some > extensions may not be registered at all, e.g. Flask-WTF. > > On 2 September 2010 12:59, Armin Ronacher <armin.ronacher@active-4.com> > wrote: > > Hi, > > > > For 0.7 we really need a extension container for Flask where extensions > > can drop themselves into. I think for simplicity we should just add a > > dictionary called "extensions" on the application object. For the > > transition phase (stuff before 1.0) extensions should register > > themselves like this: > > > > def init_app(self, app): > > if not hasattr(app, 'extensions'): > > app.extensions = {} > > app.extensions['foo'] = self > > > > (In case of a flask extension called Flask-Foo) > > > > Any objections? > > > > > > Regards, > > Armin > > > -- "A arrogância é a arma dos fracos." =========================== Italo Moreira Campelo Maia Graduado em Ciência da Computação - UECE Desenvolvedor WEB e Desktop (Java, Python, Lua) Coordenador do Pug-CE ----------------------------------------------------- http://www.italomaia.com/ http://twitter.com/italomaia/ http://eusouolobomau.blogspot.com/ ----------------------------------------------------- turtle linux 910 - http://tiny.cc/blogturtle910 ===========================
'app' is a just 'Flask' object? Couldn't it be a 'Module' object? 2010/9/2, Italo Maia <italo.maia@gmail.com>: > Maybe, for registering jinja2 extensions that would work. > > 2010/9/2 Dan Jacob <danjac354@gmail.com> > >> What benefit does this bring to the existing setup ? For example some >> extensions may not be registered at all, e.g. Flask-WTF. >> >> On 2 September 2010 12:59, Armin Ronacher <armin.ronacher@active-4.com> >> wrote: >> > Hi, >> > >> > For 0.7 we really need a extension container for Flask where extensions >> > can drop themselves into. I think for simplicity we should just add a >> > dictionary called "extensions" on the application object. For the >> > transition phase (stuff before 1.0) extensions should register >> > themselves like this: >> > >> > def init_app(self, app): >> > if not hasattr(app, 'extensions'): >> > app.extensions = {} >> > app.extensions['foo'] = self >> > >> > (In case of a flask extension called Flask-Foo) >> > >> > Any objections? >> > >> > >> > Regards, >> > Armin >> > >> > > > > -- > "A arrogância é a arma dos fracos." > > =========================== > Italo Moreira Campelo Maia > Graduado em Ciência da Computação - UECE > Desenvolvedor WEB e Desktop (Java, Python, Lua) > Coordenador do Pug-CE > ----------------------------------------------------- > http://www.italomaia.com/ > http://twitter.com/italomaia/ > http://eusouolobomau.blogspot.com/ > ----------------------------------------------------- > turtle linux 910 - http://tiny.cc/blogturtle910 > =========================== >
What benefit does this bring to the existing setup ? For example some extensions may not be registered at all, e.g. Flask-WTF. On 2 September 2010 12:59, Armin Ronacher <armin.ronacher@active-4.com> wrote: > Hi, > > For 0.7 we really need a extension container for Flask where extensions > can drop themselves into. I think for simplicity we should just add a > dictionary called "extensions" on the application object. For the > transition phase (stuff before 1.0) extensions should register > themselves like this: > > def init_app(self, app): > if not hasattr(app, 'extensions'): > app.extensions = {} > app.extensions['foo'] = self > > (In case of a flask extension called Flask-Foo) > > Any objections? > > > Regards, > Armin >