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.  But it's actually whole-URL in a way -- it checks for 
prefixes as strings, and really only cares about prefixes.  So you can 
mount something on /a/b/c without having anything at /a/b.  This is 
unlike CherryPy, for instance, which (unless this has changed) actually 
creates intermediate nodes in a set of objects so that you can traverse 
through them to some more distant child.  I find this traversal 
simply... unnecessary.  Testing string prefixes is *so* easy, why add 
these other concepts?

On the other hand, I do understand some motivation for this for creating 
eclectic URL layouts.  But I wonder if there's a better way?  In 
particular, make sure that writing routing code isn't hard, so that 
custom code for different site layouts is easy.  There are at least two 
modest methods in WebOb for this -- req.path_info_peek() and 
req.path_info_pop(), which both get the next segment of the URL.  Along 
with req.urlvars (and req.urlargs) there's a way to save the captured 
data without having to instantly inspect the model (unless you want to 
inspect the model).  And domain names can be just as valid a thing to 
parse, and don't really fit any traversal pattern.

So I'd be interested in use cases people have where Routes alone isn't 
enough.  I'm sure these exist (I could come up with a few), but I'm also 
pretty sure there's other solutions than object publishing.

>   - Its equivalent of the publisher doesn't attempt to traverse into
>     *code* stored in the object graph.  All code is on the filesystem.
>     The only thing in the object graph is "model" data.

How do you deal with distinguishing between model instantiation data, 
and traversal of the models themselves?  E.g., /archive/2008/06/ -- 
/archive probably points to an Archive class or an instance (singleton?) 
of ArchiveManager or something.  /2008 and /06 probably translate to 
datetime(2008, 6) or something along those lines, which provide the 
arguments to instantiate an Archive object, and then you call some 
default method like index or __call__.  But calling getattr(obj, '2008') 
isn't sensible.  Even obj['2008'] is somewhat questionable.  Certainly 
it's not a reasonable API for any model.  I guess you are probably using 
adaptation to cover over this, so that the methods aren't necessarily on 
the model objects themselves, but that kind of feels like it's papering 
over something that could be entirely avoided.

Routes basically gives you a way to write translations from the URL to 
objects.  Though even then in Pylons it relies on controllers to even 
more translation work, though pointing routes directly at models would 
be entirely possible.

Ian Bicking : [EMAIL PROTECTED] :
Repoze-dev mailing list

Reply via email to