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= -- Marc Portier http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog at http://blogs.cocoondev.org/mpo/ [EMAIL PROTECTED] [EMAIL PROTECTED]
