[Grok-dev] Re: Grok Widgets / Fields (Was Re: Re: [grok-br] Grok 1.0 and beyond)

[Martijn Faassen]

Hey,

Fernando Correa Neto wrote:
> On Jan 8, 2008 4:52 PM, Martijn Faassen <faassen at startifact.com> wrote:
>> Fernando Correa Neto wrote:
>> [snip]
>>> My experience with z3c.form is that is has a lot of
>>> functionality....but very componentized :). Creating conventions for
>>> forms, subforms, fieldgroups, wizards or even buttons would be a
>>> nightmare. But don't let me stop you.
>> Why would it be a nightmare? Can't we start with just exposing some
>> bits, leaving features like, say, wizards until later?
> 
> Like I said, don't let me stop you :). What I meant here is that I
> played with it a bit and it seems very powerful, but requires some
> steps to get those forms going.
> Off course one could create the same grok.EditForm using z3c.form as
> its basis, but I am afraid that in order to set up the forms, some
> more steps would be required and thus making it a "not so grokish" way
> to create components.

It'll definitely be a challenge, but if Grok can do this for the Zope 3 
component architecture we should be able to tackle it for anything. :)

> IMHO, zope.formlib is not bad or limited and nor primitive. Either
> django or tg or whatever python web framework "look" at the model in
> order to generate forms. Zope3/Grok does the same thing.

I agree zope.formlib is not bad or limited. It's a bit messy inside and 
has some limitations that z3c.form doesn't have, but z3c.form isn't a 
*huge* leap forward in functionality.

I'll note that TG's Toscawidgets does not do model inspection. It 
focuses on placing widgets on the web page and whether you generate that 
from a model or not is up to the developer. This has benefits in 
flexibility: I could for instance make a complicated expandable Ajax 
search form with it, and this would've been more of a challenge with 
zope.formlib.

Then again, zope.formlib is very nice when you do model-driven 
development, ala CRUD.

Regards,

Martijn