Hi Paul,
There are several ways to resolve this situation. One of them is a bit
awkward solution and it may not fit correctly within your surrounding
logic (so you must be careful) but it is relatively easy to setup:
Declare an instance boolean flag variable at the right place (let'
name it "isActionConfirmed") and make your code in method onBeforeClose
() check on this value to branch the logic in such a way that if the
action is confirmed then execute the action, reset the flag to false,
and return true from onBeforeClose().
If isActionConfirmed equals to false, then present an async modal
popup dialog (which captures a real user input) but return false from
onBeforeClose() in order to make the control flow stay where it is now
(and do nothing at this point). Having obtained the real action value
from user input you set the isActionConfirmed flag to true and invoke
the onBeforeClose() method on the TabPanel again.
@Override
public boolean onBeforeClose() {
if (isActionConfirmed) {
executeSyncAction();
isActionConfirmed = false; // Not any more! Reset.
return true; // State is saved by now.
} else {
showAsyncModalPopup();
// Code for popup will set the flag to true, if user wants
to save.
return false; // Keep the control flow where it
is.
}
}
Once again, such a workaround may introduce errors, so be careful. For
example, if there is code following the return of onBeforeClose()
callback and it assumes that the data is always saved then there is a
problem because we do return from onBeforeClose() (with false value)
without neither saving data nor having the user input yet.
Would be interesting to know it it works for you.
On Apr 26, 11:23 pm, Jeff Chimene <[email protected]> wrote:
> On 04/26/2009 09:40 AM, Paul Grenyer wrote:
>
> > Hi
>
> >> I'm not sure I understand this requirement. If you're talking about a
> >> GWT tab widget, no user data will be lost when the tab "closes". In a
> >> TabPanel, a Tab close event is usually associated with moving focus to
> >> another tab. No data loss occurs.
>
> > Even if that's the case, I still need to save the data that's been
> > entered onto my tab at that point.
>
> So this must be an application-specific issue. I cannot find a reference
> in the GWT Javadoc to a "tab close" event. Can you provide that
> reference? Perhaps you're reusing certain GWT widgets on a tab switch?
> If that's the case, perhaps instantiating tab-specific objects is more
> appropriate?
>
> > Any browser actions that can could result an irretrevable data loss or
> > irreversable write are , by design, synchronously cancelable (CGI
> > post, Window.onClose). Does this app. use a TabPanel in a non-standard
> > way?
>
> > Nope. All standard.
>
> OK
>
> >> For what it's worth, I've also found that it's helpful to simply
> >> implement automatic, asynchronous "save draft" behavior.Given the
> >> machinery that GWT provides, saving a user's data on their behalf is
> >> nicer than the "old style" technique where one would ask if changes
> >> should be preserved. This technique also provides a nice segue into
> >> some kind of application-specific history support.
>
> > The user may not want to save thier changes.
>
> That's why it's called "save draft", and happens automatically (I
> usually use a timer), in the background (i.e. asynchronously). The user
> is unaware the save is happening. The only indication is that the UI
> presents a history function that can automagically restore their work.
> The draft data is on the server. Probably not in a database, but in a
> session-specific storage area; which is an implementation detail that's
> not relevant to this discussion.
>
> >> This technique supports a "review before post" step. In this step the
> >> draft data are presented for review before posting to the server. The
> >> review -> post transition is synchronous and interruptible.
>
> > No with you here. Can you explain more?
>
> The idea is that the data are presented for review. The UI contains a
> pair of "abort/accept" widgets. The abort widget causes a transaction
> rollback step. The accept widget causes a transaction commit step. I
> understand you may not be using transaction semantics in your
> application. Please apply the previous statements to your application as
> appropriate. The idea is that the user can choose to persistently save
> their work. This review -> post transition can be compared to the
> "prepare" and "commit" phases found in the two-phase commit protocol.
>
> On the other hand:
> Consider the UI in an "options" dialog box in your favorite IDE. Such a
> dialog box usually has two or more tabs. On each tab panel there are
> usually three buttons: Apply, Cancel, OK
> Apply implements a "save draft" behavior. It changes the IDE state, but
> does not close the currently open dialog box.
> Cancel closes the dialog box. It might rollback any IDE state changes.
> OK closes the dialog box. It executes an Apply and commits those changes.
>
> Perhaps this type of UI dialog is what you want to implement?
>
> >> If "canceling the close" is really the behavior you want, try
> >> scheduling a deferred command in the onCloseHandler that sets focus to
> >> the tab if the user does not want to close said tab.
>
> > Setting focus to the tab stops it from closing? :-s
>
> As I wrote above, I'm not really clear what you mean by a "tab close
> event." In an onTabSelected() event handler, you can implement a
> DeferredCommand that will switch the focus back to another tab if the
> user does not really want to switch tabs.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
