[Grok-dev] What would a megrok.z3cform (and a Zope2/plone.z3cform equivalent) look like?

[Martin Aspeli]

Hi,

I'm interested in support page forms, add forms and edit forms based on 
z3c.form and plone.z3cform in Zope 2/CMF/Plone. I am not really able to 
work on a "pure Grok" megrok.z3cform, mainly since I don't have any Grok 
applications to test with or much experience with plain Grok, but I 
think it'd be preferable if, at the very least, the same patterns would 
be applied to plain Grok and Zope 2 use case and, if possible, the two 
shared code.

I think it'd be good to support:

  - AddForm
  - EditForm
  - Form (full page form)

and maybe also:

  - EditSubForm
  - Groups (actually, I'm not sure we need this)
  - Locating per-form templates with Grok template semantics

(Note that it's also possible to register default form layout templates 
with adapters, to get a common look and feel, which I think is actually 
the most common use case).

Looking at the canonical examples from 
http://pypi.python.org/pypi/z3c.form, I think this should be pretty 
straightforward. I could imagine a simple case where we just have 
grokkers for these base classes, and support the usual view directives 
from grokcore.view, specifically name(), require(), layer() and context().

I am not sure if we need a Grok-specific base class. The 
grokcore.view.components.View base class does a few things, like support 
the 'static' resource directory, give a 'response' property, and does 
some template rendering. I think z3c.form already provides a lot of 
convenience APIs and hooks, and I don't think we necessarily need to 
provide specific support for bespoke templates in the way that Grok's 
standard View does.

Now, z3c.form also has a number of namespaced entities and conventions 
of its own, such as support for defining buttons and actions, layout 
templates and so on. These are pretty sensible. One question is whether 
we want to provide convenience imports for most of them, as Grok's 
formlib support does for things like actions. I'm less inclined to do 
so, because it may cause confusion with published z3c.form 
documentation. However, I'm not sure what others would prefer.

Finally, there's an added complexity with plone.z3cform in that it 
relies on a wrapper view that wraps the "plain" z3c.form Form to provide 
the Zope 2 integration. In a way, that's nice, because it keeps custom 
forms "vanilla" z3c.form entities. However, it does mean that it's 
actually this wrapper view that gets registered. There are two ways to 
use it:

  class MyForm(Form):
      fields = field.Fields(IMyForm)
      ...

  class MyFormView(FormWrapper):
      form = MyForm

or:

  MyFormView = wrap_form(MyForm)

The latter approach creates a class on the fly. The key here is that in 
Zope 2 with plone.z3cform, it's actually the MyFormView that needs to be 
registered as the view, not the form class itself.

I would propose that we hide this with plone.z3cform specific grokkers 
that create the wrapper view class and registers it.

Thus, (shared) pattern may be:

  from z3c.form import form, field
  from my.package.interfaces import IFoo

  class FooForm(IFoo):
     grok.name('foo')
     grok.context(IFoo)
     grok.require('zope.View')

     fields = field.Fields(IFoo)

     @button.buttonAndHandler(u"OK")
     def handleOk(self, action):
         print 'ok'

Opinions? Suggestions?


Cheers,
Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book