cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <gkossakow...@apache.org>
Subject Re: Clarification on converter concept
Date Wed, 04 Jul 2007 22:56:31 GMT
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/

Mime
View raw message