GWT with multiple host pages in a legacy application

Question

I am considering making use of GWT as the front-end to an existing web application.

I can't justify a complete rewrite to 100% GWT in one go. It is likely that I would migrate parts of the system to GWT gradually. However for consistency I would like to make use of the GWT TabPanel, MenuBar, etc as global interface elements from day one.

As an experiment to see how 'legacy' parts of the system could be incorporated, I have done the following.

The application's main page template now loads a small 'wrapper' GWT module on every page. This GWT module looks for a selection of DIVs in the dynamically generated host page. If the DIV is found, a suitable widget is slotted into place, i.e. menuBar, tabPanel.

A lot of the configuration for the included widgets can also be slotted into the host page as JSON structures. For instance, I have implemented an adapter that dynamically sets up a TabPanel in this way. I've also added some very simple widgets that load remote HTML, etc.

As a prototype, this all appears to work perfectly and loads quickly. However, it seems that GWT apps are really designed to be run from a single host page, not hundreds of dynamically generated ones.

Can anyone highlight any issues that the above approach may run into, particularly as the GWT module increases in size? I would aim to keep the legacy wrapper module intentionally lean. Other functionality would be implemented in separate modules.

How have other people integrated GWT into their front end in a gradual fashion?

Answer 1

One of the ways GWT was designed to be used is exactly as you've used it. We have done that in many of our apps - where there is one GWT module with multiple 'parts' that are loaded based on whether a given id exists on a page or not. So I don't see that you'll have any issues at all going this way. We often use this approach even for new web applications, where we just want a few 'widgets' on the page, rather than coding the whole application in GWT.

It won't make a huge difference, but one thing I would suggest is not putting the GWT javascript code into your main template, but rather only put it on the pages that need it. It's true that if you're not running HTTPs it is cached basically forever, but it seems wrong to get people to load in the module if it's not actually needed on that page. This of course depends on how people use your site, if they are likely to download it anyway then it won't make any difference.

Answer 2

When you say "there is one GWT module with multiple 'parts' that are loaded based on whether a given id exists on a page or not" what do you mean by parts?

Would you be kind to put an example or point me to some sample in the web?

I am trying to speed up the loading and rendering of my GWT app. I want to fully understand the technique you are applying. Has the technique you are applying anything to do with the FastContainer pattern (techzone.enterra-inc.com/gwt/gwt-improving-performance/)?

Answer 3

You're doing it right. Avoid avoid avoid the temptation to try to 'minimize' the GWT footprint by breaking it up into multiple separate apps.

The key to GWT performance is to have as few downloads as possible and to make sure they're cached. Loading a 250k bundle once is much better than two 200k bundles and because compression get's better with larger files you really start to reap benefits as things grow.

y-slow & firebug can be really helpful when it comes to convincing yourself of this.

One performance trick you might check out is available in the sample chapter here: http://www.infoq.com/articles/progwt It shows a mini-architecture around loading GWT widgets into any number of slots and pre-populating data in JavaScript variables. This allows your GWT widgets to load and not require a second HTTP GET to get the data they use. In practice I found that this was a nice performance boost.