Jean-Baptiste Quenot wrote: > * Marc Portier: > >> 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? > > CForms was generating <date></date>, which is not a valid date. > It is interpreted as time 0. This is when binding a date widget.
Well, I still don't get it Not a valid date for who? Some back-end processing the xml afterwards? I've just done a small test which shows cforms is perfectly happy to bind to some <date /> or <date></date> in the xml... I also find no references to this mentioned org.w3c.util.DateParser in the cocoon code-base, I couldn't even find it in any of the jars we distribute... (actually outside cocoon the only references I've found to it so far are jigsaw and some css-validator) As things stand I can't help getting more and more - unsure about what the actual motivation for this change was, - convinced that the chosen resolution which makes fb:value not maintain the xml structure is actually way too drastic - close to doubting we should even support this date-issue -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]
