[ http://issues.apache.org/jira/browse/COCOON-1687?page=all ]
Marc Portier reopened COCOON-1687:
----------------------------------
The applied patch introduces an undesired side-effect:
suppose you have a binding that looks like
<fb:context path="elem">
<fb:value id="x" path="@x" />
<fb:value id="y" path="@y" />
<fb:value id="text" path="." />
</fb:context>
and have an xml that looks like this:
<elem x="a" y="b />
then just rountripping load-save of this through the binding will REMOVE the
element since the value of 'text; is set to 'null' and the save-back executes
the removepath() now.
Need to give it more thought, but I'ld suggest
1/ introducing some configuration attribute @remove-if-null="true|false" on the
fb:value to cater for the two possible use -cases.
2/ although that would break compaibility for a 2nd time make the value 'false'
the default.
> [PATCH] JXPATHBinding : when saving the form, remove xml elements if the
> value of the widget is null
> ----------------------------------------------------------------------------------------------------
>
> Key: COCOON-1687
> URL: http://issues.apache.org/jira/browse/COCOON-1687
> Project: Cocoon
> Issue Type: Bug
> Components: Blocks: Forms
> Affects Versions: 2.1.8, 2.2-dev (Current SVN), 2.1.7
> Reporter: Philippe Gassmann
> Attachments: ValueJXPathBinding.java.patch
>
>
> When a form is saved using a JXPathBinding, the xml elements that correspond
> to null widget values must be removed.
> Here is our problem : we have a form containing a "date widget" that is not
> mandatory,
> 1. the user wants to set a value to this widget ex 2005/05/09
> 2. the user save this form
> 3. the user does not want the date to be set anymore (why ? why not !)
> 4. the user edit the value removing its content (ie the value of the widget
> will be null)
> 5. the user save the form
> 6. when the user wants to view what's happened, he see : the element
> containing the value of the date is present, if he loads the form again he
> found : 1970-01-01 in the date field (the org.w3c.util.DateParser return this
> value if empty string its given).
> In general, it has no sense for kind of data (integer, float, date...) to
> have three "state" : empty, null and filled with a value !
> So here is a patch to correct this :
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
