[Grok-dev] post 1.0 Grok development wishlist
faassen at startifact.com
Wed Oct 7 15:50:03 EDT 2009
Martin Aspeli wrote:
> Martijn Faassen wrote:
>> * related to this, exploring a step towards more explicit directives,
>> less implicit rules. We could experiment with a megrok.explicit
>> extension which requires a lot more directives to be present.
> What are the benefits of this? What type of changes would this involve?
Two main reasons:
The first reason: We've noticed that in cases of inheritance, the
interactions between directives and default behavior can be very hard to
get right/explain. We see this issue especially in grokcore.view. That's
at least a danger sign.
We've also noticed there are two kinds of defaults:
* defaults which really are equivalent to the directive being on the
baseclass. I.e. grok.require('zope.View'), whatever the default layer
story is for grok.layer, etc.
* defaults which are calculated and depend on the existence of things in
the Python code and the existence of certain directories. grok.context
is an example, and so is grok.templatedir if auto-calculated, etc.
The second reason: at least JW at THA feels more explicit works better
in multi-person projects, as opposed to using the rules. Because I value
JW's opinion a lot, that's at least interesting input. :)
A related topic is that we want to explore other patterns of organizing
templates and resources instead of all stuffing them in _templates
directories (and the resources all in static or, in case of
hurry.resource my pattern is _resources).
Please note that I at this point am not convinced that we *should* get
rid of the more complicated default directives, but I want there to be
an extension that explores this topic, and see how it all feels.
>> * ZTK integration. Grok and grokcore.* should use the ZTK packages, not
>> Zope 3.4 anymore.
> This is the one I find most exciting. :) Getting Grok onto ZTK would
> hopefully inject some more momentum into the ZTK effort, and make it
> easier to re-use components across Grok, five.grok, Plone and other
Yes, the Grok project practically pushed the ZTK project into existence
earlier this year, so we're definitely interested in this. I'd very much
like to see a Grok that uses a lot less packages than it does today,
because it'll be easier to manage and easier to explain. And also
because I have BFG envy. :)
More information about the Grok-dev