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

[Martijn Faassen]

Hi there,

Fernando Correa Neto wrote:
[snip]
>> 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,
> IDefautBrowserLayer?
> 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

This is interesting. I'd like to get some form of control of this for 
Grok as well, but we're not there yet.

> Well, having it to work is a 4 step task and I think people can easily remember.

The steps are in reality more than 4 steps and more to remember...

> The steps are:
> 
> 1) Add z3c.form and it's dependencies in setup.py;

I have to remember the dependencies of z3c.form myself?

> 2) run ./bin/buildout;
> 3) Setup layer;

And set up my skin so that the layer is included. And make sure 
everything is in this layer. There's a whole extra step of stuff to do 
in my application now just to see a basic form going, whenever I want to 
start using z3c.form.

I preferably don't want to have to do this, though I can see the reasons 
why.

> 4) Setup add/edit forms;

What do I need to subclass from? grok.View, and something from z3c.form?

What is this 'extends' directive for on the edit form that I saw in your 
example before?

> I think that can easily be documented (there is actually a work in
> progress on the howto).

A howto is good!

But please do look at the amount of steps you ask people to take for 
real. I think we can reduce those steps with just a little bit of glue. 
Doesn't have to be much glue.

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

I think we need a grok.lawyer() directive. :)

> directives. The rest is pretty much z3c.form default methods.
> 
> A add form would look like this:
> 
> class MyLayer(z3c.formui.interfaces.IDivFormLayer,
>                                       Z3CFormLayer):
>     pass

These are some imports I need to remember. This can hopefully be glue in 
megrok.z3cform.

> class Z3CFormSkin(grok.Skin):
>     grok.name('MySkin')
>     grok.layer(MyLayer)
>  
> class MyAddForm(megrok.z3cform.AddForm):
>     grok.layer(MyLayer)
>     grok.context(somecontext)
> 
>     fields = field.Fields(IAinterface)
> 
>     def create(sefl, data):
>         # create the object and apply data
> 
>     def add(self, object):
>         # persist the object
> 
>     def nextURL(self):
>         self.redirect('index.html')

We might want to summarize all of this into a single method, like we do 
with formlib based add forms. How do I get to the newly created object 
in nextURL() to generate a URL to it?

> And a edit form would look like this:
> 
> class MyEditForm(megrok.z3cform.EditForm):
>     grok.layer(MyLayer)
>     grok.context(somecontext)
> 
>     fields = field.Fields(IAinterface)
> 
>     @button.buttonAndHandler(u'Apply and View', name='applyView')
>     def handleApplyView(self, action):
>         self.handleApply(self, action)
>         if not self.widgets.errors:
>             self.redirect('index.html')

What is the 'name' bit for in the button? Can I leave that out safely?

What is this self.widgets.errors bit? Why do I need to put in that guard 
there?

Where do I need to import 'field' from? And 'button'?

> It doesn't hurt that much does it?

Not that much, but there's seems to be enough to do yet.

I see you're already presupposing megrok.z3cform base classes, right?

This is also requiring I suddenly type ++myskin++ to get to the forms. 
What if I already have an application which puts stuff in the default 
layer? I suddenly will have to put *everything* in layers and include 
this in the skin. I might need to figure out how to make sure this skin 
is the default one when I browse into the application.

I think the layer bit can be a big stumbling block. For now we can just 
document it and we don't need to solve this for megrok.z3cform, but I'd 
like to think of a way to make the layer story more controllable like 
Stephan wants, without having to type grok.layer() everywhere.

It could hurt a lot less. :) The idea is that with Grok we don't give up 
easily trying to make things more convenient. A little bit of polish and 
convenience here and there can help a lot when people learn new things 
or try to remember things they've already learned. A little bit of 
repetitive code removed in a short example might mean a lot more 
readable code overall in bigger codebases.

Regards,

Martijn