History, Is An Alternate Implementation Possible?

[cmar...@avenue100.com]

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

[Ben Imp]

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, "cmarsh...@avenue100.com" <cmarsh...@avenue100.com>
wrote:

[Thomas Broyer]

Well, PlaceHistoryHandler uses an Historian (DefaultHistorian by default, which delegates to the History class), so you can easily replace the implementation there.

But really, I wonder how you'll make it work OK with the back/forward browser buttons, particularly when going back/forth not a single "place" at a time (i.e. open the back/forth menu and go several steps back/forth; similar issue with bookmarks).

IMO, what you're trying to do is simply impossible.

[Jeff Schwartz]

I agree with Thomas and would add the behavior your are seeking to implement is counter intuitive to what people expect when using browser history. As such then I'd either try to adapt the application so that the browsers navigation mechanism maintains the user's expectations or forgo using history altogether which isn't such a far fetched idea considering the power that GWT provides for creating applications that mimic desktop applications; you can legitimately consider not using history a viable solution. I've done just that when I was in the designing phase of my latest application, http://lovemyvehicle.appspot.com/, and I decided to only use navigation for the registration process which is sort of a wizard (at least at this time, it might change as I give it more thought and get more feedback). Once a user has become a member and logs into the application it uses no navigation at all.

The application my members see is highly modeless. State is maintained in most of the views so that switching to another view and then back using the applications menu structure brings the user back to the same view and state they were at before they switched views. Communication between views is via an EventBus and events are consumed by all concerned views so that when one view's state is changed it is immediately picked up by any view interested in the event. This model is very intuitive and I am getting a lot of good feedback on it.

So what I am suggesting is that there are alternatives to history if you are so inclined to imagine them.

Good luck.

Jeff

--
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-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

--
Jeff Schwartz

[Jeff Schwartz]

BTW, the app is still in development and there's lots of good stuff still left to implement but I have a rather large number of members already who I think are mostly interested in (at this time so far) seeing how my implementation is progressing.

Jeff

--
Jeff Schwartz

[Y2i]

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, "cmarsh...@avenue100.com" <cmarsh...@avenue100.com>
wrote: