[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:
> 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',
> -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?
>> 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.
More information about the Grok-dev