[Plone-developers] z3c.form critic Was: Rewrite old cpt forms to new technology like z3cform
Patrick Gerken
> It seems a little silly to even contemplate adding another form
> library to plone at this point. Let's get rid of at least 1 of our
> current ones first.
It indeed seems silly to add a third form framework.
But maybe having two form frameworks for a long time is just a sign
that z3c.form does not get truly adopted?
Personally, I nearly always only use autogenerated z3c.forms. When I
want to customize a widget I most often end up writing a wrapping
widget factory and a wrapped widget, just to modify one attribute in
the widget class. This is silly.
Changing a title attribute they way it is explained on pypi is also
silly: http://pypi.python.org/pypi/z3c.form#changing-widget-attribute-values
The amount of concepts one has to learn to master z3c.form is not in
proportion to the importance of a form library within a web framework.
While it is nice to have simple, autogenerated crud forms for
dexterity content types or for setting schema based registry settings
with plone.registry, it does not solve the problem, that one has to
understand and remember too many concepts for simple form
customizations.
Best regards,
Patrick
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Plone-developers mailing list
Plone-de...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plone-developers
Nathan Van Gheem
z3cform, something else)
As Lawrence has already said, it's good to do other form library
integrations with plone. Maybe we can get to a point where one, other
than z3cform, can be uniformly suggested for add-on developers and
integrations.
However, that does not mean it's desirable to adopt something else for
core right now. Maybe someday...
What's the point of this discussion this anyways? Is anyone even
suggesting we have something better than z3cform that integrates with
zope schemas? Or are we just complaining about z3cform at this point?
FWIW, I can't stand z3cform...
Just for the sake of trying something else, I made collective.wtforms
and was much happier with that crude implementation in plone than most
anything else I've had to mess with in formlib or z3cform...
-Nathan
Jens W. Klein
> On Tue, Mar 13, 2012 at 18:25, Nathan Van Gheem<vang...@gmail.com> wrote:
>> It seems a little silly to even contemplate adding another form
>> library to plone at this point. Let's get rid of at least 1 of our
>> current ones first.
>
> It indeed seems silly to add a third form framework.
> But maybe having two form frameworks for a long time is just a sign
> that z3c.form does not get truly adopted?
It is possibly silly to add another framework. Is it? Since we're far
away from the one-way-to-do-things mantra it may not hurt.
It's ivory-tower thinking if we now force integrators to 'think
z3cforms' before one can change a field title in a Plone form.
I freak out every time if I need to explain z3cforms. It's over and over
complex: ZCA everywhere. Need to write classes for simple things like
adding buttons. Need to learn about schemas and all around to write new
forms. This all for something dumb simple: html-forms and some value
processing afterwards. All far away from beeing pyhtonic.
[...]
> Changing a title attribute they way it is explained on pypi is also
> silly: http://pypi.python.org/pypi/z3c.form#changing-widget-attribute-values
>>> from z3c.form import widget
>>> NameLabel = widget.StaticWidgetAttribute(
... u'Full Name', field=IPerson['name'])
>>> zope.component.provideAdapter(NameLabel, name='label')
We need to factor a WidgetAttribute instance, then we have to provide
this as an named adapter. Even for somebody good in Python but not
educated in ZCA this is without further explanation transparent like a
brick wall and the user probably tends to hit his head against the wall
or turn the back on it. I'am really a fan of decoupling things and ZCA.
But decoupling a label from its widget this way is insane and abuse of ZCA.
Why cant we just have:
>>> IPerson['name'].label = u'New Label'
And this is one of the easiest modifications. Its not this single
example! Read further, next examples at given URL are showing similar
problems.
> The amount of concepts one has to learn to master z3c.form is not in
> proportion to the importance of a form library within a web framework.
+100
> While it is nice to have simple, autogenerated crud forms for
> dexterity content types or for setting schema based registry settings
> with plone.registry, it does not solve the problem, that one has to
> understand and remember too many concepts for simple form
> customizations.
full ack
So now we have z3cforms. The questions is: Can we make it simpler? Can
we reduce the complexity?
If not I have the strong opinion that z3cforms everywhere will massive
elevate the barrier for new users/ integrators. Which at the end will be
bad for Plone overall.
We simply can't afford to get even more complex with Plone.
Jens
--
Klein & Partner KG, member of BlueDynamics Alliance
Laurence Rowe
Well, you can do it that way with adapters, but that's only if you
want a fully generalizable form. Just make the changes during form
update if you want to tweak things (untested).
class MyForm(EditForm):
def update(self):
super(MyForm, self).update()
self.widgets['name'].label = u'New Label'
I generally do most customisation with templates, where the
widgetTemplate directive is really useful.
I really don't think adding another schema based form library is
useful. Of course, not all forms need to be schema based and where
appropriate just use a browser view. But where appropriate, making
them schema based (and eventually making the schemas easily
customisable using plone.supermodel TTW schemas) is a generally good
idea.
Laurence