This work has now been done and merged into the trunk.  See for more info.  I'll 
release an alpha soon into the BFG "dev" index, maybe numbered something like 
"0.9.5" or so.

- C

On 6/5/09 11:33 AM, Chris McDonough wrote:
> Paul and Tres recently taught a repoze.bfg tutorial at the Plone
> Symposium at Penn State.  Tres mentioned to me that, by the reactions
> of the tutorial attendees, he thought having two separate-but-equal
> ways to do URL-to-code mapping (traversal vs. url dispatch/aka routes)
> was too confusing.  He then suggested an alternative.
> Currently, a configured repoze.bfg application is in one of three
> modes:
> - traversal-only, when a "root factory" is used but no routes are
>     configured
> - routes-only, when routes are confgured but no root factory is used.
> - a hybrid model where if a route can't be matched, the system falls
>     back to traversal from a single root.  In this mode, both a root
>     factory and routes are configured.
> Tres' suggestion was essentially to cause BFG to always operate in a
> hybrid mode, where a "root factory" was used to generate the context
> object for views even when they are found via a route match instead of
> via traversal.
> For example, let's say we had a root factory that looked like this:
>       class Root:
>           pass
>       root = Root()
>       def root_factory(environ):
>           return root
> .. and we configure it in to our BFG application like so:
> from repoze.bfg.router import make_app
> from myapp.models import root_factory
> return make_app(root_factory)
> Currently the above "root_factory" callback is only used when the URL
> is matched as a result of traversal.  But when any<route>  matches, it
> is ignored.  Instead, when a<route>  matches:
> - If there's a "factory=" attribute on the route declaration, it names
>     a "context factory".  The context factory is called when this route
>     matches.
> - If there's no "factory=" attribute on the route declaration, a
>     default routes context factory is used.
> But BFG never calls a "root factory" for an object matched via a route.
> In a system that operated under Tres' model, we'd essentially take
> away the difference between a "root factory" and a "context factory".
> Instead:
> - Each route will match a URL pattern.
> - If a route's URL pattern is matched on ingress, if the route has a
>     "factory" attribute, the factory will be assumed to be a "root
>     factory", and it will return a context object appropriate for that
>     route.  If the route does *not* have a "factory" attribute, the
>     "default root factory" would be used to compose the context.
> - There would be a "default root factory", used when no supplied route
>     matches or when no "factory=" attribute was supplied along with a
>     route statement.  What this boils down to is that the syste will
>     have a "default route" will match any URL, but will be last in the
>     route check ordering.  The default route will always use the
>     "default root factory" as its factory.
> Benefits:
> - Makes the difference between an application that uses routes and one
>     that doesn't far less pronounced.  Essentially, this change unifies
>     the two models.
> - Adds the ability to do traversal through some set of names *after* a
>     route is matched.  We'd allow some special signifier to be placed
>     within a route path, ala "/foo/bar/*subpath"; we'd resolve the root
>     related to "/foo/bar", then just traverse with the path info
>     captured in "subpath".
> Risks:
> - If a "factory" is specified on a route, it will need to point at a
>     function that had the same call/response convention as a traversal
>     root factory.  This will break code.  "Context factories" accept
>     key/value pairs assumed to be items that matched in the URL match.
>     These would cease working, and would need to be rewritten as root
>     factories, which accept a WSGI environment.
> - URL generation may become more difficult and costly.
> I'm apt to do this for 1.0, even at the risk of breaking code, because it does
> nicely unify the traversal vs. routes story, which is definitely the
> most up-in-the-air part of BFG today.
> Anybody have any objections?
> - C
> _______________________________________________
> Repoze-dev mailing list

Repoze-dev mailing list

Reply via email to