[Grok-dev] trails vs routes

[Kapil Thangavelu]

On Sat, May 3, 2008 at 9:51 AM, Wichert Akkerman <wichert at wiggy.net> wrote:

> I'm looking at megrok.trails and comparing it with routes to see what
> their differences are. I'm interested in trying to use routes itself in
> zope, if needed with some grok sauce. Routes is used by several popular
> python web frameworks and I think it can be useful to have a consistent
> approach across frameworks.
>
> megrok.trails is much simpler than routes. It does not support things
> like named routes, wildcards, groupings, defaults, requirements,
> conditions, filters, etc. Since most of those are only rarely used that
> is not a problem.
>
> There are some conceptual differences: Routes is heavily based around
> the concept of ``controllers`` classes which have ``action`` methods.
> Matched routes end up instantiating a controller and calling an action
> method on it. This method returns the response and ends the publication
> process.
>
> In the zope world things work differently so this model does not quite
> fit. The megrok.trails approach is to use routes (which it calls trails)
> to find a class to use and instantiates that, optionally with a list of
> named parameters determined by the traversed URL. In grok terms that
> means it returns a model, where routes would return a (rendered) view.
>
> To me returning a view instead of a model makes more sense. I'ld like to
> hear some opinions from others.
>
> Wichert.
>


two cents,

if your working on relational project, i find using routes tends to make
more sense that standard object publishing, in the sense that object
publishing against with foreign key traversal, tends to involve a query per
depth of url.
the routes package in particular i've found to be a bit
inscrutable/temperamental, on inputs and outputs, ie. it tends to fail
silently and mysteriously on what it might consider bad inputs. i think the
selector wsgi package is a cleaner and reusable as an implementation of the
routes concept.

there are consequences to a routes application, in that as a framework, zope
tends to assume and use parent pointers, for various things like security,
and url determination. at a minimum you'll need to define an absoluteurl
adapter.

i think grok.trails does a really nice job of offering some the  routes
functionality within the zope framework, it still object publishing in  that
its constructing parent pointers, so default security/url determination
works. in some sense, its more like wormholes through the url, to get from a
start to destination object, where the last view traversal still matches
against the object.

and a tidbit from jim fulton yesterday on the irc channel..

"J1m- So, for example, a publication's getApplication method could use this
API to consume the traversal stack, doing the traversal itself.  The object
it returns could then be the result of that traversal."


cheers,


kapil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.zope.org/pipermail/grok-dev/attachments/20080503/4b7d0e53/attachment.html