zope.app.form: Make "no value" always available?
zope.app.form items edit widgets don't provide the "no value" value if the corresponding field is required. While this prevents invalid input, it means that e.g. a drop-down box may then have one of the valid values pre-selected. If user forgets to change that value, he could save the form without noticing that the default value is implicitly selected, which may be completely wrong. In some cases it would be preferrable for the widget to default to a "no value" value even if the field is required so the form won't validate if the user doesn't consciously select a value. One of our customers asked for this behaviour, for example. If noone objects, we'd like to change zope.app.form accordingly. -- Thomas Lotze · tl@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development
Thomas Lotze wrote:
zope.app.form items edit widgets don't provide the "no value" value if the corresponding field is required. While this prevents invalid input, it means that e.g. a drop-down box may then have one of the valid values pre-selected. If user forgets to change that value, he could save the form without noticing that the default value is implicitly selected, which may be completely wrong.
In some cases it would be preferrable for the widget to default to a "no value" value even if the field is required so the form won't validate if the user doesn't consciously select a value. One of our customers asked for this behaviour, for example. If noone objects, we'd like to change zope.app.form accordingly.
+1, but perhaps for required fields we shouldn't say "(no value)", we should say "(select a value)".
Hi Thomas
Betreff: [Zope-dev] zope.app.form: Make "no value" always available?
zope.app.form items edit widgets don't provide the "no value" value if the corresponding field is required. While this prevents invalid input, it means that e.g. a drop-down box may then have one of the valid values pre-selected. If user forgets to change that value, he could save the form without noticing that the default value is implicitly selected, which may be completely wrong.
In some cases it would be preferrable for the widget to default to a "no value" value even if the field is required so the form won't validate if the user doesn't consciously select a value. One of our customers asked for this behaviour, for example. If noone objects, we'd like to change zope.app.form accordingly.
I agree with this but... The 2750 test in one of our well tested application will explode. And probably some tests in the zope core and z3c will break too. Since this is a miss behavior and I agree that this should get fixed. We probably should think about a solution which supports the old behavior by default. Note, this whould probably also break other packages like z3c.csvvocabulary. If nobody else objects I'm fine with this changes and will fix a Zope3 revision for this project and start to migrate to z3c.form. We have to do that anyway sometimes. In general, this is not a bug it's just a bad behavior. What do you think? Regards Roger Ineichen
-- Thomas Lotze · tl@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Roger Ineichen wrote:
I agree with this but... The 2750 test in one of our well tested application will explode. And probably some tests in the zope core and z3c will break too.
Since this is a miss behavior and I agree that this should get fixed. We probably should think about a solution which supports the old behavior by default.
Fine with me.
If nobody else objects I'm fine with this changes and will fix a Zope3 revision for this project and start to migrate to z3c.form. We have to do that anyway sometimes.
I don't understand what you're saying here. Are you talking about that application of yours that you've refered to earlier? Who has to migrate to z3c.form, and how does this affect the development of zope.app.form? -- Thomas Lotze · tl@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development
Hi Thomas
Betreff: Re: [Zope-dev] zope.app.form: Make "no value" always available?
[...]
If nobody else objects I'm fine with this changes and will fix a Zope3 revision for this project and start to migrate to z3c.form. We have to do that anyway sometimes.
I don't understand what you're saying here. Are you talking about that application of yours that you've refered to earlier? Who has to migrate to z3c.form, and how does this affect the development of zope.app.form?
Sorry for confusing you. Yes I was talking about our application. Regards Roger Ineichen _____________________________ END OF MESSAGE
Roger Ineichen wrote:
Since this is a miss behavior and I agree that this should get fixed. We probably should think about a solution which supports the old behavior by default.
Note, this whould probably also break other packages like z3c.csvvocabulary.
We've thought about this some more. Our current suggestion is to implement both behaviours using a class attribute for switching, with the base class implementing the new, better one and a subclass setting the attribute differently for BBB. We'd like to register the base class with changed behaviour as the default, though, in order to facilitate adoption of the new and better implementation and provide an override registration for the BBB widget. Applications would then have an easy migration path, having to add only one line of ZCML after the zope.app.form update. Also, we'd like to implement the new behaviour in such a way that the "no value" value isn't shown for required fields that already have a valid value set. What do others think about this? Viele Grüße, Thomas Lotze -- Thomas Lotze · tl@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development
Thomas Lotze wrote:
Roger Ineichen wrote:
Since this is a miss behavior and I agree that this should get fixed. We probably should think about a solution which supports the old behavior by default.
Note, this whould probably also break other packages like z3c.csvvocabulary.
We've thought about this some more. Our current suggestion is to implement both behaviours using a class attribute for switching, with the base class implementing the new, better one and a subclass setting the attribute differently for BBB.
Oh well, it turns out that this doesn't really work well as the class in question is used as a base class by all the items edit widgets. The next-best approach we'd try would be a module-global flag that turns the old behaviour back on and must be set during application start-up for BBB. Would that be an acceptable solution? -- Thomas Lotze · tl@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thomas Lotze wrote:
Thomas Lotze wrote:
Roger Ineichen wrote:
Since this is a miss behavior and I agree that this should get fixed. We probably should think about a solution which supports the old behavior by default.
Note, this whould probably also break other packages like z3c.csvvocabulary. We've thought about this some more. Our current suggestion is to implement both behaviours using a class attribute for switching, with the base class implementing the new, better one and a subclass setting the attribute differently for BBB.
Oh well, it turns out that this doesn't really work well as the class in question is used as a base class by all the items edit widgets. The next-best approach we'd try would be a module-global flag that turns the old behaviour back on and must be set during application start-up for BBB. Would that be an acceptable solution?
+0 if you release it with a new "major" release number (i.e., 3.6.0), and document clearly how to get the BBB behavior. If you need to release with a new "minor" number (i.e., 3.5.1), then the BBB behavior must be the default. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIrE7h+gerLs4ltQ4RAnkaAJ9BsGbe4fgbI04JvcFUZkZavp+NjACaA7Jg D6yo37JOCEcKSt29Ht/Y3qY= =RoWq -----END PGP SIGNATURE-----
Tres Seaver wrote:
Thomas Lotze wrote:
Oh well, it turns out that this doesn't really work well as the class in question is used as a base class by all the items edit widgets. The next-best approach we'd try would be a module-global flag that turns the old behaviour back on and must be set during application start-up for BBB. Would that be an acceptable solution?
+0 if you release it with a new "major" release number (i.e., 3.6.0), and document clearly how to get the BBB behavior. If you need to release with a new "minor" number (i.e., 3.5.1), then the BBB behavior must be the default.
I've done that. Dropdown widgets now display a "no value" item instead of selecting the first option, while select widgets and radio button groups don't need this since they can just leave everything unselected. Also, I've changed SourceSelectWidget so that it doesn't turn its `required` attribute off except in BBB mode. This is no longer useful for SourceDropdownWidgets and seems to have been a bug anyway for SourceSelectWidgets and SourceRadioWidgets. I'll release zope.app.form 3.6.0 tomorrow if nobody objects. If someone gives me access to the package on PyPI (username: tlotze), I can also upload it there. -- Thomas
On Thu, Aug 21, 2008 at 8:45 AM, Thomas Lotze <thomas@thomas-lotze.de> wrote:
If someone gives me access to the package on PyPI (username: tlotze), I can also upload it there.
Done. -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "Chaos is the score upon which reality is written." --Henry Miller
participants (5)
-
Fred Drake -
Philipp von Weitershausen -
Roger Ineichen -
Thomas Lotze -
Tres Seaver