I would also like to have similar functionality: back-forth button working within a tab, not across a tab.
This would be possible to achieve if GWT supported for nested places and activities. In the first level, back-forth button would work across the tabs. Once a user clicks within a tab, URL would append information about a nested place. In such a case, currently running activity would not stop but keep running, and the nested activity would start. And so forth. Since there is no support for nested activities/places in GWT, I currently use back-forth button to switch between tabs. When a user navigates within the tab, I simply persist information about the current place (using a single server request when an activity stops). If user comes back to the same tab, its state is restored from the database. P.S, I don't use TabLayoutPanel, just TabBar to conform MVP approach. On Jan 6, 5: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.
