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 On 25 Oct 2013, at 09:49, Jens <jens.nehlme...@gmail.com> wrote: > 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. > > -- > 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-toolkit+unsubscr...@googlegroups.com. > To post to this group, send email to google-web-toolkit@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. -- 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-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@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.
