Early feedback on PlaceController/ActivityManager

[Thomas Broyer]

Aside from not being plugged with the History (yet), the one thing
that bothers me (a little), something that I have in my current (very
own) PlaceManager that isn't in PlaceController/ActivityManager, and
contrary to History-binding has an impact on the API, is plumbing
between PlaceController and WindowClosingEvent.

As it is done now, a PlaceChangeRequestedEvent can be "rejected",
which prevents a PlaceChangeEvent from being fired subsequently. At
the Activity level, the "current activity" can refuse to
"stop" (willStop() returns false).

I suppose the intended use that the PlaceChangeRequestedEvent handlers
(or the current Activity) eventually displays a Window.confirm(...) to
condition the call to reject() (or the return value of willStop()).
All is well, but what happens when the user closes the browser window/
tab?

In my PlaceManager, the PlaceChangingEvent is very similar to the
WindowClosingEvent, i.e. you can cancel the action, but you have to
give a message to be shown to the user. The Window.confirm(...) call
is done in a ConfirmationCallback given to the PlaceManager. What it
means is that on a WindowClosingEvent, a PlaceChangingEvent is fired.
If a handler wants to "request cancellation", it sets a message on the
event. The message is then set on the WindowClosingEvent so that the
browser shows its own confirmation dialog, with the application-
provided message.
In other cases (i.e. not WindowClosingEvent, that can be a history-
driven or programmatic navigation), when a PlaceChangingEvent is
"rejected", the message is passed to the ConfirmationCallback, which
returns a boolean, which conditions the firing of a PlaceChangeEvent.
(in my original design, the ConfirmationCallback could be asynchronous
to allow uses of a DialogBox for instance, but it has all sorts of
implications –i.e. what happens when a WindowClosingEvent or history's
ValueChangeEvent is fired while "confirming" a previous navigation
request?– so I only implemented the synchronous confirmation, in the
form of a "boolean confirm(String message)" method on the
ConfirmationCallback interface).

My design supposes a PlaceChangingEvent's "rejection" is always
subject to a "confirmation" (by the user), which is maybe not the case
in the proposed GWT's PlaceChangeRequestedEvent.

Do not hesitate to ask for more information on my PlaceManager. Ray
(and other G-men; I put Ray in Cc as he's the only one of you who
committed on these classes), I have a still-draft detailed description
of my PlaceManager and particularly where I started from and how I've
arrived there in Wave (& exported to Google Docs), but it's in French
(the idea was that Google Docs could help me in translating it to
English, so if you want, I can give you access to an automatically-
translated-by-Docs version).