[Grok-dev] What would a megrok.z3cform (and a Zope2/plone.z3cform
equivalent) look like?
optilude at gmx.net
Mon Aug 4 18:34:59 EDT 2008
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
I think it'd be good to support:
- Form (full page form)
and maybe also:
- 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
fields = field.Fields(IMyForm)
form = MyForm
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
fields = field.Fields(IFoo)
def handleOk(self, action):
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book
More information about the Grok-dev