If it helps, tell the client that google recommends a single module, and that that's the way they implemented Orkut and Google Wave (that's what my 2min investigation tells me). Google Adwords uses multiple modules, but I think that's what led to the idea of code-splitting in GWT.
If they still don't agree, take apps that the user is unlikely (or less likely) to use in the same session, and make them separate modules. For example, settings/billing is a module that isn't accessed everyday. So when the user clicks on it, its perhaps okay to download the new nocache.js for the module. Every project typically has 2-3 such independent modules, find out what they are in your case and move them out. Use the 80-20% rule - the 20% of the screen that will be used frequently MUST be in a single module to get performance. The remaining 80%, it'd be nice to convince the client -- but if not, so be it. The problem for the client is that if the UI has a common custom widget used > in a couple of the apps, modifying it would mean retesting all apps that > make use of it. > You should make a separate module for your common widgets. This module won't have an entry point, but will be included with all other modules. That way, you are still able to reuse stuff across your apps. And if you have to update "Only one app due to some critical fix", you can branch out this module. So, you get best of both worlds. *Summary* - Try to use a monolithic module. But if you cannot, at least make sure that the frequently used parts are present in a single module. --Sri On 6 April 2010 16:28, Jon Vaughan <jsvaug...@gmail.com> wrote: > Hi all. > > I'm beginning to build a set of GWT applications for a client. > > The clients customers will purchase a set of these applications (not > necessarily all of them) and when deployed these applications will > work together (imagine, for example, a 'Contacts' app, a 'Billing' > app, 'Timerecording' etc), linking back and forward between > information in each. > > The client has a requirement that each app is independently > deployable. This would rule out the option of a monolithic compile > despite its many advantages (optimization, memory footprint etc) > > - However they would also like the apps to all exist in a single > window, to prevent confusion about pop-ups etc > - And all of this has to work on relatively low powered machines and > be IE6 compatible > > Possible options are iframes or a portal framework but in my view both > of those are fairly horrible. Iframes are going to mean history and > inter app communication issues. Portal frameworks mean an extra layer > of effort, especially working out how to integrate the inter-portal > communication with gwt. > > Alternatively I need to work out how to circumvent their independently > deployable requirement. Certainly there are enormous advantages to > the single GWT compile. The problem for the client is that if the UI > has a common custom widget used in a couple of the apps, modifying it > would mean retesting all apps that make use of it. One solution to > this I suppose is total codebase independence, with no common > dependencies, or versioned widgets somehow, and I could argue for that > style of approach. > > So I was wondering, does anyone have any alternative ideas, or > thoughts about how they would approach the same situation > > Thanks > > Jon > > > > > > > > > > > > > -- > 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-tool...@googlegroups.com. > To unsubscribe from this group, send email to > google-web-toolkit+unsubscr...@googlegroups.com<google-web-toolkit%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/google-web-toolkit?hl=en. > > -- 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-tool...@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.
