Roger Ineichen a écrit :
Betreff: Re: [Zope3-Users] z3c.form - howto ignore the
context for singlewidgets in an Edit form?
On Friday 08 February 2008, Hermann Himmelbauer wrote:
One important design goal for z3c.form is not to be JS
dependent. This is what we developed z3c.formjs for.
Also, remember that a widget is something different in
z3c.form. Taking the E-mail widget example, we still only
have a TextFieldWidget but might have a specific
EMailValidator registered for this widget.
What's your opinion on this, Stephan?
From this point of view, I think it would be cool, if we
could have a ConfirmationWidget, which simply displays
another widget twice. This could then either be a
PasswordWidget or TextFieldWidget. The cool part about it is
that the constructor of the confirmation widget could be
smart to take the passed in field into account.
So here is how I would like this to look:
widget = None # The widget that we want to display twice.
def FieldConfirmationWidget(field, request):
widget = FieldWidget(field, ConfirmationWidget(request))
widget.widget = zope.component.getMultiAdapter(
(field, request), IFieldWidget)
The challenge is to have unique names for the widget and its
confirmation and do all the updating correctly. You probably
also need a custom validator that first compares the two
values to be equal and then forwards the validation.
I would love to see this widget in z3c.form. Of course, I am
also still waiting for the ObjectWidget. :-)
I recommend that we only should include widgets in z3c.form
which are registered for a specific field. Every additional
widget should go into a new z3c.form(yx?) package.
This makes it simpler if it comes to custom widget because
everything which doesn't fit by default given from z3c.form
isn't in the z3c.form package.
what do you think should we start something like
z3c.formwidget.(xy) for new z3c.form widgets? You know
we also can port some widgets form our other projects then.
bwt, I'm back from skiing;-)
My personal favorit for a password widget is an additional
schema which defines a confirmation field and uses this schema
and will setup the widgets explicit. The reason for this
is that the form concept 100% fits the requirements and this
can be done without any magic because Invariant is supported.
Also note that the same password widget is not allways used
within a confirmation field if it comes to login.
Here is some code:
"""The subscription form."""
password = zope.schema.Password(
description=_(u'The password for the applicant.'),
confirm = zope.schema.Password(
description=_(u'The password for the principal.'),
if task.password != task.confirm:
_("Password doesn't compare with password confirmation."))
if len(task.password) < 6:
_("Password must be at least 6 characters long."))
ignoreContext = True
fields = field.Fields(ISubscribeSchema)
Note the form must ignore the context and can not be used
out of the box for edit forms. If you like to use the
pattern above for edit forms which no not ignore the context
you need to define an adapter for your custom schema and the
btw, this is my favorit because any combined
password/confirmation widget implementation
is not consitent if it comes to layout because
two label and input fields get rendered in one
widget row. That could be a pain sometimes.
On the other hand, the password is already used in the definition of the
Principal (ex: in IInternalPrincipal), so you get overlapping definitions of the
password, and you need to explicitly omit() the Principal password in the form
Or maybe you think it's better to use different schemas for the Principal itself
and for the subscription?
Zope3-users mailing list