Chris McDonough wrote:
> I've been working on a new web framework named (provisionally) repoze.bfg.
> The relevant README is here: http://svn.repoze.org/repoze.bfg/trunk/README.txt
> It is essentially a "Zope lite". It is Zope-ish in that:
> - it uses a lot of Zope libraries and concepts (interfaces, some CA
> - 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] : http://blog.ianbicking.org
Repoze-dev mailing list