Ian Bicking wrote:
> 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 
>> 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?  

No, __getitem__ only.

> 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.

Yes.  I understand that better after talking to Mark Ramm today.

> 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?

Why traverse a graph?  Because it's what we're used to in Zope.  I wrote a 
section in the docs about why at 
http://static.repoze.org/bfgdocs/narr/introduction.html#graph-traversal .

I'm not under any impression that it's as good as URL dispatch for finding code 
that operates against square data.  But I'm also not looking for approval to 
graph traversal.

On the other hand, I think it's reasonable and useful to mix and match the two 
as necessary.  Like, a first crack via URL dispatch, then fall back to graph 
traversal if it fails.  I'm intending to add this (via Routes probably).  That 
would be extremely useful for things that don't need graph traversal.

> 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.

That blew my stack, sorry.

> 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__. 

It's simpler than that.  We are always traversing model instances.  We just 
__geitem__ the whole way through the model graph until we either exhaust the 
path or find an item that doesnt have a __getitem__ or whose __getitem__ raises 
a KeyError.  The "next" name becomes the view name.  Any leftover path elements 
become a "subpath".  It really is just block and tackle graph traversal of 
there's nothing tricky going on.

  > 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 don't agree, but it's probably not really worth talking about.  Any API is 
probably unreasonable when you squint at it hard enough.

> 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.

I suspect it's simpler than you think it is.

may clear things up.

> 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.

Stack still blown,

- C
Repoze-dev mailing list

Reply via email to