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). -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
