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

ct at gocept.com ct at gocept.com
Sat Feb 3 10:32:39 EST 2007


> 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.

>> 1a. To shorten this spelling we could allow grok.template('a', 'b',
>> 'c',
>> ...).
>
> -1 (reason: evolution path, see above)

In my oppinion this wouldn't hurt the evolution path.

> 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

>> 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.
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.

Christian



More information about the Grok-dev mailing list