[jira] Commented: (COCOON-1758) Form locale never used in JXMacros
[
http://issues.apache.org/jira/browse/COCOON-1758?page=comments#action_12428388
]
Marc Portier commented on COCOON-1758:
--
Adding the svn-update references to ease tracking:
http://svn.apache.org/viewvc?view=revrevision=427436
http://svn.apache.org/viewvc?view=revrevision=430438
Form locale never used in JXMacros
--
Key: COCOON-1758
URL: http://issues.apache.org/jira/browse/COCOON-1758
Project: Cocoon
Issue Type: Bug
Components: Blocks: Forms
Affects Versions: 2.1.8, 2.2-dev (Current SVN), 2.1.9
Reporter: Philippe Gassmann
Assigned To: Antonio Gallardo
Fix For: 2.2-dev (Current SVN), 2.1.10-dev (current SVN)
Attachments: 20060201-cocoon-forms-1758, patch.txt, patch1.txt
The JXMacroHelper is created with : jx:set var=cformsHelper
value=#{org.apache.cocoon.forms.generation.JXMacrosHelper.createHelper($cocoon/consumer,$cocoon/request,$cocoon/parameters/locale)}/
So the locale is get from sitemap parameters.
the locale attribute of the form is then never used.
I will provide a patch as soon as possible
--
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
[jira] Commented: (COCOON-1687) [PATCH] JXPATHBinding : when saving the form, remove xml elements if the value of the widget is null
[
http://issues.apache.org/jira/browse/COCOON-1687?page=comments#action_12427215
]
Marc Portier commented on COCOON-1687:
--
Reverted this patch:
http://svn.apache.org/viewvc?view=revrevision=430378
This patch was shipped with the 2.1.9 release of cocoon.
Because of that, people on that version seeing unwanted removal of elements
during bind-save will need to resort to some sort of workaround.
A typical sample is to replace an ordinary
fb:value id=whatever path=whatever /
with:
fb:value id=whatever path=whatever direction=load/
fb:javascript id=whatever path=whatever direction=save
save-form
if (widget.getValue() != null)
{
jxPathPointer.setValue(widget.getValue());
}
else
{
jxPathPointer.setValue();
}
/save-form
/fb:javascript
[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
[jira] Reopened: (COCOON-1687) [PATCH] JXPATHBinding : when saving the form, remove xml elements if the value of the widget is null
[ 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
