cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Quinn <>
Subject Re: i18n Translations to String
Date Fri, 17 Nov 2006 18:57:18 GMT
Hi Vadim

Many thanks for you reply :)

On 17 Nov 2006, at 13:54, Vadim Gritsenko wrote:

> Jeremy Quinn wrote:
>> Now I need to work out how to do the above from FlowScript, when  
>> my i18n messages may have parameters, eg :
> :)
>>   <message key="upload.progress.sent">Sent: {0}% ({1} of {2}  
>> bytes). Filename: {3}.</message>
>> I have not worked out yet how I18nTransformer does this ....
> All the work is done in ParamSaxBuffer. So instead of using  
> XMLResourceBundle.getString(key), you should be using getObject(key):
>   Map parameters = new HashMap();
>   parameters.put("1", "1234567");
>   ...
>   ParamSaxBuffer message = (ParamSaxBuffer) bundle.getObject(key);
>   message.toSAX(handler, parameters);
> ParamSaxBuffer currently does not have toString(Map parameters)  
> method in case if you want to get only text of the message, but  
> between SaxBuffer.toString() and ParamSaxBuffer.toSAX(handler,  
> parameters), I'm sure it won't take you long to implement toString 
> (Map parameters). :)

Your confidence in my abilities makes me blush ;)

Actually, I have always found SAX programming to be a big of a  
mystery .... lets see how it goes :)

>> Ideally, one should be able to get a String which contains any  
>> tags that were in the i18n Message, as widgets may want to use  
>> these, by injecting them as InnerHTML.
> You'd have to use some of those ContentHandler implementations  
> which would serialize SAX events into String (using TrAX, or there  
> is org.outerj.daisy.xmlutil.XmlSerializer from daisy-util.jar).

Makes sense ....

>> JSON Serialization, we need better solutions ....
>> I am currently using JXT for serializing the JSON Response (as  
>> this allows the use of XMLizable I18nMessage), but it is a pretty  
>> foul way of doing it. I am not sure that JXT is able to determine  
>> the class of Objects in a nice way, I tried this :
>>     <jx:when test"${item instanceof  
>>}"> . . . </jx:when>
>> But jexl does not like 'instanceof'.
> It's not Java ;)

or JavaScript ;)

>> This means that my serialization currently has to turn everything  
>> into a String. (yuk)
> Try testing for a presence of a method? In JavaScript, you'd do
>   if (item.toSAX) {
>     // XMLizable
>   }

XMLizable is not actually an issue, as JXT already handles this  
transparently, and I can safely output it between quotes, setting it  
up as a JSON String.

More problematic from the PoV of using JXT are Numbers, Booleans etc.  
where to make a JavaScript primitive, you'd leave the quotes off, and  
stuff like Collections and Maps, where you need recursion.

Hopefully, if we can get some kind of I18nMessage.toString() working,  
then we do not need JXT for the Serialization.

But I see your point, if I am forced to use this approach, I need to  
identify signature methods that can be used to identify generic Objects.

>> What kind of Objects should we expect to be serializing to JSON ?
>>   JavaScript: Objects, functions and primitives: should be easy  
>> once FlowScript is updated to have .toSource().

There is a vote going on about Rhino, which I think will effect this.

>>   Java: Maps, Collections, Strings, Numbers, Booleans, Dates,  
>> primitives: use generic FlowScript (could be adapted from Dojo's  
>> code?)?
>>   Java: POJOs : use Jettison ?
> No idea :)

Jettison was Sylvain's suggestion from an off-list discussion.

This sounds like the /serious/ way of doing this ..... mapping files  
etc. etc.

What I'd like to find is a simple clean way of doing simple generic  
stuff. Make it easy to do things like passing JS Objects between the  
client and server, from FlowScript.

>>   Java: I18n Message Strings : a must-have ..... Dojo's i18n  
>> mechanism is not in place yet, without this it will be very  
>> difficult to i18n dojo widgets. We may not even want to have 2  
>> i18n mechanisms with 2 types of resource file format.
> Sounds reasonable.

There is very little scope for i18n in Dojo Widgets

1. You can have optional attributes on the tag (that can have their  
values i18n) that are used by the Widget on instantiation. This could  
become cumbersome.

2. You could conceivably have a Widget load it's instantiation  
Template via an i18n Pipeline, but I would argue against this  
approach, as ideally you'd want the template cooked-in to the Widget  
for production systems.

3. You can i18n the content that the Widget requests from the server  
after it instantiates, like I am doing with JSON data, also like the  
BrowserUpdate feature of CForms does.

I am pretty sure this does not cover all usecases ....

>> ATM, we only have 2 widgets that use JSON, but IMHO this number  
>> will grow. We also need a clear route for people developing their  
>> own widgets, so can we all have a think about this ?
> Yes, guys, please think about ... widgets! :)


regards Jeremy

View raw message