Hi Wichert,
--On Donnerstag, September 10, 2009 16:27:14 +0200 Wichert Akkerman
<wich...@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(
title=u'Website',
required=False,
missing_value=u'',
constraint=isHttpURL,
)
def isHttpURL(value):
if ...:
return True
else:
raise UrlException
class UrlException(zope.schema.ValidationError):
__doc__ = u"""Please use a valid url like http://ploneconf2009.org""";
zope.interface.implements(zope.app.form.interfaces.IWidgetInputError)
[...]
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
plone.
- 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.
..Carsten
_______________________________________________
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team
