[Framework-Team] Re: DataGridField for z3c.form?

Carsten Senger senger at rehfisch.de
Thu Sep 10 18:07:11 UTC 2009

Hi Wichert,

--On Donnerstag, September 10, 2009 16:27:14 +0200 Wichert Akkerman
<wichert at wiggy.net> wrote:


> class IInformationLink(Interface):
>      """A link to more information related to a risk."""
>      url = schema.URI(
>              title = _(u"URL"),
>              required = True)
>      description = schema.TextLine(
>              title = _(u"Description"),
>              required = False)

As with formlib (and IIRC similar to Archetypes) I use a TextLine with an
isUrl constraint (validator) that (in my case) checks for http or https
(but that's a matter of taste and use case) and throws an Error message
tailored to my users.

It is one of the nice features of z3c.form that you can register you own
error snippets (even different snippets for different forms, layers etc).
But it's enough to write an contraint and throw an exception:

    badge_url = TextLine(

def isHttpURL(value):
    if ...:
        return True
        raise UrlException

class UrlException(zope.schema.ValidationError):
    __doc__ = u"""Please use a valid url like http://ploneconf2009.org"""


> and that finally works. The lessons I have learned from this are:
> - z3c.form produces very awful HTML

It can be enhanced. At the same time it's partly a matter of z3c.form, but
the zope 2 and plone integration packages.

> - z3c.form produces very confusing user interfaces

What's missing here (speaking for what a framework can provide) is a border
around each object and a border around all objects. z3c.form doesn't do it
as it does not provide additional resources like css or images, it's not
written as part of an application. The zope/plone integration packages are
written for z3c.form 1.9 which doesn't contain an object widget. Using the
MultiWidget with TextLines gives an understandable UI.
Also it's a matter of adoption. Unless someone has the usecase, nobody will
write a customization for something that could be optimized when used in

> - z3c.form documentation is indeed incomplete (no mention of
>    ObjectFactory)

Yes. And it's bad that the documentation is the complete doctest suite for
z3c.form which partly makes it confusing and not very friendly for average
plone developers/integrations. We have to provide plone specific
documentation anyway and have to fill this gap.

But the truth is that it's much better than the formlib documentation.

> - z3c.form you can do cool stuff with it, although I am not convinced
>    it is much better than hand-coding the form

We have the need for auto generated, schema driven forms. Maybe we would
better use  hand written forms at some places, but don't do for various
reasons. But that leaves the rest.

But much of what you tell comes from wrong expectations. If you have a
general framework for autogenerate forms, you can not expect it to produce
the markup and ui that is optimal for your use case. If you want that for
usability reasons, you'd better use handwritten form or, in this case, add
some css if it is enough for your requirements.

Your right that the plone integration package is rough at some points, but
it will only get better if more people use it, especially people that have
a sense for markup and user interfaces. And it will only get a variety of
widget alternatives if it has a bigger user base.
If the framework team allows the usage of z3c.form for the two (?) plips it
does not mean that everybody will do z3c.forms from the next day on. There
will be a long transition phase where we will develop better templates and
add css to make the user experience better. We will also get more z3c.form
documentation on a basic level for developers and integrators to solve the
common use cases.

I'd be against the use of z3c.form if
 * formlib is similarly suited as the general autogenerated form solution
 * z3c.form is too complex for integrators or
 * there is an alternative identifiable that will do a better job for
   schema based autogenerated forms within the next 1 or 2 years.

But I think nothing of this is true.


More information about the Framework-Team mailing list