Hi, Thanks for your invaluable help.
I'm mashing together a simple example for me to learn from that has a single statically defined plug-in. I am growing to believe I need to deploy each plug-in as a separate WAR on a web-server. Is this true, or have I missed something? I am also using gwt-exporter to make the JSNI messaging mechanism; i.e. I just write an "Exportable" class and use the resulting JS API from my plugins. I am hoping to use gwt-api-interop to remove the need to use the JS API. I assume the JS "bridge" between GWT applications handles the messaging between them (i.e. plugins register callbacks to handle messages sent from the "host"?) If I understand correctly, adding additional script tags to my "loader" page and having each plug-in as a separate WAR I avoid the need to inherit in my gwt.xml file? An example of your use of JavaScriptObject in your messaging sub- system would be interesting.... Thanks again. Mike On Jun 17, 12:20 pm, lemaiol <[email protected]> wrote: > I followed the basic ideas of application's linking and loading: > - The GWT host page is the loader. So you have to know how to > discover the modules to be loaded. > + KIS: have a class on the server side that know modules' ids, > names and URL's and generate the GWT host page using a JSP. > + Best practice: map the default GWT page's name to the JSP within > your web.xml. From outside nobody will know that the page is not > static. > + The resulting page has as many script tags to load the > *.nocache.js files as modules should be loaded. > - Once that all the applications (independent WARs) have been loaded, > they all live in the same application space: the browser window. But > they have each an own GWT application space. The JS engine is common > to all and native JS (not generated from GWT) is more pervasive and > does not get affected by GWT compilation + linking. > - Implement a communication mechanism based on JS (ex: message > dispatch facility) > + Create an structure in the GWT page where the plugins can > register themselves. An JSON object will do the trick: "var pluggins = > {{name: 'plugin1', callback: ''}, {name: 'plugin1', callback: > ''}, ...};" Because it is embedded in the page, it is already there > (static) when all applications are loaded. No application is assured > to be loaded and initialized first! > + Create GWT wrapper classes inheriting from "JavaScriptObject" to > access this structure (ex: "register" / "attach", "sendMessage", > "receive"). Define communication and plugin interfaces and pack all in > a jar with sources and <module>.gwt.xml = GWT module. > + Use JSNI for the methods implementation and calling back into > GWT. Use these classes in each plugin application. The GWT compiler > with compile and link the GWT code but the JSNI code remains as it is. > - Because at some time, the individual plugins have to be shown in > the web page, create an static HTML structure with explicit HTML IDs. > One or more of them will be populated by the plugins once at a time. > It is important that it is static because, once again, it belongs to > the broswer application space (window) and not to a concrete GWT > application space. Said in another way, none of you applications > should generate the DOM elements for other plugins neither from code > nor with UiBinder. > - One plugin is the main plugin and he is the first to show up + he > normally dispatches to other plugins or offers the dispatching > mechanism. > - Your application needs a common message model for the messages. > Should inherit from JavaScriptObject and be created with the class > factory methods and the populated. > > Which snippets do you want? > > Berto > > On Jun 16, 2:08 am, kendeng9898 <[email protected]> wrote: > > > Hi Berto, > > Waiting for more details. give some simple sample code is > > appreciate. > > > Since the compilation speed & easy development, I've changed to use > > pyjamas project, a python verion of GWT. But I still interesting in > > how to do the plugin. The hardest part is how to solved the different > > compilation and linked. > > > Thanks, > > Ken > > -- 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.
