Everything changes quickly. New ideas, technologies and tools enter our life rapidly and revolutionize everything we do. Internet is one of most significant technical innovation that affected social life. Good old web pages created in simple plain HTML revolutionized society for information exchange and personal communication.
More and more online applications offers user interface that is similar to ordinary desktop applications (and sometimes even richer) and such trend will increase even more as time goes by.
But wait! There is important feature of every well-designed desktop application that is foreigner in AJAX applications realm – undo/redo mechanism (of course, we do not consider back-forward mechanism built into browser as a kind of useful undo implementation)
So the question is - can we get universal undo manager? Sure thing, we can do it and we can do even more than plain undo/redo.
Well, let us stop chatting and lets go into details!
First, let’s consider what undo manager is.
The main purpose of undo manager is a recording of undo and redoes operations. Undo manager makes it possible for users to correct their mistakes and to try out different aspects of the application without the risk of repercussions.
Undo-redo mechanism provides such abilities as:
Un-execute (undo) the last action they just performed.
Re-execute (redo) the last undone action.
So, there is a set of user actions and there is a manager that can manage. That is all - now we are ready to build it.
Undo Manager Anatomy
Actual details are boring, but here they are:
First, we utilize concept of “actions” that contains logic how to do something. This concept is similar to one used for building user interface in Java and Delphi.
Since we are going to build undo manager, we need a special kind of actions – Undoable ones. Undoable Action is such a kind of action, which is not only aware of how to do something, but also how to get back to the starting point.
Undoable action consists of two unfold operations: DO and UNDO. Idea behind them is simple – imagine that there is some variable and we want to add two to it. We create action that does add-up (let us name this action DO.) Obviously, the action, which corresponds to the UNDO wills subtract two from it.
The undo manager records commands on a stack. When the user undoes a command, the undo manager pops it from the stack, revealing the previously executed command. Once a user has undone at least one command, executing any new command clears the undo stack.
The Undo Manager may record undoable action in two ways:
Calls undoable action (or not calls - we are not controls it) and adds it to undo stack.
Adds undoable action to undo manager undo stack and automatically calls DO method of the action. If it was performed successfully, Undo Manager adds the action to undo stack, otherwise - calls DO error processing
Well, in general, that’ all. Of course, it is possible to add many code snippets, diagrams and technical details. However, seeing is believing – please click the
to find a small live demo of working undo manager.
Ok, so far so good.
Undo manager works on client side using Java Script, sun is shining and cold beer is waiting in the cooler and life is good. But not so fast.
We have missed one important point so far– the end user may leave the page where our undo-manager resides and therefore all history could be lost. Of course, it is possible to make some dirty tricks with frames, but frames today are out of law (and they also do not provide the way to save our data if the user presses page refresh button that refreshes entire frameset) so we need to have more elegant solution.
Certainly, we can solve the particular task (every time) and store only part of necessary data in JSON or in some custom, but such an approach seems to unattractive, repetitive and boring – especially, if it is possible to have some generic and reusable solution.
So, it seems that the only one thing, which can help us tin this situation is to store internal state of Undo Manager to server and be able to request it from there at any time client needs it.
While this sounds rather simple, actually it is not. The main problem is in the fact that it is necessary to serialize internal objects (actions) stored within Undo Manager into some text format and restore them from it.
Fortunately, JSONER library provides such functionality that includes serialization of Java Script object (including corresponding methods of them, type of the object, links on another objects etc) in JSON-like form.
So, here we are – as necessary, we could store state of the Undo Manager to the server and restore it from there. Therefore, as user returns to the page, it continues to work smoothly with it (of course, if such behavior is required by logic of application).
Ok, undo manager is fine and could be used in various places by their direct purpose.
But this is not all.
Since we have actions and may to invoke them subsequently (as undo manager does) – why we can’t move further and create automated demos, or record and re-play user actions?
Just imagine how simple development of some guided tours could be if web application were built using approaches described above… Actually, the only thing that defines boundaries of possible usage there is imagination and creativity of application designer.
Well, here is an examples that illustrates virtual trip over Google Maps - and that example was created using technique described there.
Such an example demonstrates that it is possible to plug successfully the functionality offered by JSONER library into existing system that was developed without approaches listed there.
If you have some ideas on how such an approach could be used or you have some needs to do something similar – please share them with us and we hope we could help you.
Is it long-awaited silver bullet?
Yes, of course, we believe so (at least, for specific types of applications) ?
Actually, such a design was used in real working system within online journal editing component (used in online publishing system) and proved to be both convenient and effective.
If you build complex Java Script based application that includes tight interaction with the end user it worth to spend some time to take a good look at this approach (and probably let your users to say something like “Cool!”, “Great!” or “Terrific!”).