Hi all

> Betreff: Re: [Zope3-Users] z3c.form - howto ignore the 
> context for singlewidgets in an Edit form?
> On Friday 08 February 2008, Hermann Himmelbauer wrote:
> > What's your opinion on this, Stephan?
> 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.
> 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:
> class ConfirmationWidget(...)
>    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)
>     return widget
> 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:

class ISubscribeSchema(zope.interface.Interface):
    """The subscription form."""

    password = zope.schema.Password(
        description=_(u'The password for the applicant.'),

    confirm = zope.schema.Password(
        title=_(u'Confirm password'),
        description=_(u'The password for the principal.'),

    def confirmPassword(task):
        if task.password != task.confirm:
            raise zope.interface.Invalid(
                _("Password doesn't compare with password confirmation."))
        if len(task.password) < 6:
            raise zope.interface.Invalid(
                _("Password must be at least 6 characters long."))

class SubcriptionForm/form.Form):
    """Subscription form."""

    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.

Roger Ineichen

> Regards,
> Stephan

Zope3-users mailing list

Reply via email to