[Grok-dev] Re: sprint mini-report 2

Kevin Smith kevin at mcweekly.com
Fri May 2 13:20:55 EDT 2008

> [snip]
> that, the one time I tried it on a real application back in August, it
> created *horrible* spaghetti code.  When I wanted to debug why the URL
> for, say, an "Account" wasn't working, I had to get a pencil and paper
> and trace through three or four levels of classes, following their
> context() declarations, and looking around throught the source code
> for Traverser() objects and so forth.  It was not at all clear how far
> one has to read through the code (or whether there was a limit at
> all!) to figure out how URLs were constructed. [snip]

I had a similar experience with the spaghtetti-traversal system. To 
fulfill business requirements,
the traversal code became "exponentially" complex and quickly exploded 
into a *nightmarish* furball.

It didn't scale, there were dead chickens everywhere. I gave up trying 
to trace through the levels and
rolled my own traversing mechanism.

If spaghetti-traversal could be stopped easily at points along the way 
and allowed something akin
to Zope2's subpath, IMO even that, would allow better scalablity, which 
is not that far from
setting a TrailHead.

My judgment is that the spaghetti-traversal mechanism hasn't had enough 
real use in the wild to expose
it's shortcomings.

In any case, I think this is an important area of Grok that reequires 
further exploration.

Kevin Smith

(Brandon I think I may have a few ideas to bounce of off you to expand 
megrok.trials, email if you're

More information about the Grok-dev mailing list