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

Martijn Faassen faassen at startifact.com
Tue Aug 5 10:36:59 EDT 2008

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?". 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 mailing list