Multiple dynamic Application-GWT-Modules running in a Core-GWT-Module
pi
its the first time, that I post something in this forum. Offen i'am
reading the articles in here and iam very exited about the high
quality of questions and answers!
About 3 month ago i started to educate myself in GWT. And 6 month ago
i startet with J2EE. So i am still learning a lot about it every day!
GWT is a really great framework. But i have a problem and iam not
sure, how to resolve it. It would be really greate if someone could
give me a tip, which way i should follow in resolving this.
The best expamle would be, i describe, what i like to do:
I'd like to create an environment, in which i or other can write
applications (ItemMaintenance, OrderMaintenance, Invoice..., an so on)
on a very simple way. For the frontside i descided to take GWT. The
serverside will be designed with seam and jboss.
In the first step, i designed a GWT-Core-Module. This core-module is a
simple GWT-Module (with entrypoint,...). This GWT-core-module should
be able to load other GWT-modules (application-moduls
[ItemMaintenance,...]) into the browser. This means, that serveral
moduls are running at the same time in one Browserwindow.
The way of doing this is quiet simple. The core fetches infos about
the application-moduls by RPC from the server an create links to the
website of the application-moduls. The infos are offered by xml-Files
serversided.
The windowhandling technologie would be GWM (google window manager).
It allows to run more than one window with different content at the
same time. I have been reading, that seam can handle multiple
windowsessions within one browsersession. (really great).
So far so good! There are no Problems at this point.
The GWT-core-module should also build an environment. This means, that
central communicationObjects and messageObjects are in the GWT-core-
module.
For example:
A central repositoryInfoRetriever. The application-moduls do not know
the exactly labels of their fields. They just know a dataDescription.
On instantiating a field (extended Textbox), the field registers in an
InfoCache. This cache sends the dataDescription to the server, which
responds the label, fieldlenght, format,... A callback is setting the
responded properties to the field. And the cache is caching the
responded data. So a dataDecription that is still in the cache, won't
be requested from the server anymore. Then the cache directly calls
the callback.
This feature is quiet simple, an it is still working.
But now my big problem.
I'd like to share to cache described above with all loaded application-
moduls. That means, that a new loaded application-modul has to get a
reference to the core-modul, which knows the InfoManager, which
manages the cache.
And it is very imported, that the application-modules can be compiled
without the Environment, because i don't like to compile the whole
applications inclusive the core by adding one application-module. I'd
like to have one core-module an multiple independent application-
moduls. So each module is its own webpage! (Of course, the application-
modules are not runnable themselfe without the core! But thats ok)
The big problem in one sentence
I don't know how to get a reference to the core-module from the
application-modules???
Eventually I thought about the following:
The application-moduls are programmed against interfaces or native
methods, that are representing the core. The core-module has to offer
a global object in javascript, which allows the application-moduls to
find the core in the Browser. And so they can get a reference to the
core.
It would be really, really great if someone of you has an idea, how i
can resolve this problem.
Best danks, pi
Dan Morrill
Multiple Modules that have been compiled separately will not be able to share any classes. The compiler will obfuscate each module separately, and this will mean that the JavaScript counterpart for a given Java class will have a different name in each module, once the obfuscator has run.
So, any caching strategy you use that operates across Modules will be restricted to primitive data types, like strings, integers, and so on. You can also use plain JavaScript objects, though manipulating them will require you to use JSNI methods. Additionally, since you are using objects across windows, you won't be able to use instanceof, because of how JavaScript manages classes, which might further limit your data structure strategy. (If you create an object such as an Array in one window, 'obj instanceof Array' will fail in all other windows, because they don't share the same instance of the Array class itself.)
So, if you can live with those limitations, then you can implement a shared cache. You would, as you concluded, do so by using global variables to store objects under well-known names that you share across windows.
As an example, suppose you have class named "MyCache" in your "Core" module, and you have methods named "void set(String key, String key)" and "String get(String key)". In that case, you might use a JSNI method similar to this:
public native void setupCacheHandles() /*-{
window.__cacheSet = function(key, val) {
this.@com.company.app.core.client.MyCache::set(Ljava/lang/String;Ljava/lang/String;)(key, val);
};
window.__cacheGet = function(key) {
return this.@com.company.app.core.client.MyCache::get(Ljava/lang/String;)(key);
};
}-*/;
This code will store pointers to MyCache's get()/set() methods under the window._cacheSet/Get properties. You would call that method from your MyCache's constructor (for example). In your "child" Modules, they would have JSNI methods similar to this:
public native void cacheSet(String key, String val) /*-{
window.opener.__cacheSet(key, val);
}-*/;
You would, of course, have to replace window.opener with the appropriate handle to the window which contains the cache.
I think you'll probably have to adapt this technique to meet your needs; the examples above just show you how you can store references to your Java class's methods under well-known names in JavaScript. You'll have to store whatever methods or fields are appropriate for your cache implementation.
In case you're not familiar with JSNI yet, the documentation is here: http://code.google.com/webtoolkit/documentation/com.google.gwt.doc.DeveloperGuide.JavaScriptNativeInterface.html
Hope that helps!
- Dan Morrill
pi
great! Thanks a lot. I'll try on weekend and post my results.
Best thanks, Pi