Dobes schrieb:
> It seems like it should be possible to implement a kind of server-side
> GWT.create() that generates an subclass using cglib or one of the
> other bytecode generators.
Actually I think you can do that with the functionality of
the JVM itself using Proxies:
------
public interface MyConstants implements Messages{
public String LocalizedMessage(String argument);
}
------
public class MyConstantsProxy implements java.lang.reflect.InvocationHandler{
private ResourceBundle rb;
public MyConstantsProxy(ResourceBundle rb){
this.rb = rb;
}
public Object invoke(Object proxy, Method method, Object[] args) throws
Throwable {
String value = rb.getString(method.getName());
for (int i = 0; args != null && i < args.length; i++){
if (args[i] == null) continue;
value = value.replaceAll("\\{" + i + "\\}", args[i].toString());
}
return value;
}
}
------
To use the proxy you have to get the resource-bundle and create the
proxy, so an imaginary GWT.create-method might look like the following:
------
public static Object create(Class clazz, Locale loc){
ResourceBundle rb = ResourceBundle.getBundle(clazz.getName(), loc);
MyConstants constants = (MyConstants) Proxy.newProxyInstance(
getClass().getClassLoader(), new Class[]{MyConstants.class},
new MyConstantsProxy(rb));
}
------
And use the method normally:
MyConstants constants = (MyConstants) GWT.create(MyConstants.class,
new Locale("de", "DE"));
System.out.println(constants.LocalizedMessage("this is the message"));
> Maybe it would only work for the Constants
> and Messages interfaces, and a minor selection of others, but it would
> be quite useful.
I think restricting it to Messages and Constants is OK because
these two are the only ones anyway where the special behavior
of GWT.create is used.
> Unfortunately, it would be difficult to implement
> this outside of GWT because the client code a) can't use any classes
> not supported by GWT and b) must use GWT.create with a literal class
> (not a variable) as the parameter.
The skeleton above should work and is not in conflict with the
current concept of GWT. You need the second parameter because
you must be able to get different "classes" in dependence from
the Locale being set on the client.
The "only" thing missing is implementing your own version of
ResourceBundle with the same algorithm for deciding which
property-file to be used in dependence to the requested Locale
(no use of System-Locale but directly fall back to the main
property-file, wrong default Locales for EN and ES, etc.)
and UTF-8 to be used as encoding. The latter can be done
by using Properties.load(Reader) implementing all the methods
of ResourceBundle or write an InputStream that is reading in
the data as UTF-8 and converts all non-8859_1-characters to
the escaped sequence being accepted by Properties. Other
things like caching of created proxies, support of the
annotations that came with GWT 1.5 etc. IMHO can be added later.
And that's the part where I don't have the time at the moment. ;-)
Regards, Lothar
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~----------~----~----~----~------~----~------~--~---
