[Grok-dev] What would a megrok.z3cform (and a
Zope2/plone.z3cform equivalent) look like?
optilude at gmx.net
Tue Aug 5 12:40:00 EDT 2008
Martijn Faassen-2 wrote:
> Hi there,
> I'd like to look at this from the perspective of someone who doesn't
> know much about z3c.form for a bit.
> What I'd like to see for megrok.z3cform is:
> * I can very easily create a form. This means there's a tutorial
> somewhere that tells me what to do.
> * I don't have to worry about dependencies - if I get megrok.z3cform
> into my app it'll get me the right versions of whatever z3c.form needs
> * there's a focus on reducing the amount of manual setup to the minimum.
> This means we focus on getting the basic use case for setting up an
> add form or edit form down to the minimum.
> I hear for instance z3c.form needs a special layer for some reason. One
> question is: "why?".
It certainly doesn't with plone.z3cform and Zope 2. :-) This definitely
shouldn't be necessary for a "plain Grok" use case either.
> Once that is answered, we can think about the best
> way to make this work with our code. We could for instance make life
> easier by adding everything to the default layer, but z3c.form isn't
> doing this layer thing for nothing, so perhaps there's a much better way.
> I think it'd be all right if megrok.z3cform imported some commonly used
> bits of z3c.form into itself, so that they're easier to use. Perhaps
> this is far too much stuff though, in which case we need to think about
> which bits we really care about supporting for the 90% case.
z3c.form certainly has thought about imports and patterns, which is why I'm
a bit wary of re-thinking them too much. You do:
from z3c.form import form, field, group, button
and then you use things like form.AddForm, field.Fields(), group.Group or
button.buttonAndHandler(). Flattening the namespace may just cause confusion
and break with conventions for other z3c.form forms.
> I'd want a z3c.form-based view to behave like a grok view; so I expect
> url() to be there, and static to work, etc.
Okay. I'm not sure how often you really need this, i.e. how often you make
custom templates, but fair enough. The only thing here is that you need
Grok-specific base classes for every base class that z3c.form has, or you
need to use multiple inheritance.
> This suggests to me the
> introduction of a new base classes for EditForm, AddForm etc in
> megrok.form anyway, which also helps answering the import question.
I think having to maintain a parallel base class hierarchy is a bit of a
shame, and breaks existing z3c.form documentation in a way, but it's
probably not so bad.
> I see quite a bit of discussion about implementation strategies, but I'd
> like to get some "user interface" questions answered too. Perhaps it's a
> good idea to start with some mockup code that people would have to write
> when they *use* megrok.z3cform, then discuss it, adjust it, and then see
> about making it work.
> The goal is not to make people think too much when using z3c.form in the
> basic case, and not requiring people they wire up a lot of things to see
> the basic case work, while not hiding any of the advanced usages of
> z3c.form. This smoothens out the learning curve.
> I think it makes sense to at least consider how Grok manages formlib in
> this integration, but it also makes perfect sense not to follow this
> model where z3c.form diverges from it in an important way.
Agree. Consistency is important here.
View this message in context: http://www.nabble.com/What-would-a-megrok.z3cform-%28and-a-Zope2-plone.z3cform-equivalent%29-look-like--tp18821220p18835037.html
Sent from the Grok mailing list archive at Nabble.com.
More information about the Grok-dev