Hi,
Why don't you use code generation to generate the interfaces based on the
resource bundle properties files ?
That is what we do. Developers only need to define the properties and
through a Builder config in Eclipse we auto generate
the interfaces for GWT (and you could do the same to generate code you can
use in the SWING client).
That way you only need to maintain the properties files.
David
On Thu, Dec 11, 2008 at 2:38 PM, Marek Gregor <marek.gre...@gmail.com>wrote:
>
> We use GWT as web client technology for enterprise J2EE system (EJB,
> JAAS, ...) which is also capable to offer swing client GUI via java-
> web-start.
>
> Our aim is to make development simple (because of the size of
> project)- to use the same code for the same thing in all parts of the
> code. But nowadays different localization concepts makes us headache,
> because for functionality X for which is accessible from swing client
> and also from (web) client we need to use the same resource bundle.
> The same resource bundle is required also on server side (EJB
> stateless bean) where we generate image of the chart (jfreechart) with
> the legend which should be also localized.
>
> So we have property files:
> SuperFunX.properties
> SuperFunX_de.properties
> ...
>
> then interfaces which extends gwt.i18.Constants and Messages which
> should be in the same package:
> interface SuperFunX extends Constants {
> String title();
> ....
> }
>
> But For Swing and server localization we have to use different
> interfaces which extends our own localization interfaces with the
> same concept as it is in GWT (pairing method name with key of resource
> bundle is very elegant way how to have check in compile time for
> matching if keys exists, we get this localization concept from GWT):
>
> interface SuperFunXResourceBundle extends LocaleResourceConstants{
> String title();
> ....
> }
>
> where LocaleResourceConstants is our interface similar to
> gwt.i18n.ConstantsWithLookup
>
> So now the code for receiving localized text looks like:
>
> 1) in GWT
> GWT.create(SuperFunX.class).title();
>
> 2) In Swing and server it is:
> LocaleResourceFactory.create(SuperFunXResourceBundle.class).title();
> or for specific locale
> LocaleResourceFactory.create(SuperFunXResourceBundle.class,
> "en_En").title();
> or for runtime key value:
> LocaleResourceFactory.create(SuperFunXResourceBundle.class).getString
> ("title")
>
> Reason why we do not want to use GWT interfaces (Constants,
> ConstantsWithLookup, Message) is that we do not want to make
> dependency on GWT (gwt-servlet.jar or gwt.user.jar) for every module
> where localization is used.
>
> Our problem is that managing in synch two interfaces for growing
> number of resource bundles (currently approx. 250) and usage both of
> them for the same thing in different modules causes seamless effort.
> Also we cannot use e.g. the same validation logic (one class) for all
> environments (gwt, swing, server) which returns localized error-
> message - using one interface and one factory for creation of
> localized text.
>
> Solution which will be acceptable consists of:
>
> 1) the ability to define any interface to be treated as "Constants,
> Messages, ConstantsWithLookup" in .gwt.xml file, or to make GWT-
> localization-generator extensible to define new interfaces to be to be
> treated as "Constants, Messages, ConstantsWithLookup".
> 2) the possibility for usage of the same factory class for creation of
> resource bundles. This will be partially solved by
> http://code.google.com/p/google-web-toolkit/issues/detail?id=2243 but
> we need in some way to easily define different implementation of the
> same class (LocaleResourceFactory) for GWT and for normal J2SE
> environment.
>
> thanks.
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---
