[Grok-dev] Grok 1.0 final?
faassen at startifact.com
Wed Apr 15 04:02:51 EDT 2009
Wichert Akkerman wrote:
> 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
>> - 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.
> 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.
More information about the Grok-dev