[Grok-dev] Re: RFC: Making the automatic registration of templates more explicit

[Philipp von Weitershausen]

On 3 Feb 2007, at 16:10 , ct at gocept.com wrote:
> Sorry for catching up so late. I'm trying to remember everything that
> popped up in my mind while reading this thread.
>
> 1. I like grok.template('asdf') on a module level in opposition to
> "consume all templates".

Ok. The only beef I have with it is that the evolution path to a  
template + view isn't very gradual. Say you only have a template,  
index.pt. So you do:

   grok.template('index')

Now you realize you need to compute some stuff in that template, so  
you delete that line again and write:

   class Index(grok.View):

       def update(self):
           self.pi = 3

Having to delete stuff to evolve sucks. I'd rather have empty  
classes, even if they look dead-chicken-y:

   class Index(grok.View):
       pass # rendered by a template


> 1a. To shorten this spelling we could allow grok.template('a', 'b',  
> 'c',
> ...).

-1 (reason: evolution path, see above)

> 1b. We do also have the templatedir() directive right?

Sure.

> 2. I notice that the use of classes for views is not the same as in  
> Zope 3
> itself. In Zope 3, due to a third component that does the view
> registration, a class and a template can be used with multiple  
> instances
> of the opposite thinge (one template for multiple views with different
> classes, one class for multiple views with different templates).  
> Maybe, as
> for the adapters and utilities,

Where do we have this for adapters and utilities?

> we need to come up with a module-level
> grok.view(class=, template=, ...) registration?

Shrug. Please, no. We're bringing back ZCML all over again, only in a  
different wrapper. Less is more. One class and one template per view  
is absolutely ok; if there's a need for consolidating commonly used  
stuff, there's always subclassing. Let people use this "natural" way  
of consolidating things. They don't need to learn extra stuff.

Philipp