I18n transformer and JXTemplates

[Ralph Goers <Ra...@digitalinsight.com>]

We ran into a little problem. In our I18n catalogs we want to have variables
which are dynamically replaced by variables in the request or the session.
So what we are doing is something like:

 

        <map:pipeline internal="true">

            <map:match pattern="Retrieve/**">

                <map:generate src="documents/{1}"/>

                <map:transform type="i18n">

                    <map:parameter name="locale"
value="{request-param:i18n-locale}"/>

                </map:transform>

                <map:serialize type="xml"/>

            </map:match>

        </map:pipeline>

 


        <map:pipeline>

           <map:match pattern="**">

             <map:generate type="jx" src="cocoon:/Retrieve/{0}"/>

             <map:serialize type="xml"/>

           </map:match>

         </map:pipeline>

 

This works fine, except for one problem.  If the values in the catalog
contain things like <jx:out value="${request:xxxx}"/> the I18n transformer
will replace {request:xxxx} with nothing leaving only the $ as the value.
So what we'd like to know is if there is any way to keep the I18n
transformer from replacing these so they can be processed by the
JXTemplateGenerator.  If not, I'd be happy to create a patch to allow it if
someone has a good idea on a good approach.

 

Thanks,

Ralph

Re: I18n transformer and JXTemplates

[Vadim Gritsenko <va...@reverycodes.com>]

Ralph Goers wrote:

>                 <map:transform type="i18n">
>
...

> If the values in the catalog contain things like <jx:out 
> value="${request:xxxx}"/> the I18n transformer will replace 
> {request:xxxx} with nothing leaving only the $ as the value.  So what 
> we'd like to know is if there is any way to keep the I18n transformer 
> from replacing these so they can be processed by the 
> JXTemplateGenerator.  If not, I'd be happy to create a patch to allow 
> it if someone has a good idea on a good approach.
>

i18n parameters processing happens in ParamSaxBuffer.java. Currently, it 
has no escaping syntax, and has one bug with consecutive characters 
events (see FIXME).

Currently, I see several ways of approaching this problem:

1. Catalog - level parameters processing enable/disable switch. When 
parameters are disabled, SaxBuffer should be used instead of 
ParamSaxBuffer in XMLResourceBundle.java
2. Message - level switch, same XMLResourceBundle.java
3. Escaping syntax added to the ParamSaxBuffer.java

Either one, or all three ways can be implemented. If you also fix a 
mentioned bug in ParamSaxBuffer - even better.


Vadim