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

[Sylvain Viollon]

On Mon, 04 Aug 2008 23:34:59 +0100
Martin Aspeli <optilude at gmx.net> wrote:

> Hi,
> 

  Hello,

> 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 worked on that yesterday and this morning. You can check:

  http://svn.zope.org/plone.z3cform/branches/infrae-grok/

  That's still an experiment, not a final implementation. As well, I
made it in Silva, so I didn't try in Plone. But there is nothing of
Silva specific, or Plone specific in what I wrote.

> I think it'd be good to support:
> 
>   - AddForm
>   - EditForm
>   - Form (full page form)
> 

  I have them working. Maybe it will be interesting to grokify grouping
feature as well.

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

  The 'static' should work in my experiment. As well, it inherit
grokcore.view.View, so have all grok-like methods ('response',
'redirect', ...) should work as well.

  I don't think I support anymore the layout feature of plone.z3cform,
because, it don't seems to work quite well outside of Plone. (I don't
have the correct main_template for the default layout), but you should
be able to use it maybe.

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

  I don't need anymore that wrapper in the Grok implementation. The
fact is it's hard to grok something like that, since you need to change
grokcore.view to be able to register the view with a wrapper.

> [...]
> 
> 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'
> 


  My implemented pattern is:

  class IMyPage(interface.Interface):

     some_fields ...


  from plone.z3cform.components import EditForm
  from five import grok

  class MyForm(EditForm)
      grok.context(IMyPage)
      grok.name('edit.html')



  Fields are computed like for grok formlib forms. As well, you can
define update() like on a grok to do stuff before your form is
rendered. 

  You can register template for rendering like in z3c.form (using
adapter to IPageTemplate), or like in grok.

  You have to include the `meta.zcml` file of plone.z3cform to enable
the grokification of your forms, so if you don't want it, don't include
it (and plone.z3cform is still compatible with project which don't use
grok).

> Opinions? Suggestions?
> 
> 

   Well, I will be interested to have some feedback on that, it's still
experimentation, but seems to work.

   Best regards,

   Sylvain,

-- 
Sylvain Viollon -- Infrae
t +31 10 243 7051 -- http://infrae.com
Hoevestraat 10 3033GC Rotterdam -- The Netherlands
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://mail.zope.org/pipermail/grok-dev/attachments/20080805/98b47965/signature.bin