You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Tobias Bocanegra <to...@day.com> on 2008/01/19 22:31:02 UTC

empty string handling in the ujax post servlet

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.

I think all the above could be handled with a default value hint:
./myProp@DefaultValue = ""  --> treat them as empty strings (1).
./myProp@DefaultValue = "ujax:ignore"  --> ignore them (2)
./myProp@DefaultValue = "ujax:null"  --> remove them (3)
./myProp@DefaultValue = "foobar"  --> "normal" default value behavior

where the first would remain the default behavior.

WDYT ?
regards, toby

-- 
-----------------------------------------< tobias.bocanegra@day.com >---
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 >---

Re: empty string handling in the ujax post servlet

Posted by Tobias Bocanegra <to...@day.com>.
> > ...I think all the above could be handled with a default value hint:
> > ./myProp@DefaultValue = ""  --> treat them as empty strings (1).
> > ./myProp@DefaultValue = "ujax:ignore"  --> ignore them (2)
> > ./myProp@DefaultValue = "ujax:null"  --> remove them (3)
> > ./myProp@DefaultValue = "foobar"  --> "normal" default value behavior
> >
> > where the first would remain the default behavior....
>
> I agree with that (although, as Felix notes, lines 1 and 4 are the same thing)
that's what i wanted to say, actually :-)
-- 
-----------------------------------------< tobias.bocanegra@day.com >---
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 >---

Re: empty string handling in the ujax post servlet

Posted by Bertrand Delacretaz <bd...@apache.org>.
On Jan 19, 2008 10:31 PM, Tobias Bocanegra <to...@day.com> wrote:

> ...I think all the above could be handled with a default value hint:
> ./myProp@DefaultValue = ""  --> treat them as empty strings (1).
> ./myProp@DefaultValue = "ujax:ignore"  --> ignore them (2)
> ./myProp@DefaultValue = "ujax:null"  --> remove them (3)
> ./myProp@DefaultValue = "foobar"  --> "normal" default value behavior
>
> where the first would remain the default behavior....

I agree with that (although, as Felix notes, lines 1 and 4 are the same thing)

-Bertrand

Re: empty string handling in the ujax post servlet

Posted by Tobias Bocanegra <to...@day.com>.
On 1/21/08, Felix Meschberger <fm...@gmail.com> 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:
> > ./myProp@DefaultValue = ""  --> treat them as empty strings (1).
>
> Do we need this special definition ? see below
>
> > ./myProp@DefaultValue = "ujax:ignore"  --> ignore them (2)
>
> +1
>
> > ./myProp@DefaultValue = "ujax:null"  --> remove them (3)
>
> +1
>
> > ./myProp@DefaultValue = "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
-- 
-----------------------------------------< tobias.bocanegra@day.com >---
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 >---

Re: empty string handling in the ujax post servlet

Posted by Felix Meschberger <fm...@gmail.com>.
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:
> ./myProp@DefaultValue = ""  --> treat them as empty strings (1).

Do we need this special definition ? see below

> ./myProp@DefaultValue = "ujax:ignore"  --> ignore them (2)

+1

> ./myProp@DefaultValue = "ujax:null"  --> remove them (3)

+1

> ./myProp@DefaultValue = "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

Regards
Felix

> 
> where the first would remain the default behavior.
> 
> WDYT ?
> regards, toby
>