cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antonio Gallardo <>
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 Tue, 08 Aug 2006 15:22:39 GMT

I understand the concerns and I agree to keep the binding framework 
backward compatible. It is important for our current user base moving 
from older cocoon versions. Usually, adding a new attribute for handling 
the new required behavior is the way how we have been resolving this 
things before, hence I don't see why in this case will not be fixed this 

Best Regards,

Antonio Gallardo.

Marc Portier escribió:
> Jean-Baptiste Quenot wrote:
>> Hello Marc,
>> I understand your  concern.  Here is the reply I  made on the JIRA
>> issue:
>> Just my opinion but this XML-based CForms binding API has a number
>> of inconsistencies and bugs. I doubt that  we will ever be able to
>> find a  syntax that  fits all use-cases. I'd  advise to  write the
>> binding  using <fb:javascript>  or  <fb:java> which  is much  more
>> reliable.
> .. or even: don't use the binding framework and write proper
> cform-instance-traversal code in custom classes or flowscript :-)
>> Reverting the  changes will give  back date fields  initialized to
>> 1970-01-01.  On the contrary, your use case is very specific.
> Hm, I don't think we should revert the changes (I don't see where I
> might have suggested that) as I believe there is room for coping with
> both use cases.
> I am trying to decide what would be the best way to achieve that.
> Apart from that I agree that the most 'common' use case deserves to
> drive the decision for the 'default' behavior.
> (mind though that I currently value my 'text-node' in that respect
> higher then the 'date-parsing' case, but YMMV)
> Coming back to that original date issue in fact I'm afraid I don't get
> it yet completely? At which time is this 'org.w3c.util.DateParser'
> active?  How does this become a problem of the binding?
> regards,
> -marc=

View raw message