Grzegorz Kossakowski skrev:
Hello,
I'm glad to see that we agreed on design of OM, now I would like to
focus on converter concept.
First of all, I would like to know which form should be preferred:
"converter" or "convertor". Since both are valid (according to
dictionary.com) I'm not really sure which one I should pick.
Convertor was from CForms, converter might be a better name.
Now I must admit that I'm not sure if I understand converter concept.
Let me explain my current understanding.
Basically, converter for certain type is a class that performs
conversion between that type and its string representation. The
converter is locale-aware so string produced by converter may depend
on user's locale (e.g. Date representation).
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.
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.
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?).
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. 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.
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.
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.
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.
For each type it is possible to define default converter and it is
assumed that Cocoon ships with set of default converters for
primitive, common types.
Yes.
/Daniel
