[Grok-dev] Re: Template directories

[Martijn Faassen]

Hi there,

Brandon Craig Rhodes wrote:
[snip]
> Which, incidentally, we do not have in Grok today; from one Grok app to
> another, there's no way to predict which files define the Models, which
> files define Views (sometimes with the corresponding Models, sometimes
> separate), where the Indexes have been declared (you have to therefore
> search the entire code base to see for which Models there are indexes),
> and where all of the Traversers are that make URLs work if the ZODB is
> not beneath a particular container or objects
[snip]

This is true, we don't have that in Grok today. I'm not sure whether 
it's a good idea, though I've seen it work reasonably well in projects 
like TurboGears.

Zope 3 tried this a long time ago. Probably Zope 3 tried it the wrong 
way, but we had a separate tree for interfaces, and browser subpackages 
for everything. The browser subpackages is something we still have to 
deal with today. I'd much rather have the browser stuff not be there at 
all, in completely different packages. :)

Instead we choose to cluster things around, typically, the context, and 
encourage people to do this by using defaults, though never requiring 
it, as quite frequently you *do* want to add a view or adapter to a 
context from far away. That's also a nice thing about Grok's approach: 
you can always amend an application from far away, you don't have to go 
add things to a particular tree structure.

I wonder how such a pattern would work with a separate tree of 
templates, say. I also agree that since we don't follow it for anything 
else, I'm not sure following it for templates would be a good step forward.

[snip]
> (Or am I entirely wrong?  Is grok.template() inherited?)

Last I heard there were issues with this, but I may be wrong. You can do 
this by registering a master template as a view itself, and then simply 
looking up that view, though. That allows you to specifically override 
the master template for particular views too should you so desire.

> What I like about using the existing rules like this is not only the
> simplicity, but the utter explicitness: you know exactly where to go in
> each case to find something, and never have to look two places.  Thanks
> to the "import" statements and to the fact that the Master template can
> only be one place, everything points back to the resources it uses
> without any ambiguity about where they can be found.

That's an interesting observation. This is only true in one direction 
though (you can find the context from a view, but not vice versa), and 
also only true if interfaces aren't used for indirection. Or, of course, 
at some point the Grok introspector should become so intuitive and easy 
and obvious to use for this purpose people like me will actually think 
of doing it. :)

Regards,

Martijn