[Grok-dev] Re: What would a megrok.z3cform (and a
Zope2/plone.z3cform equivalent) look like?
faassen at startifact.com
Tue Aug 5 10:36:59 EDT 2008
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?". 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.
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. 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 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.
More information about the Grok-dev