librelist archives

« back to archive

Request Context Available to URL Converter

Request Context Available to URL Converter

From:
nivardus
Date:
2011-06-19 @ 15:49
I am working on an app using flask-sqlalchemy and with multiple view
modules. It would be amazingly convenient to use a URL Converter (subclass
of werkzeug.routing.UnicodeConverter) to parse and pass one of my models as
an argument to views. However, when working with modules flaskext.SQLAlchemy
pulls the app (with engine config, etc.) from the current context, which is
not available until the view is called. This, I presume, is to allow modules
different extension configurations (modules are modular who would have
guessed.)

Would it be wrongheaded to resolve to a module based on its url_prefix
before parsing it to python objects for views? I have been having
difficulting tracing down what exactly to subclass and change, short of
knowing the module would need to be determined before
werkzeug.routing.Rule.match() begins work.

The app's __init__.py for reference: http://paste.pocoo.org/show/414719/
-- 
Bennett Goble // Nivardus

Re: [flask] Request Context Available to URL Converter

From:
Ron DuPlain
Date:
2011-06-20 @ 16:46
On Sun, Jun 19, 2011 at 11:49 AM, nivardus <nivardus@gmail.com> wrote:
> I am working on an app using flask-sqlalchemy and with multiple view
> modules. It would be amazingly convenient to use a URL Converter (subclass
> of werkzeug.routing.UnicodeConverter) to parse and pass one of my models as
> an argument to views. However, when working with modules flaskext.SQLAlchemy
> pulls the app (with engine config, etc.) from the current context, which is
> not available until the view is called. This, I presume, is to allow modules
> different extension configurations (modules are modular who would have
> guessed.)

You are right.  The current request context is not yet available at
this point in the dispatch.  Personally, I'd build a view function
wrapper that converts the view arg to a model with abort(404) given
any problems.


> Would it be wrongheaded to resolve to a module based on its url_prefix
> before parsing it to python objects for views? I have been having
> difficulting tracing down what exactly to subclass and change, short of
> knowing the module would need to be determined before
> werkzeug.routing.Rule.match() begins work.

match is called here, in _RequestContext.__init__
https://github.com/mitsuhiko/flask/blob/master/flask/ctx.py#L61

-Ron


> The app's __init__.py for reference: http://paste.pocoo.org/show/414719/
> --
> Bennett Goble // Nivardus
>

Re: [flask] Request Context Available to URL Converter

From:
nivardus
Date:
2011-06-21 @ 00:38
...and thus the application/module context is available to converters:
https://gist.github.com/1036951 I believe doing it this way will preserve
module configuration (Unless I'm wrong.)

On Mon, Jun 20, 2011 at 12:46 PM, Ron DuPlain <ron.duplain@gmail.com> wrote:

>
> Personally, I'd build a view function
> wrapper that converts the view arg to a model with abort(404) given
> any problems.


I was originally doing the same, but because essentially every view in the
application would need to accept three additional arguments and include
extra code to resolve to a list of "Locale" objects I thought it'd be more
sensible to use a converter "/<Locale:Locale>/"

-- 
Bennett Goble // Nivardus

Re: [flask] Request Context Available to URL Converter

From:
Ron DuPlain
Date:
2011-06-21 @ 01:51
On Mon, Jun 20, 2011 at 8:38 PM, nivardus <nivardus@gmail.com> wrote:
> On Mon, Jun 20, 2011 at 12:46 PM, Ron DuPlain <ron.duplain@gmail.com> wrote:
>> Personally, I'd build a view function
>> wrapper that converts the view arg to a model with abort(404) given
>> any problems.
>
> I was originally doing the same, but because essentially every view in the
> application would need to accept three additional arguments and include
> extra code to resolve to a list of "Locale" objects I thought it'd be more
> sensible to use a converter "/<Locale:Locale>/"

This is one of the motivations behind the new blueprint concept coming
in Flask 0.7.  You can register functions via url_value_preprocessor
on either a blueprint or an app.  These functions are called before
the view functions are called and can modify the url values provided.

https://github.com/mitsuhiko/flask/blob/blueprints/flask/blueprints.py#L244

-Ron