I would strongly consider whether there is a way to creatively accommodate their independently deployable requirement. Use code splitting and independent modules in the design architecture, but maybe when their customer requests a particular configuration, do a real-time compile of the application with only the components they purchased. So if they change their configuration, they get an entire new WAR file or whatever, with all of their options compiled in, vs a little plugin they tack on somewhere. Really shouldn't matter to the customer. If you're looking to sell the idea to your client, mention that the customer then can't purloin/hack these extra components - they can only purchase a full setup with the set of options they want. The benefits of making GWT work as a single monolithic unit make this very attractive from both development side and the final end- user experience.
If they don't go for it, then maybe gadgets like Jan mentions or create your own infrastructure with iframes and components and communications between them.. On Apr 6, 4:58 am, 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. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
