On extension strategies for GWT applications

[Davide Cavestro]

I have to support the deployment of additional modules in order to dynamically extend my employer's GWT application, adding new features or customizing the existing ones.

I mean something like a plugin system which dynamically loads and executes new code deployed at any point of time.

The basic application is composed by several logical modules: they are compiled together and make heavy use of GIN and DFN code splitting.

So I'm looking for a way to make the additional modules coexist with the basic application, hence supplying additional features within the same HTML host page of the original application.

At server side I have a Spring web MVC application. In order to deploy the additional modules it is acceptable having to restart the web application (if needed), while it is not acceptable having to redeploy the entire war application. i.e. I could introduce some dedicated controllers to serve contents from additional modules at the appropriate URIs.

I'd like to know:

  1) is there any well established pattern for this kind of scenario?
  2) is there any certainty that compiling two modules separately then I can run them into the same HTML host page without any clash? i.e. separate GWT compiler executions on separate modules could generate globally-scoped javascript variables with the same name?
    2.a) if I can compile them separately, then I should find a way to make the two applications communicate, potentially sharing references of object managed by GIN. Is it feasible?
    2.b) if I cannot compile them separately, then is there any alternative to recompile them before the deploy? i.e. did anyone successfully integrate the GWT compiler or the superdevmode at the server side for production uses?

[David]

Davide,

GWT is not really made to be deployed as multiple  GWT compilation units. This is done for the sake of performance.

I had similar requirements as you I needed to be able to co-host multiple GWT applications on one page (a portal system) but they are compiled separately and developed by other teams. There was also the need to communicate between those applications.

GWT can host multiple GWT applications on one page. The code is loaded in an IFrame so there is no risk that the generated classes would clash.

But at the same time, you can not just simply pass those objects between the GWT applications since the same Java class does not generate the identically named JS class.

So, I am using a JSNI API that allows me to pass some basic object types between the different applications (JS Overlays are nice for that purpose).

Another thing to consider is styling. If you use plain CSS stylesheets make sure that they can coexist. If you use CssResources, then you need to make sure that the generated CSS names do not clash, that is possible because you can define a prefix that should be used by the generator (or even implement your own naming mechanism).

The 2b option you describe is interesting, but no I did not try to go down that road. That would actually mean that we need to ship our sources to the customers, which is not allowed in our case.

David

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-tool...@googlegroups.com.
To post to this group, send email to google-we...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.

[Thanos]

We really need something like this too. We've developed a workbench UI, that has plugins - all currently compile time. Would be nice to be able to have those as runtime plugins, even if they are self contained GWT apps. As you pointed out "you can not just simply pass those objects between the GWT applications since the same Java class does not generate the identically named JS class".

Maybe in the future a base application during compilation could export a symbol table of names, for classes with the correct annotations, that the other GWT applications can compile against. This would then allow each GWT application to read/write the same java objects, without requiring a GWT -> JS <- GWT bridge.

Mark

[Jens]

We really need something like this too. We've developed a workbench UI, that has plugins - all currently compile time. Would be nice to be able to have those as runtime plugins, even if they are self contained GWT apps. As you pointed out "you can not just simply pass those objects between the GWT applications since the same Java class does not generate the identically named JS class".

There are people that have used OSGI with GWT. They basically have a parent app that contains an iframe and a menu that is generated based on a server request. The server request figures out which OSGI bundles are deployed so that if you disable an OSGI bundle or add new one the menu adjusts itself. Once you hit a menu item a new GWT app will be loaded (from the corresponding OSGI bundle) and displayed inside the iframe. To communicate between the parent app and the app loaded in the iframe you could use window.postMessage and a defined set of messages.

Then there is also https://code.google.com/p/gwt-exporter/ which can help to create a JS based API that different apps can use to talk to each other.

The only thing your pay by having multiple apps that represents single sections in your app is that each app will download all the required GWT library code on its own. So at the end your clients need to download a bit more JS.

-- J.

[Mark Proctor]

It seems like this is a common request. I wonder if there is anything the GWT team can put into the roadmap, that would allow for the compilation of a core application. Then the later compilation, aka “linking”, of other gwt code - where the user annotates things not to be pruned, so they can be linked against later. This way we can write modular applications, with runtime module plugins.

I notice GWT is moving to closure in the roadmap. Closure already has capabilities to mark things, to avoid for pruning, for exactly this reason. I believe it creates some sort of global table of compiled names, so that when the later module is compiled it re-uses those same names. Thus there is little extra baggage, from re-loading duplicate things, and no GWT <- JS -> GWT bridge is needed. As both Modules, the core one, and the runtime plugin one, understands the same names for objects and properties.

Mark

--
You received this message because you are subscribed to a topic in the Google Groups "Google Web Toolkit" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/mO4l7HygPoo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-web-tool...@googlegroups.com.