Jeff,
You are right. This code did not work although there was no compilation
error.
I have 2 other solutions ( and this time, I have successfully tested the
first one :) )
1. with a class that switch I18n
public class I18nSwitcher {
public static I18n getI18n()
{
final String profil = getProfil();
if ("profil1".equals(profil)) {
return GWT.create(I18nProfil1.class);
} else if ("profil2".equals(profil)) {
return GWT.create(I18nProfil2.class);
} else {
// default
return GWT.create(I18n.class);
}
}
private static native String getProfil()
/*-{
return $wnd.profil;
}-*/;
}
public interface I18n extends com.google.gwt.i18n.client.Messages{
// all your i18n keys
}
public interface I18nProfil1 extends I18n {
// nothing
}
in .ui.xml :
<ui:with field='i18n' type='com.xxx.gwt.i18n.client.I18n' />
in .java
@UiField(provided = true)
com.xxx.gwt.i18n.client.I18n i18n = I18nSwitcher.getI18n();
This method has a drawback ; if 10 profils are defined, 10 values of i18n
will be load on browser although only 1 is used. That's why the second
solution is better IMHO.
2. using a generator
Replacing
<replace-with class="com.xxx.gwt.i18n.client.I18n">
<when-type-is class="com.xxx.gwt.i18n.client.profil1.I18n" />
<when-property-is name="profil" value="profil1" />
</replace-with>
with:
<generate-with class="com.xxx.gwt.i18n.rebind.I18nProfil1Generator">
<all>
<when-type-is class="com.xxx.gwt.i18n.client.I18n" />
<when-property-is name="profil" value="profil1" />
</all>
</generate-with>
I will try the second solution in the next days.
Thanks for the bug you found for me,
Alexandre
2011/4/15 Jeff Burnham <jeffrey.burn...@gmail.com>
> Alexandre,
>
> I had tried this but ran into the issue that the "<replace-with
> class="xxx">" declaration required a class rather than an interface which is
> what is used by i18n when utilizing property files. I've seen other
> approaches where people have used this approach along with a factory but
> that doesn't appear to work with ui binders where the constants interface is
> utilized within the ui.xml file.
>
> Did your project use the approach of the constants being referenced
> directly in the ui.xml file?
>
> Thanks,
> Jeff
>
> On Fri, Apr 15, 2011 at 12:03 AM, Alexandre Ardhuin <
> alexandre.ardh...@gmail.com> wrote:
>
>> I have something similar in my project. I resolved the problem with
>> Deferred Binding.
>>
>> In HTML page, I can set a js variable :
>> var profil = "profil1";
>>
>> This js variable will be re-use in Module.gwt.xml to replace default i18n
>> by a specific one:
>> <!-- 'profil' property -->
>> <define-property name="profil" values="profil1,profil2,profil3" />
>> <property-provider name="profil"><![CDATA[
>> return profil || "profil1";
>> ]]></property-provider>
>> <replace-with class="com.xxx.gwt.i18n.client.I18n">
>> <when-type-is class="com.xxx.gwt.i18n.client.profil1.I18n" />
>> <when-property-is name="profil" value="profil1" />
>> </replace-with>
>>
>> Thus, com.xxx.gwt.i18n.client.I18n and
>> com.xxx.gwt.i18n.client.profil1.I18n can reference differents properties
>> files.
>>
>>
>> Hope this helps,
>> Alexandre
>>
>>
>> 2011/4/14 Jeff <jeffrey.burn...@gmail.com>
>>
>>> Does anyone have any experience with how to handle the following
>>> problem?
>>>
>>> My application has multiple user roles, all of which see the same
>>> screen with the same fields but depending on what role the user comes
>>> in with, the labels on the fields may differ. I'd like to use an
>>> approach similar to i18n (constants class backed by various property
>>> files) where in my use case the role is synonomous with a locale. Note
>>> that all labels are assigned in UiBinder ui.xml files so the goal is
>>> something like:
>>>
>>> <ui:with field="const" type="com.sample.client.LabelConstants" />
>>>
>>> Where the above declaration should use
>>> "LabelConstants_registered.properties" or
>>> "LabelConstants_anonymous.properties" similarly to how i18n would use
>>> "LabelConstants_en.properties" or "LabelConstants_fr.properties"
>>> depending on the locale.
>>>
>>> Any ideas or experiences?
>>>
>>> Thanks in advance.
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "Google Web Toolkit" group.
>>> To post to this group, send email to google-web-toolkit@googlegroups.com
>>> .
>>> To unsubscribe from this group, send email to
>>> google-web-toolkit+unsubscr...@googlegroups.com.
>>> For more options, visit this group at
>>> http://groups.google.com/group/google-web-toolkit?hl=en.
>>>
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Google Web Toolkit" group.
>> To post to this group, send email to google-web-toolkit@googlegroups.com.
>> To unsubscribe from this group, send email to
>> google-web-toolkit+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/google-web-toolkit?hl=en.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Google Web Toolkit" group.
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> To unsubscribe from this group, send email to
> google-web-toolkit+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-web-toolkit?hl=en.
>
--
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
