Grzegorz Kossakowski skrev:
Daniel Fagerstrom pisze:
Grzegorz Kossakowski skrev:
...
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.
Didn't my examples from CForms and CTemplate below help you?
Anyway, say that you have a couple of dates in your model bean that you
would like to render on a web page using CTemplate. Then you currently
would need to write something like (haven't checked the details):
<jx:formatDate value="${myobj.startDate}" dateStyle="short"
locale="${cocoon.request.locale}">
for each date. That is of course quite OK to write, but it clearly
clutters the code, and it is not that obvious for a non developer. With
converters it would be more like:
${myobj.startDate#short}
and
${myobj.startDate}
for the default formatting.
And for CForms you would use exactly the same notation.
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.
Maybe, but in that case you have one way of handling formating for forms
and another way for templates. And you would need two configurations
instead of one. Also from a conceptual standpoint it is better to
separate the rendering part (template) and the model part (form
definition). See my abstract text ;)
http://article.gmane.org/gmane.text.xml.cocoon.devel/42968 for more
about the model-rendering separation.
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?
I think those are the main use cases. But I think it should be plugable
so that people are able to write converters for there own classes. As
you can see in
http://svn.apache.org/repos/asf/cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src/main/java/org/apache/cocoon/forms/datatype/convertor/,
cforms contains a number of different convertors.
...
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?
A date converter would be that, yes.
/Daniel
