<div>On Sat, May 3, 2008 at 9:51 AM, Wichert Akkerman <<a href="mailto:wichert@wiggy.net" target="_blank">wichert@wiggy.net</a>> wrote:<br></div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm looking at megrok.trails and comparing it with routes to see what<br>
their differences are. I'm interested in trying to use routes itself in<br>
zope, if needed with some grok sauce. Routes is used by several popular<br>
python web frameworks and I think it can be useful to have a consistent<br>
approach across frameworks.<br>
<br>
megrok.trails is much simpler than routes. It does not support things<br>
like named routes, wildcards, groupings, defaults, requirements,<br>
conditions, filters, etc. Since most of those are only rarely used that<br>
is not a problem.<br>
<br>
There are some conceptual differences: Routes is heavily based around<br>
the concept of ``controllers`` classes which have ``action`` methods.<br>
Matched routes end up instantiating a controller and calling an action<br>
method on it. This method returns the response and ends the publication<br>
process.<br>
<br>
In the zope world things work differently so this model does not quite<br>
fit. The megrok.trails approach is to use routes (which it calls trails)<br>
to find a class to use and instantiates that, optionally with a list of<br>
named parameters determined by the traversed URL. In grok terms that<br>
means it returns a model, where routes would return a (rendered) view.<br>
<br>
To me returning a view instead of a model makes more sense. I'ld like to<br>
hear some opinions from others.<br>
<br>
Wichert.<br></blockquote><div><br></div><div><br></div><div>two cents,</div><div><br></div>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.<div>
<br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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. </div>
<div> </div><div>and a tidbit from jim fulton yesterday on the irc channel..</div><div><p style="margin: 0.0px 0.0px 0.0px 119.0px; text-indent: -119.0px; font: 12.0px Courier; color: #4c4c4c">"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."</p>
<p style="margin: 0.0px 0.0px 0.0px 119.0px; text-indent: -119.0px; font: 12.0px Courier; color: #4c4c4c"><br></p><p style="margin: 0.0px 0.0px 0.0px 119.0px; text-indent: -119.0px; font: 12.0px Courier; color: #4c4c4c">cheers,</p>
<p style="margin: 0.0px 0.0px 0.0px 119.0px; text-indent: -119.0px; font: 12.0px Courier; color: #4c4c4c"><br></p><p style="margin: 0.0px 0.0px 0.0px 119.0px; text-indent: -119.0px; font: 12.0px Courier; color: #4c4c4c">kapil</p>
<p style="margin: 0.0px 0.0px 0.0px 119.0px; text-indent: -119.0px; font: 12.0px Courier; color: #4c4c4c"><br></p></div></div></div>