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 Repozeemail@example.com http://lists.repoze.org/listinfo/repoze-dev