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 <dolephi9...@gmail.com> 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 google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
