What's the use case for multiple entry points?

102 views
Skip to first unread message

David Easley

unread,
Nov 11, 2007, 1:51:44 PM11/11/07
to Google-We...@googlegroups.com
Hi,

[First post from GWT newb.] I want to use GWT to add AJAX features to an existing Struts web-app (in the 'attach GWT mini-apps to existing pages' style).

It took me a while to appreciate how entry points work. Perusing this group, there appears to be a lot of confusion about this, which I share. What's surprising is that when a module has multiple entry points they all get started together (consecutively, to be more accurate) on module load. I had initially assumed that (a) multiple entry points would provide a convenient means for us old Struts guys to bundle-up all our separate app fragments into one module and (b) there'd be some means of declaring which entry point should be used on each host page.

It would help my understanding tremendously if someone could describe the use case(s) the GWT designers had in mind when they decided that multiple entry points should work the way they do? I must be missing something because it seems to me that multiple entry points as designed provides nothing you couldn't do with a single entry point: a single entry point can be programmed to conditionally fill different 'slots' on a page depending on what's found in the DOM. What does the multiple entry points feature afford beyond this?

Thanks for any help,
David

Ian Bambury

unread,
Nov 11, 2007, 3:57:27 PM11/11/07
to Google-We...@googlegroups.com
Hi David,
 
There are very few situations I can think of where I would use multiple entry points. Here is about the only kind of thing I can come up with.
 
You need a situation where you need two completely divorced apps on the same page. A chat/ticker/etc window which you want to appear in many situations - the advantage of separate entrypoints (as opposed to including the project being included in many apps) is that you only have to recompile the chat app if it changes, not everything that includes it.
 
Pretty limited, yes, but if it is possible, then why not allow it, just in case...
 
 Ian
 
http://examples.roughian.com
--------------------------------------------

Jason Essington

unread,
Nov 13, 2007, 10:52:11 AM11/13/07
to Google-We...@googlegroups.com
If you have several disparate components on a page, you could create
a single entry point that parses through the DOM, and hands each
found element of to it's particular module, or you could simply have
a module that inherits all of the disparate components each with
their own entry point. The only difference being that in the first
case, you actually have to write some logic to sort out who needs to
do what, in the second, each component just handles its bit without
any extra code.

If you have many (or even just a couple) unrelated GWT modules on a
page, and your modules know how to find the elements that they need
on that page, then I don't really see any reason to create a single
entry point to perform the task that GWT will do on its own.

It is still important to note, that even with multiple modules it is
best to still only use one script tag to load them all. Your over all
byte count, and request count (and thus page load time) will be
reduced by doing this.

The trick to combining multiple modules (each with its own entry
point) is to simply create a new .gwt.xml file that only inherits
each module. don't declare an entry point in the new module (the
individual modules should handle that) and just compile this new
module. you will end up with a single javascript codebase that is
much more efficient than separate modules, but each module will still
have its onModuleLoad() method fired when the page is loaded.

However, if all the GWT components on the page are all part of a
single application, then it'd probably be best to go with a single
entry point.

-jason

Reply all
Reply to author
Forward
0 new messages