[Grok-dev] Re: What would a megrok.z3cform (and a
Zope2/plone.z3cform equivalent) look like?
Fernando Correa Neto
fcdoth at gmail.com
Tue Aug 5 12:35:41 EDT 2008
On Tue, Aug 5, 2008 at 11:36 AM, Martijn Faassen <faassen at startifact.com> 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 believe that the only issue so far is setting up the layers so you
can access all z3c.form components.
> 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.
Here is Stefan Richter input:
fcorrea srichter, hi. Is there a special reason on why everything in
z3c.form is registered for IFormLayer and not for , say,
srichter fcorrea: yeah
srichter fcorrea: default browser layer is full of stuff that I have
no or little control over
srichter in my apps, I never ever base a skin on default browser layer
> 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.
In my tests a form is just a ordinary view and is grokked as such..
I assume static is also present.
> 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.
Well, having it to work is a 4 step task and I think people can easily remember.
The steps are:
1) Add z3c.form and it's dependencies in setup.py;
2) run ./bin/buildout;
3) Setup layer;
4) Setup add/edit forms;
I think that can easily be documented (there is actually a work in
progress on the howto).
> 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.
I think they are very similar and one can easily associate the setup
of a z3c.form with a zope.form equivalent. The extra bits in the
add/edit form right now are the grok.laywer() and grok.context()
directives. The rest is pretty much z3c.form default methods.
A add form would look like this:
fields = field.Fields(IAinterface)
def create(sefl, data):
# create the object and apply data
def add(self, object):
# persist the object
And a edit form would look like this:
fields = field.Fields(IAinterface)
@button.buttonAndHandler(u'Apply and View', name='applyView')
def handleApplyView(self, action):
if not self.widgets.errors:
It doesn't hurt that much does it?
More information about the Grok-dev