> > > From: Steve Finkelstein > > > I was curious if there is anyone currently working on > > > an 'Undo' type plugin for the jQuery platform. Essentially, > > > similar functionality to what gmail offers is desired by > > > many. If not in the works, I wouldn't mind giving it a > > > shot myself.
> > From: Jörn Zaefferer > > Implementing an undo functionality requires quite some > > work on the serverside, as it is always some persistent > > state that is undone. Where do you think could a jQuery > > plugin help to implement that? I have a purely client-side undo plugin, in case that is of any interest. It's not really like GMail - it has no connection with anything on a server, and it uses Undo and Redo buttons that are enabled and disabled in a more traditional UI fashion. I use it in a color theme picker for our Zvents event calendar widget. The color picker lets you adjust colors individually for any of the theme elements, and also has master color controls that automatically select a matching set of colors. I realized I needed this the first time I hit one of the master controls after experimenting with some of the individual controls. The master control blew away all of the individual colors I'd picked. Undo fixes that and makes it easy to experiment with different colors. > From: John Beppu > Even if you just want a purely client-side undo mechanism > (that delayed sending to the server until you're ready), > you'd need to maintain some kind of event queue. That kind > of thing tends to be very app-specific, and it's hard thing > to generalize w/o defining a lot of policy about what > constitutes an event. Callback functions make it easy to separate out those concerns. The undo plugin manages the event queue itself, but it doesn't care about the content of the queue entries. When the app has a new undoable state, it creates a state entry and calls the undo plugin to save it in the queue. When there is an undo or redo event, the plugin grabs a state entry from the queue and passes it back to a callback function that the app provided, so the app can update its own state. In the case of my color picker, each queue entry is a CSS string that defines all of the colors in the picker. IOW, the queue entries aren't "change" transactions, but represent the entire page state. That makes the code simple for this particular use case - the app code generates and parses the complete CSS string anyway, so it just uses that format for the undo state queue. Even with the application code handling the actual updates, there's still a fair amount of work for the undo manager to do, what with enabling and disabling the undo/redo buttons, handling some subtle keyboard focus issues, and managing the queue itself. Also, the queue is kept in a hidden form field, so the page state survives a soft reload. That wasn't really a requirement, but it was easy to do and nice to have. Also I've been meaning to add a few features but haven't gotten around to it because I didn't need them for my own use: 1) Make the buttons optional, with callbacks when they are enabled and disabled, so you can change the UI. 2) Support change transactions in the event queue as an option instead of "complete state" queue entries. Since the plugin doesn't care what the queue entries mean, this shouldn't be much different from the current code - I just haven't thought about it yet. 3) Allow the use of objects as state queue entries as an option instead of strings. The undo manager code would work fine either way, except for the way it stores the entries in a hidden form field. If it stored them in an array they could be objects - at the cost of not surviving a soft reload. Anyway, I must have a working demo somewhere - I'll track it down and post a link. -Mike
