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

[Philipp von Weitershausen]

On 3 Feb 2007, at 16:32 , ct at gocept.com wrote:
>> 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
>
> Uh. Why? IMHO template() would act the same way as the autotemplates()
> would. Meaning: the template 'index' would be 'activated' and if a  
> class
> Index is around then also associated with it.

I'm confused then. How would you write a class that's associated with  
a template?

   grok.template('index')

   class Index(grok.View):
       def update(self):
           ...

or

   class Index(grok.View):
       grok.temlate('index')

       def update(self):
           ...


or simply

   class Index(grok.View):
       def update(self):
           ...

?

>> Where do we have this for adapters and utilities?
>
> http://svn.zope.org/grok/trunk/src/grok/tests/utility/utility.py? 
> rev=71761&view=auto

Ok, fine, we have grok.global_utility. I don't see the need for  
grok.view, grok.adapter, etc. (yet).

>>> 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.
>
> Hmm. True in a sense. I'm not sure subclassing handles the same use- 
> cases.

I would be surprised if it can't handle them. I think we need to play  
with this more and actually try solve some usecases out there before  
we should introduce new concepts and statements.

> Of course we do have to provide the means of configuring the component
> architecture. And I don't think we should disable people to  
> leverage it's
> richness. And that richness does include that registrations are not  
> a 1:1
> mapping of classes to registrations.

That "richness" you're describing isn't given to us by the Component  
Architecture and it's not by any means part of the Component  
Architecture idea. The richness of automagically binding classes and  
templates together happens to be a configuration policy, in Zope 3  
implemented by a ZCML directive handler (which automagically creates  
new classes), in grok partially done by the ViewGrokker.

I'm not particularly keen on introducing lots of grok.do_something()  
directives. Directives are nice when they're not needed often. And  
when they're needed, they should be there to override a certain  
default, or in rare cases, register things (like  
grok.define_permission).

I'd hate to actually introduce a new configuration language with lots  
of verbs.