Form validation: default values

[Franck Routier]

Hi,

on 20th february 2000 (!!!), 'ilc' made a change to DefaultFormValidator
so that it will call element.getOrigVal() instead of element.getVal()
before validating the resulting value.

Until now, I never used default values on FormElement, so I didn't
notice or care.

But my colleague came accross a case where a default value would be
useful: when using html "disabled" components, the form does not get the
value, even if it is set...

So my use case is I have an immutable field (primary key), I create a
form for it, but I want it to be read only.

Using READONLY is only supported by text fields. Others can be modified,
but the modification is not taken into account. Ugly.

Using DISABLED. But then I can't get back the value... So What I want to
do is set the value (for displaying it), set the default value, and get
back the default value when validating.

So basically the modification is the following:

1) current behaviour: if the default value is set, it is never taken
into account on form validation, and you only get access to it when
calling getDefaultValue on the form element..... I think this is
useless.
Also validators apply on OrigVal, not parsed value.

2) proposed change: if the default value is set, it is taken into
account unless another value was set. Validators apply to parsed value,
or to default value if none was input.


The other side effect is that the validator will apply on the parsed
value, not the original value the user has input. This obviously could
have an effect on existing code. On the other side, it seem more
relevant to me. Doing so does NOT break any unit test, but it might
break some code somewhere...
For example, with a not null validator and a default value, if the user
input nothing, you'll get an exception now, but after the change, the
default value will be taken into account, so no exception. But it is
what a default value is meant to, isn't it ?

SO I think the current code is broken from 2000-02-20, I propose to
change it back to a more coherent state. But as it has been the way it
is for a long time, some of you might depend on the broken behaviour.
So, is anyone against the proposed change ?

Franck

PS: Don't hesitate to ask if I'm not clear.




--
Barracuda mailing list
Barracuda@...
http://www.ow2.org/wws/lists/projects/barracuda

[Jacob Kjome]

Hi Franck,

As Diez mentioned, Barracuda could probably use an overhaul while staying true
to its core concepts.  There's probably more instances than this one where
Barracuda's behavior might be considered broken.  My view is that some of
these "broken" or poorly defined behaviors keep new users from trying
Barracuda.  I can't imagine we've picked up many new users in the last few
years given other frameworks that have better kept up with the times.

I hope existing users will speak up and make it known whether proposed changes
would break their applications, as well as mention whether they actually plan
to keep up with new versions or just stick with an old version.  I suspect the
latter is probably the majority case at this point.

Unless users speak up against changes (within a reasonable amount of time), I
encourage you to make changes, even breaking ones, where the benefit is clear
and will ceate well defined behavior.  Of course, make sure there is test
coverage to make sure well defined behavior isn't broken later.


Jake

On Mon, 21 Jul 2008 18:59:44 +0200
  Franck Routier <franck.routier@...> wrote:

> Hi,
>
> on 20th february 2000 (!!!), 'ilc' made a change to DefaultFormValidator
> so that it will call element.getOrigVal() instead of element.getVal()
> before validating the resulting value.
>
> Until now, I never used default values on FormElement, so I didn't
> notice or care.
>
> But my colleague came accross a case where a default value would be
> useful: when using html "disabled" components, the form does not get the
> value, even if it is set...
>
> So my use case is I have an immutable field (primary key), I create a
> form for it, but I want it to be read only.
>
> Using READONLY is only supported by text fields. Others can be modified,
> but the modification is not taken into account. Ugly.
>
> Using DISABLED. But then I can't get back the value... So What I want to
> do is set the value (for displaying it), set the default value, and get
> back the default value when validating.
>
> So basically the modification is the following:
>
> 1) current behaviour: if the default value is set, it is never taken
> into account on form validation, and you only get access to it when
> calling getDefaultValue on the form element..... I think this is
> useless.
> Also validators apply on OrigVal, not parsed value.
>
> 2) proposed change: if the default value is set, it is taken into
> account unless another value was set. Validators apply to parsed value,
> or to default value if none was input.
>
>
> The other side effect is that the validator will apply on the parsed
> value, not the original value the user has input. This obviously could
> have an effect on existing code. On the other side, it seem more
> relevant to me. Doing so does NOT break any unit test, but it might
> break some code somewhere...
>For example, with a not null validator and a default value, if the user
> input nothing, you'll get an exception now, but after the change, the
> default value will be taken into account, so no exception. But it is
> what a default value is meant to, isn't it ?
>
> SO I think the current code is broken from 2000-02-20, I propose to
> change it back to a more coherent state. But as it has been the way it
> is for a long time, some of you might depend on the broken behaviour.
> So, is anyone against the proposed change ?
>
>Franck
>
> PS: Don't hesitate to ask if I'm not clear.
>
>

--
Barracuda mailing list
Barracuda@...
http://www.ow2.org/wws/lists/projects/barracuda