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 13:25:40 GMT


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/
mpo@outerthought.org                              mpo@apache.org

Mime
View raw message