Previously Ian Bicking wrote:
> Chris McDonough wrote:
> > I've been working on a new web framework named (provisionally) repoze.bfg.
> > 
> > The relevant README is here: 
> >
> > 
> > It is essentially a "Zope lite".  It is Zope-ish in that:
> > 
> >   - it uses a lot of Zope libraries and concepts (interfaces, some CA 
> > constructs,
> >     ZCML)
> > 
> >   - it uses graph-traversal-based URL dispatch.
> I feel like there's some... different perspective on things that would 
> be useful to understand in this case.  I'm not sure exactly how you are 
> implementing this.  Like, Zope (and TG), with getattr?  Incidentally, TG 
> uses Routes with a default route that points to the object publisher, 
> which is similar to what you suggest doing in a response in this thread.
> Anyway, I feel like there's some useful distinction to be teased out 
> here, with next-segment URL analysis (like in object publishing) and 
> whole-URL analysis (with Routes).  paste.urlmap being another example of 
> next-segment.

For Zope there are two packages that make it possible to use something
similar to routes inside Zope as well: megrok.trails allows you to do
routes-style traversal from a content object. z3c.routes (far from
usable still) allows the same but goes a bit further in that it allows
the publisher to continue with content/graph-based traversal after it
has processed a route, making it possible to mix routes and graph-style
traversing in any way you want.

Which mechanism you use depends highly on the use case. For hierarchical
content such as Zope gets from the ZODB content traversing is extremely
intuitive and practical. When you deal with applications that are as
content-centric routes makes more sense since you are not traversing
over content(ish) objects. I've often had a wish to be able to combine
the two so you can start with contrnt traversal to get to an object and
use a routes-style traverser from there to find the right controller. In
more Zopeish terminology I want to use routes to get a parameterized
view for the context.


Wichert Akkerman <[EMAIL PROTECTED]>    It is simple to make things.                   It is hard to make things simple.
Repoze-dev mailing list

Reply via email to