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 (JIRA)" <ji...@apache.org> on 2008/01/21 16:27:34 UTC
[jira] Created: (SLING-180) ujax post servlet: add @DefaultValue
hint for empty strings
ujax post servlet: add @DefaultValue hint for empty strings
-----------------------------------------------------------
Key: SLING-180
URL: https://issues.apache.org/jira/browse/SLING-180
Project: Sling
Issue Type: Improvement
Components: microsling
Reporter: Tobias Bocanegra
[from http://comments.gmane.org/gmane.comp.apache.sling.devel/1909]
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)
where the first would remain the default behavior.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-180) ujax post servlet: add @DefaultValue
hint for empty strings
Posted by "Tobias Bocanegra (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tobias Bocanegra closed SLING-180.
----------------------------------
> ujax post servlet: add @DefaultValue hint for empty strings
> -----------------------------------------------------------
>
> Key: SLING-180
> URL: https://issues.apache.org/jira/browse/SLING-180
> Project: Sling
> Issue Type: Improvement
> Components: microsling
> Reporter: Tobias Bocanegra
> Attachments: launchpad-r614568.patch
>
>
> [from http://comments.gmane.org/gmane.comp.apache.sling.devel/1909]
> 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)
> where the first would remain the default behavior.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-180) ujax post servlet: add @DefaultValue
hint for empty strings
Posted by "Bertrand Delacretaz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bertrand Delacretaz resolved SLING-180.
---------------------------------------
Resolution: Fixed
Patch applied in revision 614875, thanks!
Created SLING-191 to test the new UjaxPostServlet "move" functionality.
> ujax post servlet: add @DefaultValue hint for empty strings
> -----------------------------------------------------------
>
> Key: SLING-180
> URL: https://issues.apache.org/jira/browse/SLING-180
> Project: Sling
> Issue Type: Improvement
> Components: microsling
> Reporter: Tobias Bocanegra
> Attachments: launchpad-r614568.patch
>
>
> [from http://comments.gmane.org/gmane.comp.apache.sling.devel/1909]
> 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)
> where the first would remain the default behavior.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-180) ujax post servlet: add @DefaultValue
hint for empty strings
Posted by "Tobias Bocanegra (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tobias Bocanegra updated SLING-180:
-----------------------------------
Attachment: launchpad-r614568.patch
fixes:
- add support for @DefaultValue (incl. test)
- cleanup code a bit
- revert "create_node" suffix to *, since issue SLING-159 was fixed
- updated tests to use constant for "create_node" suffix instead of hard coded value
- add support for "move" (probably needs a own issue + tests)
- allow for deleting node and update in the same request
> ujax post servlet: add @DefaultValue hint for empty strings
> -----------------------------------------------------------
>
> Key: SLING-180
> URL: https://issues.apache.org/jira/browse/SLING-180
> Project: Sling
> Issue Type: Improvement
> Components: microsling
> Reporter: Tobias Bocanegra
> Attachments: launchpad-r614568.patch
>
>
> [from http://comments.gmane.org/gmane.comp.apache.sling.devel/1909]
> 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)
> where the first would remain the default behavior.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.