[Grok-dev] Re: Grok Widgets / Fields (Was Re: Re: [grok-br] Grok
1.0 and beyond)
faassen at startifact.com
Thu Jan 10 07:45:26 EST 2008
Fernando Correa Neto wrote:
> On Jan 8, 2008 4:52 PM, Martijn Faassen <faassen at startifact.com> wrote:
>> Fernando Correa Neto wrote:
>>> 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
Then again, zope.formlib is very nice when you do model-driven
development, ala CRUD.
More information about the Grok-dev