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

[Martijn Faassen]

Brandon Craig Rhodes wrote:
> Martijn Faassen <faassen at startifact.com> writes:
> 
>> I disagree. megrok.trails is a major philosophical change, while
>> this codifies a pattern we've seen in current Grok applications.
> 
> True; but note that the megrok.trails TrailHead object can be attached
> anywhere, to any object, in an app, and that once a Trail has been
> followed, old-fashioned traversal takes over again.

I didn't know about this; that makes it quite a bit more flexible and my 
'recomposing applications' argument doesn't work against megrok.trails.

> Your other arguments are good ones, especially about traversable
> attributes being not-really-about ORMs.  I suppose I'm just wary about
> adding yet another way of traversing, and worried that we're going to
> wind up with seven or ten different ways for traversal to happen by
> the time Grok is really finished.  Right now, when Grok goes across
> objects it detects at least:
> 
>  - Container lookup (object['foo']).
>  - A traverse() method on an object.
>  - A Traverser() class whose context is the current object.
>  - A view, if we are at the last element of the URL.
> 
> As of this morning (and maybe I just need to re-read your new
> handbook/whatever-it's-called!), I couldn't even tell you in which
> order the above methods are detected, or in which cases they combine
> safely (I *think* you can have both a View and container lookup
> working at the same time?) and in which cases they trump each other (I
> *think* that having a traverse() method turns off container lookup?).

I can understand your worry. It's not in the docs yet and I don't know 
the details off the top off my head either. We need to straighten out 
the semantics (though my lack of knowledge of the current 'what trumps 
what' semantics hasn't really bothered me a lot yet in practice). I do 
think we do need docs for this. It helps that you can trump view lookup 
by adding @@.

Anyway, we should be about codifying patterns, and this 'traverse()' 
pattern (and container misuse) is very common in at least my code.

[snip]
>> class App(grok.Model):
>>     grok.traverse('person')
>>     grok.traverse('account')
>>
>>     def __init__(self):
>>          self.person = PersonContainer()
>>          self.account = AccountContainer()
> 
> What if, in addition to "person" and "account", they have two or three
> traversal targets that need to be implemented in code?  Can they
> combine the above with a traverse() method?  Or will the rule be that
> they can either grok.traverse(), or have a traverse() method, but not
> both?

I don't know, we need to look at the tests. :)

[snip]
> So if this really cool idea gained support, we would have *six* ways
> of resolving what a "/foo" at the end of a URL could mean.

I think it's interesting to consider the use of @grok.traversable as a 
decorator on methods. That doesn't take away the use of grok.traversable 
for attributes as well.

Note that I believe the current implementation does work with methods, 
but it looks like this

class Foo(grok.Model):
     grok.traversable('foo')

     def foo(self):
         return Bar()

I think a decorator looks nicer.

Regards,

Martijn