Thanks David!
And also (thanks mostly to Reed O'Brien) I came to a resolution for the issues
I
wrote down in the email. In short, I don't think anything needs to change from
how things are on the trunk.
In excruciating detail however:
- Both route and view statements will continue to exist.
- I will create an advanced topics chapter for explaining how
traversal and routing work together.
- route statements will require relative ordering. I will explain
this in advanced routes+traversal documentation by placing them
in a separate routes.zcml file that has a must be ordered! comment
and via narrative explanation.
- view statements will (optionally) name a route by its name
via a route_name attribute. I will explain that these do not
need to be ordered by placing them in a separate views.zcml
file within advanced routes+traversal documentation.
- We won't implement a routeview/view//route pattern for
now (a route tag that contains associated views). We'll keep
this in our pocket for later should the need arise.
- C
On 6/16/09 7:15 PM, David Pratt wrote:
Wow. I think you have done a pretty decent job of explaining it here
Chris. I'd include your explanation, but as you say include it as an
advanced concept. I have used both routing methods in same app and I am
currently working with bfg 0.6.9. When I update my work, which will be
soon, will be having to dig into this a bit more. I am glad you have
documented this here at the very least and see value in putting it in
the docs if not already there. Might be that folks won't get it but
those that take time to understand both routing methods will find value
and possibilities in what you have done. Many thanks.
Regards,
David
On 11-Jun-09, at 11:10 PM, Chris McDonough wrote:
So now that this work is done, I'm having some major problems
explaining its finer points in documentation. I'm a bit worried that
I'll not explain it satisfactorily, and that will cause support and
adoption issues later. Sorry about writing the novel below. I don't
really expect anybody to read this, much less reply, but maybe the act
of writing it will help me think about how to make changes that will
simplify things a bit.
On the BFG trunk, nothing much is different than BFG 0.8+ if you don't
try to use *both* routes and traversal within the same application.
In fact, almost all existing applications will run unchanged. The
only ones that won't run unchanged are those that make use of a routes
context factory.
An application that uses Routes exclusively to map URLs to code will
still have declarations like this:
route
path=:foo/:bar
name=foobar
view=.views.foobar
/
route
path=:baz/:buz
name=bazbuz
view=.views.bazbuz
/
In other words, each route typically corresponds with a single view
function, and when the route is matched during a request, the view
attached to it is invoked. Typically, applications that use only URL
dispatch won't have any view statements in them. Simple enough.
Under the hood, up until 0.9.1, when such route statements were
executed, we'd register a view for a special IRoutesContext
interface as the context interface and IRequest as a request interface
using the route name as the view name. On the BFG trunk, however, we
ditched the IRoutesContext interface because we disused the concept
of context factories in favor of unifying the idea of a root
factory as something both traversal and URL dispatch can use. So
instead when we run into view declarations like the above on the
trunk, we register a view for each route for the context interface
``None`` (implying any context) and a route-statement-specific
(dynamically-constructed) request interface type using the empty
string as the view name (implying the default view). In either case,
the point is to make it so that the named view will only be called
when the route it's attached to actually matches, and in the simplest
case they are logically equivalent.
As before, an application that uses *traversal* exclusively to map
URLs to code just won't have any route declarations. Instead, its
ZCML (or bfg_view decorators) will imply declarations that look like
this:
view
name=foobar
view=.views.foobar
/
view
name=bazbuz
view=.views.bazbuz
/
The above view statements register a view using the context interface
``None``, the IRequest request interface with a name matching the
name= argument. The foobar view above will match the URL
/a/b/c/foobar or /foobar, etc, assuming that no view is named a,
b, or c during traversal. Nothing about this has changed since,
well, forever.
No example applications that use both route and view declarations
within the same application really exist, but this has always been
possible, and it still is. It works exactly how it did in 0.8+:
route
path=:foo/:bar
name=foobar
view=.views.foobar
/
view
name=bazbuz
view=.views.bazbuz
/
In all versions of BFG after
