What I usually do in situations like this is design the webpage framework first. I’ll have a div for the header, side menu and footer. I’ll also have a
div in my HTML for the main content.
(If you like <div> based layouts, feel free to use those instead.)
Then you build your entry point (in my case
Core.java) as you normally would, setting each of the elements as need be.
RootPanel.get("header").add(new Header()); RootPanel.get("leftnav").add(new NavigationMenu()); RootPanel.get("footer").add(new Footer());
It is, of course, possible to have a static footer and header, but that’s neither here nor there.
I also have an abstract class called “Content”. Content objects extend “Composite” and will have various methods for simplifying the creation and layout of a new page. Every page that I build for this application, be it a help screen, search screen, shopping cart, or anything else, is of type
Now, what I do is create a class called “ContentContainer”. This is a singleton that is responsible for managing the “content” element. It has one method “setContent” that accepts objects of type “Content”. It then basically removes anything within the “content” <td> and replaces it with whatever widget (Composite) you assign via the “setContent” method. The setContent method also handles history and title bar management. Basically the ContentContainer serves to aggregate all the various points of binding that you might have to make if each page content had to “know” about all the functions it must perform.
Finally, you need a way to get to that page, right? That’s simple:
Put the above in an on-click event somewhere and you’re golden.
The only things that your other widgets need to be bound to is the ContentContainer and the type of Content that they are adding.
The downsides that I can see to ChrisBo’s approach are that you’ve got a list that has to be maintained of tokens -> pages. The other downside I can see is that I don’t see how you can have an actual history system with this method.
One thing it does offer over my approach is that all page choices are pretty centralized. I’d use some sort of Enum or at least a static class with String values to prevent myself from mongling up links.
In either case, I think the point can be summed up as this: swap the content of some central page element based
on what your user clicks actions your user(s) perform.