[Grok-dev] Re: RFC: Making the automatic registration of
templates more explicit
Philipp von Weitershausen
philipp at weitershausen.de
Sat Feb 3 10:49:40 EST 2007
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
>>> 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
> Index is around then also associated with it.
I'm confused then. How would you write a class that's associated with
>> Where do we have this for adapters and utilities?
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-
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
I'd hate to actually introduce a new configuration language with lots
More information about the Grok-dev