[Grok-dev] Re: five.grok
Philipp von Weitershausen
philipp at weitershausen.de
Fri Aug 1 05:16:35 EDT 2008
Sylvain Viollon wrote:
> But recently a lot of work have been done on grokcore packages, and
> not everything from grokcore packages are imported in five.grok like
> in grok, I think.
Not yet. five.grok is still a work in progress. Ultimately, the goal of
five.grok is to provide as much of the grok API as possible. If that
weren't the case, we woudln't go through the trouble of splitting Grok
up like that.
>>> Basically, we have to build a grokker which create the form_fields
>>> attribute like for formlib, wrap actions ... We will have to
>>> register the form to the ZCA as view wrapped with the form_wrapper
>>> provided in plone.z3cform.
>> Right. Please let's talk about this. I need this exact same thing for
>> Dexterity, with support for add and edit forms (as well as standalone
>> form views, but that's not really specific to Dexterity). I think
>> plone.z3cform would be a natural place to keep the grokking code.
> If you add the grokking code to plone.z3cform, this going to mean
> that's everybody who want to use z3c.form in Zope 2 will have to either
> use Grok, or if they don't work, rebuild their own support.
I don't understand the last part of the sentence.
Surely, if plone.z3cform contained support for grokkers, it would depend
on martian + grokcore.component. Perhaps even on five.grok since it's a
Zope 2 package. However, that doesn't mean it is *required* to use
plone.z3cform like that. If people preferred, they could still use ZCML
to register views, utilities, adapters, etc.
More information about the Grok-dev