Have you pondered simply not using the Places? I'm not sure if this is a requirement (or simply a strongly desired outcome) of your project, but if not, then you can simply roll your own MVP framework. In the case of my company, we started using GWT before the new place stuff came about, so we didn't have too much choice but to be inventive (aka maniacal).
Since nothing in the base GWT libraries calls History.newItem() (besides a Hyperlink widget), and (as far as I am aware) nothing of importance listens to those events by default, you can pretty easily make your own history management mechanism. I wrap the whole thing in a ApplicationNavigationControl class, which the various presenters can poke to cause navigation to different Pages (our equivalent of Places). While our application is much more traditional (only one Page at a time), I could see creating some custom scheme of encoding the state of multiple tabs into the history token. If you want the back/forward navigation to only affect the currently selected tab, that might get a bit tricky, since you will need to keep around multiple stacks of tokens in your history wrapper, and then somehow create a composite token to represent the current top item on all of the stacks. Or perhaps some other method that additional caffeine intake might bring about would work as well. -Ben On Jan 6, 7:14 am, "[email protected]" <[email protected]> wrote: > We have been experimenting with GWT and with the MVP design pattern > but are having trouble with the history mechanism in our proposed UI. > Looking through the many posts there are other people who have > encountered problems similar to what we have but there don't seem to > be conclusive. Our proposed UI uses a TabLayoutPanel where each tab > is a different function and each tab should be independent of every > other tab. This includes the browser back and forward buttons working > within the tabs and not across the tabs. > > Digging through the code and implementing a ValueChangeHandler and a > PlaceChangeEvent.Handler when the browsers back button is pressed the > ValueChangeHandler is invoked first and then the > PlaceChangeEvent.Handler is invoked. Looking at the stack both events > seem to originate from a call to HistoryImpl.newItem() and the event > that is generated does include the token from the previous Place > visited within the application (but not necessarily the previous Place > within the current tab). I presume that HistoryImpl.newItem() is > invoked from within a javascript library supplied by GWT. Do I have > this right? > > Assuming the preceding paragraph is correct it looks as though the key > to changing the behavior of the history mechanism would be replacing > the HistoryImpl class with a class that performs lookups for the > currently visible tab to figure out what the previous or next place > within the tab is. Both the History and HistoryImpl consist of static > methods and assuming the javascript libraries are invoking the > HistoryImpl.newItem() the existence of the HistoryImpl is probably > baked into the javascript libraries. Is there a property file or some > other mechanism that controls what HistoryImpl is invoked? Is it > possible to replace the HistoryImpl and/or History implementation with > one's own implementation? > > If it is not possible to replace the HistoryImpl, is there any way to > trap and kill events? This would mean trapping the events fired as a > result of the invocation of the HistoryImpl.newItem() and then firing > new events with the content for the correct Place within the current > tab. Is this possible? > > From the experimentation I have done with creating my own > PlaceController and PlaceHistoryHandler it looks as though the only > other possible alternative is to let the place change events run their > course and in some way recognize in the Activity/Presenter that this > isn't really where we wanted to be and invoke a goTo to the Place we > really do want to be. > > Chris Marshall > Avenue100 Media Solutions -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
