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

[Fernando Correa Neto]

Hey!

On Mon, Aug 4, 2008 at 7:34 PM, Martin Aspeli <optilude at gmx.net> wrote:
> 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)


That can be done easily. Check
http://mail.zope.org/pipermail/grok-dev/2008-July/005999.html for
quick prototyping of a Add/Edit form.

We discussed this briefly today on IRC on what it might be. Some think
that just pushing the base classes for Add/Edit/Display forms would be
enough but some others might desire some more boiler plate code like
registering all z3c.form widgets for IDefautBrowserLayer intead of
IFormLayer.
That would reduce the need of explicitly mark your layer with z3c.form ones.

>
> and maybe also:
>
>  - EditSubForm
>  - Groups (actually, I'm not sure we need this)


Actually I think groups are a good thing. Some times you just want to
split your form in some smaller pieces and groups very nice for that.


>  - 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).


Right. I am not sure if one can register a template factory using
plain grok.Adapter.  Worth trying it out though.


>
> 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.


Well, I think that if you manage to register your template using
adapters for example, you might be able to use , say, 'static' because
either AddForm and EditForm subclass grok.View.
I "naively" tried doing that because I know that everything that
subclass grok.View will be traversable.
In terms of Plone, if  view and layers works in there, then I think
the simple approach would work without any problems.

>
> 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.


Well, I believe the basic form generation that is documented in
z3c.form works ok. The example is based on the z3c.formdemo/message
package and worked by just subclassing grok.View and adding some grok
directives to make it fulfil the contract with grok.
Unfortunately I didn't have time to fully experience trying to
register new template factories, data managers etc, and then I can't
tell we can apply what's documented 100%.


>
> 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.


How grokcore.view works in Plone? I am not sure but I think that if
you just try something like:


class FooForm(form.AddForm, grok.View):
    grok.layer(ISomeFormLayer)
    grok.context(yourcontext)
    grok.name('addDocument')


If plone is already groking views, I think it would grok this form as well.


>
> 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?

How does it gets grokked? I assume IFoo is just the interface that is
going to provide the context and the fields but I have no idea how the
grokker would look at it.


Regards,
Fernando