Daniel Fagerstrom pisze:
Grzegorz Kossakowski skrev:
Convertor was from CForms, converter might be a better name.
There are three (including me) people that agree on this, I would said that it
is already decided. ;-)
Something like that. You find some background in
http://article.gmane.org/gmane.text.xml.cocoon.devel/42968 and
http://article.gmane.org/gmane.text.xml.cocoon.devel/43141. Also I think
we already discussed converters while discussing your GSoC application.
Yes, but I really didn't get the idea fully. Now I think that it may be just a lack of use cases for converter. Would you be so kind to
provide some examples how it could work in particular cases and how it would be helpful for Cocoon developer?
Sometimes abstract explanations hide the basic idea, actually.
The main usage is localization of string representations of dates and
numbers. This is needed both for CTemplate and CForms. For CForms the
converter needs to be bidirectional as well.
Yes.
Of course there already is possible to do localization in CForms and
CTemplate but it is not that convenient. In CForms you need a
declaration like
<fd:convertor type="formatting">
<fd:patterns>
<fd:pattern>MM/dd/yyyy</fd:pattern>
<fd:pattern locale="nl-BE">dd/MM/yyyy</fd:pattern>
<fd:pattern locale="fr">dd-MM-yyyy</fd:pattern>
</fd:patterns>
</fd:convertor>
see
http://cocoon.apache.org/2.1/userdocs/widgetconcepts/datatypes.html#formatting+%28date%29,
for each date field in your form definition (maybe there are some more
convenient way to do it with form libraries?).
AFAIR, using form libraries is the solution you look for in this case.
In CTemplate you instead use special tags
http://cocoon.apache.org/2.1/userdocs/flow/jxtemplate.html#formatDate.
With these constructions a localized Cocoon webapp becomes cluttered
with localization code.
Are there any use-cases apart form Date/Number/Currency conversion?
There are certainly room for some improvements:
First, it would be better to have *one* localization method that could
be used in both CForms and CTemplate (and possibly at other places), so
it is enough to learn one method for newcomer.
+1
Second, it should be enough to declare the localized rules for getting
from an object to its localized string representation in one place
(configuration file), needing to do it for each use makes the code hard
to maintain and read.
+1
Third, there should be a default converter (possibly localized) for
important data types, so you don't need to write anything at all in your
forms or templates in most cases.
...and option to override default converter.
It is perfectly valid to have more than one converter for particular
type, each one identified by unique, short identifier. Thanks to
converter concept following syntax:
{jxpath:cocoon/request/parameters/date}#shortDate
will be used to tell Cocoon that user expects 'date' request parameter
to be formatted as short date (whatever it means).
Short etc. is from DateFormat
http://java.sun.com/j2se/1.4.2/docs/api/java/text/DateFormat.html.
So converter is just a wrapper for configured DateFormat, right?
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
