[Grok-dev] Grok 1.0 final?

[Martijn Faassen]

Wichert Akkerman wrote:
[snip]
> For the same reason I would rather see that grok does not shadow
> functions such as implements or adapts. I feel it is important that
> people see that these are not grok concepts but Zope component features,
> and the import should reflect that.

Some problems with not shadowing that I see:

* grok's adapter decorator (together with implementer) actually has the 
side effect that it results in configuration, the ones from Zope don't.

* Grok itself tries to make a reasonably simple API available. Due to 
the way it's implemented now, that's aggregating APIs from the various 
grokcore.* packages

>>   - We probably want a simpler view story. The CodeView stuff looks 
>> good. We definitely want Chameleon. Also, we may want a different 
>> template lookup convention: having <module>_templates/*.pt match view 
>> classes means we end up with a lot of files called 'view.pt' and lots of 
>> directories containing only this one file. I think we may prefer to 
>> switch this around, e.g. so we have templates/<context>_view.pt or 
>> similar. I'm not quite sure yet.
> 
> +1
> 
> The current naming in grok has always been a big turnoff for me, and I
> was sad to see it appear in plone dexterity as well. With namespaces and
> eggs we already have too many directories, and this adds even more.

The work to refactor views tries to make them a bit more flexible, 
though templates/<context>_view.pt wouldn't work yet out of the box. It 
should be easier to supply a base view that allows this kind of stuff - 
often people want a pattern with a larger templates directory which 
contains all the templates in a package.

Regards,

Martijn