cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <...@outerthought.org>
Subject Re: 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 Wed, 09 Aug 2006 16:34:40 GMT


Jean-Baptiste Quenot wrote:
> * Marc Portier:
> 
>> The argumentation of  the fix, namely to  make the value-binding
>> remove an element upon 'save'  seems, currently, to be that this
>> avoids after re-'load' some weird  formatting result (from "" to
>> "1/1/1970")  in the  i18n  transformer caused  by some  external
>> date-parser suggested in a patch that isn't applied?
> 
> You  may be  right  that  the date  problem  may  not happen  with
> SimpleDateFormat  because  it is  lenient  by  default.  This  has
> nothing  to do  with the  i18n transformer  however, but  with the
> FormattingDateConvertor.
> 

ok, makes sense

obvious question then of course is why that formatting-convertor
couldn't be made to capture the 'null' and circumvent the replacement to
this '0' 'or 1/1/1970?

> Now it's  up to you to  decide whether empty string  is garbage or
> not.   For me,  it is.   Then your  proposal to  add an  option to
> instruct CForms to remove the XML  node or to leave it empty makes
> sense.
> 

well, I don't think it is garbage at all, it's a hook to add e.g.
attribute-nodes, those have reason of existence regardless of the fact
that there is a nested text-node or not.

suppose you don't have the flexibility to design the input-xml coming
from your backend and it doesn't look like

<dates>
  <startdate />
  <enddate />
<dates>

that can be optionally removed, but actually looks like

<dates>
  <date event="start" />
  <date event="end" />
</dates>

then you'll need to solve your issue differently as well

so I guess even for you it's only garbage in this particular case, no?


> Anyway  I  should have  been  more  careful when  committing  this
> incompatible change,  as you're  right most  Cocoon users  may not
> have been impacted by this problem.

no worries, mate, I'm glad we're taking and finding time and patience to
get to the core of this.


Anyways, this whole process of finding out what and how kind of
convinced me that we can in fact revert the change. (and not add an
attribute)

In the event that somebody might want to remove the element when the
nested text-node would be empty, then he/she should do so through the
nested on-update:

<fb:value id="x" path=".">
  <fb:on-update>
    <fb:javascript direction="save">
     .. the logic to remove the path if new value is null,
    </fb:javascript>
  </fb:on-update>
</fb:value>


I understand that this is more typing then just adding a
@remove-if-null="true" (which was my earlier idea), but it's the kind of
explicitness that both holds more flexibility and fits better my feeling
that the ValueBinding by itself should not be altering the xml structure.


wdyt?


regards,
-marc=
-- 
Marc Portier                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                http://blogs.cocoondev.org/mpo/
mpo@outerthought.org                              mpo@apache.org

Mime
View raw message