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 -~----------~----~----~----~------~----~------~--~---
