Sylvain Wallez wrote:
Hi all,
Trying to catch up some late reading (yep, nearly one week!), I found some questions related to early validation of widget values. Firstly, I
I explicitely let this message wait until I had some time and focus to get into it, too bad it took much more time to organize that then I expected myself, sorry for that
fixed the problem (introduced just before 2.1.4 was released): validation occured at each and every readFromRequest(), which was obviously not the expected behaviour! From now on, we're back to validation being done only when validate() is called, and also on getValue().
I'm the one who introduced this validation on getValue(), but maybe not the way it should be. So let me explain where it came from and let's discuss it.
Type safety is an important feature of CForms: the application doesn't have to deal with strings sent in the request, but only with object types such as date and integers.
yep
Now what about "value safety"? When writing some application code that relies on the form values (event listeners, binding, etc), widgets should return only correct values, i.e. values that are not only syntactically correct (according to the converter), but also semantically correct (according to the validators). Or else, we have the risk for the application to fail badly simply because it used incorrect values.
yep, I even think the same holds for the aspect of event-handling: the programmatically set value could possibly be triggering widget-effects local to the form
Now how do we solve this? A solution is that widget.getValue() not only does the parsing, but also the validation, and therefore returns a non-null value if and only if the input value is successfully parsed and validated.
above assumes that returning 'null' yields a valid state, no?
failing as fast as possible I would suggest there is a setValue version that tells the binding something's rotten, this would allow the binding to handle it
This is what is done in Field, with the side effect that calling getValue() may set a validation error on the widget even if validate() wasn't explicitely called. This side effect is interesting: for example, if an event listener couldn't do its job because of a wrong input, the offending input is automatically shown to the user. This is examplified in the "number fields" section in the "flow1.form" sample.
yep, good example
Now this behaviour can also lead to premature flagging of widgets that may not be wanted. An example of this is in the carselector sample (see event listeners in the form definition) where we must reset the "make" widget value to null because a "getValue" can set a validation error if the user chose the null value.
So, although validation _must_ occur when getValue() is called, we may
I'm still doubthing... I'm tending towards a view where the value wasn't _set_ until validation happened.
maybe a split between the 'unvalidatedValue' and the 'value' (much like between enteredValue and value today) offers us a better base to react on all requirements (don't see yet how... I'm still trying to understand)
want getValidationError() to return null until validate() has actually been called.
So the two possible behaviours are:
- as of today (with the fix), have validation errors as the side effect of getting the value.
which sounds odd from a distance?
- raise the validation error only if validate() was called, even if getValue() does the actual call to the validators.
to me it's still a surprise that getValue does that
That second solution will require event-listeners to manually call validate() if ever they want to show errors on the widgets they act upon to the user.
as would be the case for the binding?
we seem to state that value-setting should be distinct from triggering validation-error-raising, but it seems odd that the end-user of the interface should (even could) decide for this explicitely?
wild thought: maybe there should be a specific accessor object passed rather then the widget itself
What do you think?
not sure yet, I'm currently trying to get all angles of the issue in one view, lacking that here and now deprives me from the comfortable feeling that would allow me to make any statements
I see more and more how our widgets are often 'pretending' to be in a different state then they declare through the getting of their properties, resulting in different semantics behind the same properties depending on who's asking at what time. I any specific case it's often quite visible why this is, it just doesn't help clarity in general
regards, -marc= -- Marc Portier http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog at http://blogs.cocoondev.org/mpo/ [EMAIL PROTECTED] [EMAIL PROTECTED]
