[Grok-dev] post 1.0 Grok development wishlist

[Martijn Faassen]

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

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

Regards,

Martijn