cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <>
Subject cforms incompatibility in 2.1.9 (was [Fwd: [jira] Reopened: (COCOON-1687) [PATCH] JXPATHBinding : when saving the form, remove xml elements if the value of the widget is null])
Date Tue, 08 Aug 2006 08:11:07 GMT
Hi there,

being late on upgrading some cforms sites I recently noticed an
incompatibility introduced in cocoon 2.1.9

since I'm unsure about the best way to handle, I just reopened the
jira-issue that ported the patch which led us here

     [ ]

this follow up, tries to poll for some suggestions on the topic.

in pre 2.1.9 times this would work:

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

and have an xml that looks like this:
<elem x="a" y="b />

then just round-tripping load-save of this through the binding would
just work,

since the mentioned fix however the effect of the 'null' in the 'text'
field is that the complete element gets removed (since that executes the
removePath() on ".")

In short term people can work around this by updating the binding to
something like:

<fb:context path="elem">
  <fb:value id="x" path="@x" />
  <fb:value id="y" path="@y" />
  <fb:value id="text" path="." direction="load"/>
  <fb:javascript id="text" path="." direction="save">
      if (widget.getValue() != null)

In the long term however, I'm still unsure what cocoon should be doing.

It is my feeling that the round-tripping behavior is quite normal to
expect, and current behavior is from that respect more a bug then only
an incompatible change.

As such my recommendation would be to change back to the default
behavior (and possibly break compatibility again)

My original idea therefor was to enable the requested feature through
the introduction of some new attribute @remove-if-null on the fb:value
binding. (defaulting to 'false')

Possibly we could also be inspecting the value of @path to decide if we
should remove or not. That might make our changes look less
incompatible, but all options I've considered down this path seem to
lead to solutions that tend to hide some magic which possible confuses
users more:

* don't remove if path.equals(".")
   but then we would get different behavior depending on whether the
binding would be using fb:context or not

* only remove if path.charAt(0) == '@' (attribute-paths)
   sounds acceptable, but is bound to introduce some confusion when
binding to java-bean objects where this distinction is rather
artificial, no?

Any suggestions or remarks?

Marc Portier                  
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                          

View raw message