Question

I have a GWT two column display. The left column contains a CellTable with a list of users in the application. When the user selects an user from the list, the right column displays the selected users details – which the user can edit.

I have my Activity wired up to use the mayStop() method so that before switching users, the system will attempt to save any unsaved changes the user has made – as long as there are no validation errors.

My question is about the behavior if there are validation errors. I have it wired to ask the user to discard the unsaved edits or return to the page and correct the issues. My problem is that when the user hits cancel (to return and correct the errors), the cell table still “selects” the new user instead of keeping the user that’s in the detail column selected. It appears that switching away from the user activity was canceled, but GWT is still making the CellTable selection. Is there a way to capture the “Cancel” selection, or stop cell table selection from occurring?

Answer 1

From looking at the source of PlaceController, which triggers the eventual calls to mayStop() and onStop(), two different events are called, one for each. PlaceChangeRequestEvent goes first, indicating (predictably) that a change is being requested, but hasn’t finished yet. This will call mayStop().

Then, if the user doesn’t elect to cancel the change, PlaceChangeEvent gets fired, which calls onStop(). Otherwise, this will never be called.

My approach would be to base the actual selection in the left column based on these events. There isn’t a handy way to stop/cancel selection, so there is no nice way to actually manage the selection, and delay it after the user provides their feedback. My thought would be to either

• Don’t actually select when the user clicks, just effect the place change. Then, when PlaceChangeEvent is fired, actually make the selection. This is slightly gross, as I see no convenient way to cancel selection. Or
• Keep track of the last selected element after the user changes the selection (as opposed to the place). Listen for the PlaceChangeRequestEvent, and schedule a deferred command to select that original item, and listen for PlaceChangeEvent to skip the body of that command. This should work, since the alert presented to the user is blocking – I haven’t actually tested it though.

If you are wiring the place changes into the url, you already need a PlaceChangeEvent handler to watch for the user clicking the browser forward/back buttons, so keep that in mind when you decide how to wire this – the place change should drive selection, just like selection needs to drive the place, but if the user clicks back, and cancels the place change, then the celltable should keep its original selection.