Is there any way to have the same class implemented differently on the client vs the server?
To avoid the "Why do you want to do that?" question.. I will elaborate
I am converting a very large Java client/server application. Currently it uses a Swing GUI client and talks to the server via Spring remoting (RPC). Using GWT RPC with Spring services is not a problem, there are several excellent examples available and the all seem to work well.
Several classes that are common to both the client and the server contain data that is passed back and forth. These classes also contain some behavior that is implemented by using the standard JRE classes. For example, one class contains, parses and formats date and time, including time zone, DST, etc. in a locale specific way. I could rewrite/refactor it but the application is over 10 million SLOC, resulting in literally millions of references to this class alone, so a major rewrite is not cost effective.
To use this as an example, GWT provides excellent i18n support for parsing and formatting dates. But the implementation is different to the way the JRE does it.
So I'm looking for a cleaver way where by I can inject an implementation into the shell of my DateTime class, depending on whether it is in the client (using GWT and native JS) or in the server (using the JRE). Is there a cunning way to do this? Perhaps using the module file XXXXX.gwt.xml. I'm looking for a generic solution.
You'd want to use the <super-source> for overriding one package implementation with another.
This is what GWT uses to emulate the Java Runtime classes, and (among others) provide different implementations for client and server of the com.google.gwt.regexp.shared.* classes.
I think what You are looking for, is this: <source path="client" /> in your project gwt.xml file. It tells the GWT generator where to look for client side code to convert to JS. In my project I have it set up this way:
<source path="client" />
<source path="shared" />
Basically client code is in the client directory, and in shared we keep beans and some data wrappers for client and server side.
What you could do, is to add the packages you want to convert to client with the source path like above. But you must remember, that the classes you are going to convert, can be composed only of objects and properties which GWT generator can convert into client-side java script. I'm not sure also if more accurate path can be put in the source path, like:
<source path="shared/beans/whatever" />
Another drawback is, that if you use GWT i18n support, it handles different locale in time of compilation by its own - which is good. If you decide to use your own mechanism, your classes must contain some logic to be aware of locale being used currently, which must be compatible with GWT.
Related
I have 2 different gwt applications, both on different machines, but they need to communicate.
Is their a simple way, using the gwt mechanisem to do it and access an existing servlet on another gwt application, or do i need to open another http connection between them some other way?
The most standardized way to do that is to use JMX: it is future prone and a lot of work was already done for you.
http://en.wikipedia.org/wiki/Java_Management_Extensions
Your issue cannot be considered as a GWT problem since GWT is limited to java script, and you need real java methods to communicate together, doing it through GWT is at best unperformant and at worse the source of many problems (since you are not inside a browser, and using a "virtual browser" to execute your javascript might lead to subtile very hard to understand differences)
From the below link I understood that GWT supporting only a subset of classes or methods in the following package in client side.
java.lang
java.lang.annotation
java.util
java.io
java.sql
https://developers.google.com/web-toolkit/doc/1.6/RefJreEmulation#Package_java_lang
Why is it so?
I think it make more problem in development because I am using only GWT client and using REST Web service instead of server.
Is there any new release of jar like gwtx (new release for supporting persistence,annotation etc) for using all classes and methods in the above packages.
and my main doubt is why they are not supporting all?
To support translating Java to JavaScript, every standard class has to be emulated, i.e. recreated in such a way that the GWT compiler knows how to translate it to JavaScript. An ArrayList for instance is based around a JavaScript Array, String methods have to be emulated on top of a JavaScript String, etc.
And there are things that are simply impossible to emulate (files, sockets). A few other things are not emulated on-purpose, because the emulated version, while technically possible, would be much less performant than a more direct mapping of the browser APIs, and GWT strives for performance (third-party libraries, such as GWTx, can provide such emulations if needed) more than compatibility (the choice of Java as the language was primarily to leverage tooling, not provide a compatibility layer to allow reuse of existing libraries).
Finally, reflection is not supported as it would make it impossible for the compiler to prune dead code and do all its optimizations: how would it know that a particular class, field or method is not actually used by reflection rather than direct calls?
I have some doubt regarding gwt file handling.
How to do file handling in gwt(at server side). How to create simple file. I mean which class is particularly used for CREATING and HANDLING it ??
Where is the file created. Is it under server package or somewhere else ??
How to resolve serialization and serialization problem. ??
GWT is a client-side technology. It's server-agnostic (and can also be used client-only, e.g. mobile apps, Chrome apps, browser extensions). GWT-RPC and RequestFactory use Java servlets by default (nothing precludes implementing RequestFactory in other languages/technologies) but have otherwise no requirement or limitations.
So, server-side, it's all just Java in most of the cases, and depends on your deployment target (e.g. AppEngine restricts what you can do, servlet containers can also have security policies in place, and you're of course dependent on authorizations at the filesystem level)
Since GWT is a pure client-side technology you have all possible options like plain Servlets for example. You are not limited in any way in picking the upload approach.
However, there is a number of open source projects, which make possible to use nice features like progress bars and multiple file uploads. And those come integrated with some GWT widgets as well. Check this project for example http://code.google.com/p/gwtupload/
while developing GWT apps we ran into lots of problems with project configuration. Let me explain... As usual in development, we have few environments for our application: local, demo, preview and live. Of course they are running on different machines, some are using SSL while others don't. But most importantly - all of them have different URLs.
Now, in few places in our application we need specify some URLs. Usually we would use *.properties files stored on server, and tools like Spring taglibs and it's <spring:message /> tag. But since GWT does not have such tools, we ended up in leaving hard coded URLs and performing code replacement on different SVN branches. As you can imagine - this is the worst possible scenario, causing us much problems.
So, my question is:
how one could build proper, flexible mechanism of storing config properties shared for both client and server side in GWT application. This properties have to be available for server-side handlers, client app (compiled JavaScript), UiBinder, other code running on server (workers, Spring, etc.).
The preferred way would be to avoid gwtc build if we change value of some property, but I guess it will be hard to achieve. So I will accept any reasonable alternative.
How about using relative URI references (e.g. absolute paths, without scheme or authority; i.e. /path/to/foo instead of http://example.com/path/to/foo)?
And in the few places where you absolutely need an URI (with scheme and authority), then use another property to store the "prefix" (e.g. http://example.com), and then concatenate with the above path.
Those places where you need a full URI should all be on the server, which means you don't have to recompile your GWT project when you change the "prefix", so everything is only runtime configuration and you can deploy the same artifacts in all environments.
That being said, if you ever need something configurable at runtime in GWT, then use a dynamic host page and JSNI (or a com.google.gwt.i18n.client.Dictionary); see http://code.google.com/webtoolkit/articles/dynamic_host_page.html
Still wresting with GWT and App Engine, and I have come to this problem:
I have an app engine populated with various data, which I would like to present on the client using a GWT RPC.
I have found out the hard way that, because my Model objects are annotated with JDO, i can't just send them back to the client because they aren't serializable. This means I'm going to have to create a layer of intermediate classes to extract data from my model objects, and send it back to the client to use asynchronously.
I am wondering though, it is possible to construct a GWT object in a servlet and send it back to be used? For example, the servlet would be receive my asynchronous request, pull out the data i want from the database, create a GWT VerticalPanel() with appropriate child elements for the data, and send that VerticalPanel back to the client to be injected.
My understanding of the Java / Javascript interaction that is going on here is still foggy, and I'm thinking that sending a Java object that is not compiled to Javascript after the application is deplyed will not work. Can anybody clarify this for me?
No the server can't create GWT UI objects (like vertical panels) to be used in the presentation layer, nor should it, that's why it's called a 'server' and a 'presentation layer' one serves the data and handles all the business logic, the other displays things on a screen and allows a user to interact with them.
You can however send your JPA annotated POJO's to the front end just fine (we do it in all our applications). You simply need to include the source code for the annotations themselves so that GWT knows how to compile them. You also need to make sure your POJOs's are in a package that is referenced by a NameOfXmlFile.gwt.xml file, eg:
<module>
<inherits name='com.google.gwt.user.User'/>
<source path="domain" />
</module>
This file in my case is in a folder above a package called 'domain' where all my JPA annotated POJO's live. Then in your client side you tell it to inherit that .gwt.xml file:
<module>
<inherits name='com.google.gwt.user.User'/>
<!-- Domain layer references -->
<inherits name='your.package.structure.NameOfXmlFile'/>
</module>
There are restrictions on what you can put in those classes (like for example BigDecimal is not supported, etc) but anything that can be compiled by the GWT compiler (and JPA annotations certainly can be) can be sent without needing any kind of transfer objects. This is one of the real strengths of GWT, that you can use the same JPA Pojos in your entire application, without ever needing to create any other similar object.
Edit: I just noticed you said JDO and not JPA. I assume the same applies there as well though if they are just annotations?
I've seen good answers, so I won't repeat them myself..
Anyway my simple but vital suggestion is: the only way to go is through POJO objects.. BUT IMHO to avoid problems, remember that your POJO objects SHOULD be really PLAIN
Anyway, I can suggest you also a little framework I recently did (few hours of work, so don't expect a rocket!).
It is pojo-injector: http://code.google.com/p/pojo-injector
It helps you in translating your data models to POJO and back... It's based on annotations (only on the POJO side!).
I hope it can help.
This is (imho) one of the problems with GWT.
Basically in Java Web applications it's pretty common to have data or domain objects (which would be your JDO objects) and presentation objects, which are sent to the view. Some go much further than this and can have many more layers of abstraction ("go ahead, add one more layer").
I can see the argument for this but it adds a lot of boilerplate as you translate objects between layers.
Anyway, in GWT you need to do this if your domain objects are POJOs (and as with JPA, even though they claim to be POJOs, the annotations make them not so in reality).
GWT will do this for you on objects returned by your RPC interface but there are certain classes you can't use (eg BigDecimal) as there is no Javascript equivalent (so to use BigDecimals you pass Strings around to construct BigDecimals yourself on the serverside when you ened them and convert them back to Strings when you send them to the client).