This work has now been done and merged into the trunk. See http://svn.repoze.org/repoze.bfg/trunk/CHANGES.txt for more info. I'll probably 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@lists.repoze.org > http://lists.repoze.org/listinfo/repoze-dev > _______________________________________________ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
