Hi,
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
way.
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=
