AW: [Zope3-Users] z3c.form - howto ignore the context for singlewidgets in an Edit form?

[Christophe Combelles]

Roger Ineichen a écrit :
> 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.
> 
> Stephan,
> 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(
>         title=_(u'Password'),
>         description=_(u'The password for the applicant.'),
>         required=True)
> 
>     confirm = zope.schema.Password(
>         title=_(u'Confirm password'),
>         description=_(u'The password for the principal.'),
>         required=True)
> 
>     @zope.interface.invariant
>     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 
> context.
> 
> 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 
generation.
Or maybe you think it's better to use different schemas for the Principal itself 
and for the subscription?

> 
> Regards
> Roger Ineichen
> 
>> Regards,
>> Stephan
> 
> 
>