[Grok-dev] sprint mini-report 6 (last day wrapup)

Brandon Craig Rhodes brandon at rhodesmill.org
Mon May 5 09:08:12 EDT 2008

Martijn Faassen <faassen at startifact.com> writes:

> If you want to be in on any of these topics, or want to propose
> other larger topics, please let us (or at least the driver) know.

I'm likely to be "driving", in the sense of continuing to post about,
the big issue of traversing when there is no hierachical database
behind Grok like the ZODB, and about what we should do as the number
of traversal rules and traversal shortcuts continues to grow and grow.
I am still considering the posts that were made this weekend about
Routes, which included the (correct) observation someone made that
integrating Routes would essentially mean adopting an alternative to
the adapter-based views we have now - since, obviously, if the Route
selects *both* the model and the view, then there's no role left for
adapters, traversal-wise.

Of course, this is a necessary property of Routes, since it's designed
for frameworks without adapters at all; it's a separate and competing
methodology for hooking models and views together.  When I designed my
little Trails experiment, I deliberately left normal Grok adaptation
as the way one hooks a view to the model, but there's no reason we
have to do this.  It could be argued that, when writing URL recipes,
adaptation is a pretty silly way of hooking views to models - a
symptom of our having a hammer (adapters) and wanting to use that
hammer even where it's overkill.

The beauty of adapter-based views, I think, really shines in the
context of something like a CMS, where, say, a Folder can appear
several levels deep at any location on the site.  This is quite
different from an RDB application, where you typically design exactly
one canonical URL pattern for each object; if every Person object
lives at a URL "/person/<id>", then one might as well go ahead and
define the possible views along with the URL.

But despite that, I still like the idea of having Trails just select
the model, so that Trails-based Grok applications will still look like
Grok and not like something else. :-)

Hmm.  Well, drat.  This was supposed to be a post *about* posting
about URL traversal in the future, not a post about URL traversal.
Anyway, my only points are that this issue is of great concern to me;
it seems to have been a topic of conversation at the sprint; and that
by continuing the discussion I'll hope to be serving the community and
not just distracting them from other issues. :-)

Brandon Craig Rhodes   brandon at rhodesmill.org   http://rhodesmill.org/brandon

More information about the Grok-dev mailing list