On 10.11.2004 12:15, Daniel Fagerstrom wrote:
AFAICS we don't need the formatCache in a convertion component, each convertor will only be needed to be defined once. The generateSaxFragment is also somewhat specific for my taste, I wonder if that is part of the convertion concern. Furthermore it has an empty implementation in all the convertors within CForms, so it is hard to see what it is supposed to be good for.
One exception:
http://svn.apache.org/viewcvs.cgi/cocoon/trunk/src/blocks/forms/java/org/apache/cocoon/forms/datatype/convertor/FormattingDateConvertor.java?rev=56582&view=markup
Wasn't carefull enough when I browsed the code obviously.
The convertor params might be needed in the output as it is the case for the DateConvertor. The pattern will be reused in the HTML output for the calendar widget.
I see, for the variant part the most popular idea in the discussion have been for the view to ask for what variant (presentation class) to use. E.g. ${$date#datetime}, meaning give me a string representation of the object in the $date variable using the current locale and the presentation class datetime. As the presentation class is decided in the view template, the template writer can make that info available for the stylesheet also, if needed.
For the pattern info I don't know. Is it really a user friendly to present Java date formating pattern info? The difference between M, MM and MMM or between h and H isn't that obvious for the user I would believe. Maybe one could use I18N catalogues instead and get something a little bit more readable.
/Daniel
