On 1/21/08, Felix Meschberger <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Am Samstag, den 19.01.2008, 22:31 +0100 schrieb Tobias Bocanegra:
> > hi,
> > the current ujax post servlet writes back all eligible input values to
> > their respective properties. if the input values are empty strings,
> > properties with empty strings are created. i think this behavior is
> > not always desired. absent properties might mean something different
> > than properties with empty strings (null vs. ""). i can imagine the
> > opposite, too. where applications want all properties to be filled in.
> >
> > this problem is even more important when dealing with non-string
> > properties. e.g. a number input which is not filled in, does not
> > automatically mean '0'.
> >
> > there are several ways how to control this behavior:
> > 1) do not include 'empty' values in the post.
> > this requires some javascript preprocessing of the form which removes
> > the empty inputs or mangles their names (i.e. removing the
> > 'saveprefix').
> >
> > 2) ignore empty strings for non-existent, non-mandatory properties.
> > this way, no superfluous properties are created. but the application
> > must be aware of the fact that empty values might not create the
> > properties. if a property is already set, sending an empty string
> > would of course not remove the property but modify its value.
> >
> > 3) treat empty strings as 'null' value
> > this means, that empty strings do not create empty properties and
> > delete existing (non-mandatory) properties.
> >
> Basically I agree, but ...
>
> > I think all the above could be handled with a default value hint:
> > ./[EMAIL PROTECTED] = "" --> treat them as empty strings (1).
>
> Do we need this special definition ? see below
>
> > ./[EMAIL PROTECTED] = "ujax:ignore" --> ignore them (2)
>
> +1
>
> > ./[EMAIL PROTECTED] = "ujax:null" --> remove them (3)
>
> +1
>
> > ./[EMAIL PROTECTED] = "foobar" --> "normal" default value behavior
>
> I would say, that in this case the "foobar" would be taken as the
> DefaultValue (is this already the case today ??) This would alos handle
> the first case of having an empty DefautlValue, thus leaving just three
> cases:
>
> ujax:ignore -> take "empty" string as "don't change current value
> (if any)"
> ujax:null - > take "empty" string as "remove property"
> any thing else -> use provided value for property in case of empty
> string
of course. but we don't have this @DefaultValue in place yet. so this
is the proposal :-)
regards, toby
--
-----------------------------------------< [EMAIL PROTECTED] >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
-----------------------------------------------< http://www.day.com >---
