z3c.form - extraction from sequence widget
Hi, In z3c.form.widget.SequenceWidget, we have: def extract(self, default=interfaces.NOVALUE): """See z3c.form.interfaces.IWidget.""" if (self.name not in self.request and self.name+'-empty-marker' in self.request): return [] value = self.request.get(self.name, default) if value != default: for token in value: if token == self.noValueToken: continue try: self.terms.getTermByToken(token) except LookupError: return default return value This means that if the request contains the empty-marker only (no selection was made) for a checkbox widget (say), then the return value is [], rather than default (NOVALUE). Is that a bug? I have a custom checkbox widget derived from the standard checkbox widget, (z3c.formwidget.query, in fact), and I never get any "required missing" exceptions, even when I untick all the checkboxes and click OK. Am I missing something? Cheers, Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
On Wednesday 27 August 2008, Martin Aspeli wrote:
This means that if the request contains the empty-marker only (no selection was made) for a checkbox widget (say), then the return value is [], rather than default (NOVALUE).
Is that a bug? I have a custom checkbox widget derived from the standard checkbox widget, (z3c.formwidget.query, in fact), and I never get any "required missing" exceptions, even when I untick all the checkboxes and click OK.
Am I missing something?
I think you have a point. Have you tried changing the behavior to return "default" and see what tests fail? If no major failures come out of this, I would say change it. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter"
On Wed, Aug 27, 2008 at 05:15:48PM -0700, Stephan Richter wrote:
On Wednesday 27 August 2008, Martin Aspeli wrote:
This means that if the request contains the empty-marker only (no selection was made) for a checkbox widget (say), then the return value is [], rather than default (NOVALUE).
Is that a bug? I have a custom checkbox widget derived from the standard checkbox widget, (z3c.formwidget.query, in fact), and I never get any "required missing" exceptions, even when I untick all the checkboxes and click OK.
Am I missing something?
I think you have a point. Have you tried changing the behavior to return "default" and see what tests fail? If no major failures come out of this, I would say change it.
Wait a second, maybe I'm misunderstanding this, but I certainly oppose any change that would make an unchecked checkbox an error during form validation. A required Bool field can have two values: True or False. One is represented by a checked checkbox, the other by an unchecked checkbox. An unchecked checkbox is not missing input and should not trigger "required missing" errors. Marius Gedminas -- As easy as 3.14159265358979323846264338327950288419716
Am Donnerstag 28 August 2008 02:35:28 schrieb Marius Gedminas:
On Wed, Aug 27, 2008 at 05:15:48PM -0700, Stephan Richter wrote:
On Wednesday 27 August 2008, Martin Aspeli wrote:
This means that if the request contains the empty-marker only (no selection was made) for a checkbox widget (say), then the return value is [], rather than default (NOVALUE).
Is that a bug? I have a custom checkbox widget derived from the standard checkbox widget, (z3c.formwidget.query, in fact), and I never get any "required missing" exceptions, even when I untick all the checkboxes and click OK.
Am I missing something?
I think you have a point. Have you tried changing the behavior to return "default" and see what tests fail? If no major failures come out of this, I would say change it.
Wait a second, maybe I'm misunderstanding this, but I certainly oppose any change that would make an unchecked checkbox an error during form validation.
A required Bool field can have two values: True or False. One is represented by a checked checkbox, the other by an unchecked checkbox. An unchecked checkbox is not missing input and should not trigger "required missing" errors.
I see this the same way - in my application I have a similar case (Accept some policy by a checkbox-click). I solved this simply by checking the value in the action handler and raising a WidgetExecutionError if it is unchecked. Best Regards, Hermann -- hermann@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7
Hermann Himmelbauer wrote:
Am Donnerstag 28 August 2008 02:35:28 schrieb Marius Gedminas:
On Wed, Aug 27, 2008 at 05:15:48PM -0700, Stephan Richter wrote:
On Wednesday 27 August 2008, Martin Aspeli wrote:
This means that if the request contains the empty-marker only (no selection was made) for a checkbox widget (say), then the return value is [], rather than default (NOVALUE).
Is that a bug? I have a custom checkbox widget derived from the standard checkbox widget, (z3c.formwidget.query, in fact), and I never get any "required missing" exceptions, even when I untick all the checkboxes and click OK.
Am I missing something? I think you have a point. Have you tried changing the behavior to return "default" and see what tests fail? If no major failures come out of this, I would say change it. Wait a second, maybe I'm misunderstanding this, but I certainly oppose any change that would make an unchecked checkbox an error during form validation.
A required Bool field can have two values: True or False. One is represented by a checked checkbox, the other by an unchecked checkbox. An unchecked checkbox is not missing input and should not trigger "required missing" errors.
I see this the same way - in my application I have a similar case (Accept some policy by a checkbox-click). I solved this simply by checking the value in the action handler and raising a WidgetExecutionError if it is unchecked.
The notion of a "required" boolean field is a bit weird anyway. I think you *could* interpret it so that a boolean field that's required really means "you have to tick this box" (e.g. an "I agree to these terms and conditions" type scenario). To put it the other way - how would you have a non-required boolean field represented by a checkbox? You really need three states then: True False and None, which you can't get with a checkbox. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
Am Donnerstag 28 August 2008 23:55:24 schrieb Martin Aspeli:
Hermann Himmelbauer wrote:
Am Donnerstag 28 August 2008 02:35:28 schrieb Marius Gedminas:
On Wed, Aug 27, 2008 at 05:15:48PM -0700, Stephan Richter wrote:
On Wednesday 27 August 2008, Martin Aspeli wrote:
This means that if the request contains the empty-marker only (no selection was made) for a checkbox widget (say), then the return value is [], rather than default (NOVALUE).
Is that a bug? I have a custom checkbox widget derived from the standard checkbox widget, (z3c.formwidget.query, in fact), and I never get any "required missing" exceptions, even when I untick all the checkboxes and click OK.
Am I missing something?
I think you have a point. Have you tried changing the behavior to return "default" and see what tests fail? If no major failures come out of this, I would say change it.
Wait a second, maybe I'm misunderstanding this, but I certainly oppose any change that would make an unchecked checkbox an error during form validation.
A required Bool field can have two values: True or False. One is represented by a checked checkbox, the other by an unchecked checkbox. An unchecked checkbox is not missing input and should not trigger "required missing" errors.
I see this the same way - in my application I have a similar case (Accept some policy by a checkbox-click). I solved this simply by checking the value in the action handler and raising a WidgetExecutionError if it is unchecked.
The notion of a "required" boolean field is a bit weird anyway.
I think you *could* interpret it so that a boolean field that's required really means "you have to tick this box" (e.g. an "I agree to these terms and conditions" type scenario).
My idea is to look at it bottom-up: Think about schemas without widgets at all, e.g. in a totally different non-zope/form scenario. To my mind, it's obvious, that required="True" means, that some sort of value has to be given and not, that the value has to be of a specific type (e.g. "True" for Boolean).
To put it the other way - how would you have a non-required boolean field represented by a checkbox? You really need three states then: True False and None, which you can't get with a checkbox.
Well, and then there's the representation of fields by widgets. And, right, it's impossible to provide no value via a checkbox or a radio-box offering "yes/no". And, yes, this somehow obsoletes the "required" constraint. But isn't this perfectly normal for widgets? For instance, a Choice, which is represented by a drop-down widget, will also never return None. Btw., it is possible to have a three-state widget for booleans, such as a drop-down widget, that includes "True/False/None", although it may not make much sense. Best Regards, Hermann -- hermann@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7
Hi Hermann
Betreff: Re: [Zope-dev] z3c.form - extraction from sequence widget
[...]
I think you *could* interpret it so that a boolean field that's required really means "you have to tick this box" (e.g. an "I agree to these terms and conditions" type scenario).
My idea is to look at it bottom-up: Think about schemas without widgets at all, e.g. in a totally different non-zope/form scenario. To my mind, it's obvious, that required="True" means, that some sort of value has to be given and not, that the value has to be of a specific type (e.g. "True" for Boolean).
To put it the other way - how would you have a non-required boolean field represented by a checkbox? You really need three states then: True False and None, which you can't get with a checkbox.
Well, and then there's the representation of fields by widgets. And, right, it's impossible to provide no value via a checkbox or a radio-box offering "yes/no". And, yes, this somehow obsoletes the "required" constraint. But isn't this perfectly normal for widgets? For instance, a Choice, which is represented by a drop-down widget, will also never return None.
Btw., it is possible to have a three-state widget for booleans, such as a drop-down widget, that includes "True/False/None", although it may not make much sense.
No that's not possible! Because you can't save anything then False or True in a Bool field. That means the first time if no value is given the Bool field could return None as default=None. Which indicates that if missing_value=None is used the input is missing. But.... it is not valid to do that! Why? In some use case: zope.schema.Bool( required=True, default=None, missing_value=None) will raise exceptions. But why? If this field get used for a global configuration and will apply the defualt value if nothing get defined and the valdation get invoked, then this is will raise a validation error during zope start up and zope will not start. I think it's always bad idea to use default=None for Bool fields. Because of it's invalid defaults. Some background; Let me explain how the schema and the different field attribute combination work. If a field defines: required=True That means you must provide input if you store a value. But what means input for the field? This is defined in: missing_value='foo' That means everything except 'foo' is input. But doesn't mean that everything is valid input. the missing_value marker is a very important concept. It defines if input is given. This makes it possible to use None or False as input (doens't matter if valid or not) The widget and also the field has validation methods for find out if a value is valid or not which get in use if you store something. In general I think if an attribute should provide states like - selected - not selected - no yet set and at least a given state could set back to *not yet set* after the state was set. A boolean with a Bool field is defently the wrong type for such an attribute. If you like to do so, you need to define a choice which you can choose form and use another HTML input component then a single checkbox input or two radio (yes, no) elements. Hermann, can you you give me a short description of the problem what this thread describes and what is missing in z3c.form? If there is a real problem in the behavior or a missing widget I like to fix that. But right now I don't really understand the real problem. Sorry but I didn't follow the full mail thread. Regards Roger Ineichen
Best Regards, Hermann
-- hermann@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7 _______________________________________________ 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 )
Hi Roger,
Btw., it is possible to have a three-state widget for booleans, such as a drop-down widget, that includes "True/False/None", although it may not make much sense.
No that's not possible! Because you can't save anything then False or True in a Bool field.
Really? How is this different to having a not-required Int, Float, TextLine or whatever field, with no default? Do they then semantically default to 0, 0.0, "" etc, or are they expected to be None? My assumption is that they're None when not explicitly set.
I think it's always bad idea to use default=None for Bool fields. Because of it's invalid defaults.
I guess that depends on whether you think "not set" means "invalid". In SQL, for example, any field type can accept NULL (unless the column is defined NOT NULL). Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
Hi Martin
Betreff: Re: [Zope-dev] z3c.form - extraction from sequence widget
Hi Roger,
Btw., it is possible to have a three-state widget for booleans, such as a drop-down widget, that includes "True/False/None", although it may not make much sense.
No that's not possible! Because you can't save anything then False or True in a Bool field.
I was a little bit unclear. I meant that the widget can't save back None as a new value after True/False was set.
Really? How is this different to having a not-required Int, Float, TextLine or whatever field, with no default? Do they then semantically default to 0, 0.0, "" etc, or are they expected to be None? My assumption is that they're None when not explicitly set.
Yes, you are right the default is set to None like any other field which doesn't define something else. The problem is, if you use a widget and the widget uses None as an option e.g. True/False/None for act as (True, False and not set) then the field validation whould not allow to set anything then True or False as a value. The initial value could be None, but after set to True or False this initial (None) state can't get set again. That's sometimes useful but sometime not.
I think it's always bad idea to use default=None for Bool fields. Because of it's invalid defaults.
I guess that depends on whether you think "not set" means "invalid". In SQL, for example, any field type can accept NULL (unless the column is defined NOT NULL).
I see your point, None is often use as an indicator for a not set value. I'm not so sure if this is a good concept for any use case. I use that concept too im my projects for Bool fields. But I also use some Choice fields with explicit (True/False/None) values for allow to reset a already set value. What I tried to say is: None is a possible inital value but this value is invalid for Bool fields. If the goal is to indicate a *not set value* then we are fine. If you set the field to require=True and that's fundamental part of your business logic, then it could end in a nightmare because of the invalid default. At least if the application will access the field value before someone changed that to a valid value. Regards Roger Ineichen
Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
_______________________________________________ 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 )
On Thu, 2008-08-28 at 22:55 +0100, Martin Aspeli wrote:
Hermann Himmelbauer wrote:
Am Donnerstag 28 August 2008 02:35:28 schrieb Marius Gedminas:
On Wed, Aug 27, 2008 at 05:15:48PM -0700, Stephan Richter wrote:
On Wednesday 27 August 2008, Martin Aspeli wrote:
This means that if the request contains the empty-marker only (no selection was made) for a checkbox widget (say), then the return value is [], rather than default (NOVALUE).
Is that a bug? I have a custom checkbox widget derived from the standard checkbox widget, (z3c.formwidget.query, in fact), and I never get any "required missing" exceptions, even when I untick all the checkboxes and click OK.
Am I missing something? I think you have a point. Have you tried changing the behavior to return "default" and see what tests fail? If no major failures come out of this, I would say change it. Wait a second, maybe I'm misunderstanding this, but I certainly oppose any change that would make an unchecked checkbox an error during form validation.
A required Bool field can have two values: True or False. One is represented by a checked checkbox, the other by an unchecked checkbox. An unchecked checkbox is not missing input and should not trigger "required missing" errors.
I see this the same way - in my application I have a similar case (Accept some policy by a checkbox-click). I solved this simply by checking the value in the action handler and raising a WidgetExecutionError if it is unchecked.
The notion of a "required" boolean field is a bit weird anyway.
I remember Windows UI introducing 3-state-checkboxes back in ... uuh ... I think I saw it with Delphi 2. They had the ability to say unchecked, checked and grey meaning: the user didn't say anything.
I think you *could* interpret it so that a boolean field that's required really means "you have to tick this box" (e.g. an "I agree to these terms and conditions" type scenario).
To put it the other way - how would you have a non-required boolean field represented by a checkbox? You really need three states then: True False and None, which you can't get with a checkbox.
Actually that shouldn't be None. It's more that the attribute wouldn't be set in the first place as None can't be globally used as a marker for 'no user input'. Christian -- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1 Zope and Plone consulting and development
Marius Gedminas wrote:
On Wed, Aug 27, 2008 at 05:15:48PM -0700, Stephan Richter wrote:
On Wednesday 27 August 2008, Martin Aspeli wrote:
This means that if the request contains the empty-marker only (no selection was made) for a checkbox widget (say), then the return value is [], rather than default (NOVALUE).
Is that a bug? I have a custom checkbox widget derived from the standard checkbox widget, (z3c.formwidget.query, in fact), and I never get any "required missing" exceptions, even when I untick all the checkboxes and click OK.
Am I missing something? I think you have a point. Have you tried changing the behavior to return "default" and see what tests fail? If no major failures come out of this, I would say change it.
Wait a second, maybe I'm misunderstanding this, but I certainly oppose any change that would make an unchecked checkbox an error during form validation.
A required Bool field can have two values: True or False. One is represented by a checked checkbox, the other by an unchecked checkbox. An unchecked checkbox is not missing input and should not trigger "required missing" errors.
What about the case when you have a list of options of which you need to chose one or more? In that case, ticking none is a validation error. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
Am Donnerstag 28 August 2008 10:14:11 schrieb Martin Aspeli:
Marius Gedminas wrote:
On Wed, Aug 27, 2008 at 05:15:48PM -0700, Stephan Richter wrote:
On Wednesday 27 August 2008, Martin Aspeli wrote:
This means that if the request contains the empty-marker only (no selection was made) for a checkbox widget (say), then the return value is [], rather than default (NOVALUE).
Is that a bug? I have a custom checkbox widget derived from the standard checkbox widget, (z3c.formwidget.query, in fact), and I never get any "required missing" exceptions, even when I untick all the checkboxes and click OK.
Am I missing something?
I think you have a point. Have you tried changing the behavior to return "default" and see what tests fail? If no major failures come out of this, I would say change it.
Wait a second, maybe I'm misunderstanding this, but I certainly oppose any change that would make an unchecked checkbox an error during form validation.
A required Bool field can have two values: True or False. One is represented by a checked checkbox, the other by an unchecked checkbox. An unchecked checkbox is not missing input and should not trigger "required missing" errors.
What about the case when you have a list of options of which you need to chose one or more? In that case, ticking none is a validation error.
Yes, in your case this should give a validation error. However, the case where someone uses a checkbox for a True/False operation is at least as common. And if "no ticking" gives a validation error, this would prevent using checkboxes for this case. Moreover, a checkbox is typically used to represent a "Bool" schema (by default it's a choice widget, I think), so that fits well, I think. My suggestion would be to: - Create some schema field, e.g. "MultipleChoice": colors = MutlipleChoice(title='Colors', values=['red', 'green', 'blue'], default=['green', 'blue'], required=True) - Register a widget for this field, which is then rendered as a bunch of checkboxes. Best Regards, Hermann -- hermann@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7
On Thu, Aug 28, 2008 at 05:26:20PM +0200, Hermann Himmelbauer wrote:
Am Donnerstag 28 August 2008 10:14:11 schrieb Martin Aspeli:
What about the case when you have a list of options of which you need to chose one or more? In that case, ticking none is a validation error.
Yes, in your case this should give a validation error. However, the case where someone uses a checkbox for a True/False operation is at least as common. And if "no ticking" gives a validation error, this would prevent using checkboxes for this case. Moreover, a checkbox is typically used to represent a "Bool" schema (by default it's a choice widget, I think), so that fits well, I think.
My suggestion would be to:
- Create some schema field, e.g. "MultipleChoice":
colors = MutlipleChoice(title='Colors', values=['red', 'green', 'blue'], default=['green', 'blue'], required=True)
colors = Set(type=u"Choose your favourite colors", value_type=Choice(values=['red', 'green', 'blue']), min_length=1)
- Register a widget for this field, which is then rendered as a bunch of checkboxes.
I think there is a multi-selection widget based on checkboxes, that works on Sets of Choices. It's not the default widget (the default is a multi-selection list box), and while it is registered as being valid for sets, it always tries to store a list in the content object. I'm writing from memory, so I may have gotten some details wrong. Marius Gedminas -- The typewriter was invented by Hungarian immigrant Qwert Yuiop, who left his "signature" on the keyboard. -- "Kim"
Am Donnerstag 28 August 2008 17:45:58 schrieb Marius Gedminas:
On Thu, Aug 28, 2008 at 05:26:20PM +0200, Hermann Himmelbauer wrote:
Am Donnerstag 28 August 2008 10:14:11 schrieb Martin Aspeli:
What about the case when you have a list of options of which you need to chose one or more? In that case, ticking none is a validation error.
Yes, in your case this should give a validation error. However, the case where someone uses a checkbox for a True/False operation is at least as common. And if "no ticking" gives a validation error, this would prevent using checkboxes for this case. Moreover, a checkbox is typically used to represent a "Bool" schema (by default it's a choice widget, I think), so that fits well, I think.
My suggestion would be to:
- Create some schema field, e.g. "MultipleChoice":
colors = MutlipleChoice(title='Colors', values=['red', 'green', 'blue'], default=['green', 'blue'], required=True)
colors = Set(type=u"Choose your favourite colors", value_type=Choice(values=['red', 'green', 'blue']), min_length=1)
Yes, so it already exists, then. Best Regards, Hermann -- hermann@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7
Hermann Himmelbauer wrote:
Am Donnerstag 28 August 2008 10:14:11 schrieb Martin Aspeli:
Marius Gedminas wrote:
On Wed, Aug 27, 2008 at 05:15:48PM -0700, Stephan Richter wrote:
On Wednesday 27 August 2008, Martin Aspeli wrote:
This means that if the request contains the empty-marker only (no selection was made) for a checkbox widget (say), then the return value is [], rather than default (NOVALUE).
Is that a bug? I have a custom checkbox widget derived from the standard checkbox widget, (z3c.formwidget.query, in fact), and I never get any "required missing" exceptions, even when I untick all the checkboxes and click OK.
Am I missing something? I think you have a point. Have you tried changing the behavior to return "default" and see what tests fail? If no major failures come out of this, I would say change it. Wait a second, maybe I'm misunderstanding this, but I certainly oppose any change that would make an unchecked checkbox an error during form validation.
A required Bool field can have two values: True or False. One is represented by a checked checkbox, the other by an unchecked checkbox. An unchecked checkbox is not missing input and should not trigger "required missing" errors. What about the case when you have a list of options of which you need to chose one or more? In that case, ticking none is a validation error.
Yes, in your case this should give a validation error. However, the case where someone uses a checkbox for a True/False operation is at least as common. And if "no ticking" gives a validation error, this would prevent using checkboxes for this case. Moreover, a checkbox is typically used to represent a "Bool" schema (by default it's a choice widget, I think), so that fits well, I think.
My suggestion would be to:
- Create some schema field, e.g. "MultipleChoice":
colors = MutlipleChoice(title='Colors', values=['red', 'green', 'blue'], default=['green', 'blue'], required=True)
- Register a widget for this field, which is then rendered as a bunch of checkboxes.
We already have such a field - it's an ICollection field with a Choice value_type. I suspect that we just need widget.SequenceWidget in z3c.form to have a special case for len(self.terms)==1, i.e. it's a checkbox with only one option, or maybe a special case for a BooleanField, or indeed have different widgets for Boolean and ICollection fields. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
On Thursday 28 August 2008, Martin Aspeli wrote:
I suspect that we just need widget.SequenceWidget in z3c.form to have a special case for len(self.terms)==1, i.e. it's a checkbox with only one option, or maybe a special case for a BooleanField, or indeed have different widgets for Boolean and ICollection fields.
Widgets should not make these sort of decisions. I think this is the responsibility of the data converter. I am pretty sure that writing more specific data converters will solve our problem. Thoughts? Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter"
Stephan Richter wrote:
On Thursday 28 August 2008, Martin Aspeli wrote:
I suspect that we just need widget.SequenceWidget in z3c.form to have a special case for len(self.terms)==1, i.e. it's a checkbox with only one option, or maybe a special case for a BooleanField, or indeed have different widgets for Boolean and ICollection fields.
Widgets should not make these sort of decisions. I think this is the responsibility of the data converter. I am pretty sure that writing more specific data converters will solve our problem.
In the implementation of extract() in the SequenceWidget(), the extract() method does this: def extract(self, default=interfaces.NOVALUE): """See z3c.form.interfaces.IWidget.""" if (self.name not in self.request and self.name+'-empty-marker' in self.request): return [] value = self.request.get(self.name, default) if value != default: for token in value: if token == self.noValueToken: continue try: self.terms.getTermByToken(token) except LookupError: return default return value It's the 'return []' that's the problem, i.e. it's treating the return value when empty-marker is in place as something other than the 'default' that the base widget class will use when the field isn't in the request: def extract(self, default=interfaces.NOVALUE): """See z3c.form.interfaces.IWidget.""" return self.request.get(self.name, default) I think to get those same semantics for sequence fields, we'll need something in the extract() method. I also don't quite understand why we use [] and not NOVALUE, even when the field isn't required. It seems to me that the BooleanField case is the special case. In fact, it's somewhat weird that a BooleanField, which is scalar, should default to using a SequenceWidget. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
Martin Aspeli schrieb:
Marius Gedminas wrote:
On Wed, Aug 27, 2008 at 05:15:48PM -0700, Stephan Richter wrote:
On Wednesday 27 August 2008, Martin Aspeli wrote:
[...]
Wait a second, maybe I'm misunderstanding this, but I certainly oppose any change that would make an unchecked checkbox an error during form validation.
A required Bool field can have two values: True or False. One is represented by a checked checkbox, the other by an unchecked checkbox. An unchecked checkbox is not missing input and should not trigger "required missing" errors.
What about the case when you have a list of options of which you need to chose one or more? In that case, ticking none is a validation error.
Use "min_length = 1" and the Field will raise TooShort. ..Carsten
On Wednesday 27 August 2008, Marius Gedminas wrote:
I think you have a point. Have you tried changing the behavior to return "default" and see what tests fail? If no major failures come out of this, I would say change it.
Wait a second, maybe I'm misunderstanding this, but I certainly oppose any change that would make an unchecked checkbox an error during form validation.
A required Bool field can have two values: True or False. One is represented by a checked checkbox, the other by an unchecked checkbox. An unchecked checkbox is not missing input and should not trigger "required missing" errors.
Good point. I am going to watch the discussion a little more. :-) Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter"
participants (8)
-
Carsten Senger -
Christian Theune -
Hermann Himmelbauer -
Marius Gedminas -
Martin Aspeli -
Roger Ineichen -
Stephan Richter -
Stephan Richter