.. _pages/ui_html_editing/undo_redo#undo_and_redo:
Undo and Redo
*************
.. _pages/ui_html_editing/undo_redo#limitations:
Limitations
===========
The implementation of undo/redo in the HtmlArea has some limitations you should be aware of.
It is possible to ``undo`` all of your steps but ``redo`` is only possible when no other action occured between the undo and the redo action. If you undo several steps and e.g. enter some text you **can not** execute redo anymore.
.. note::
If you use the Undo/Redo functionality you have to make sure you are not manipulating the content of the HtmlArea by using the ``innerHTML`` property of an element.
**This will break Undo/Redo functionality!**
.. _pages/ui_html_editing/undo_redo#implementation:_description_on_a_high-level:
Implementation: Description on a high-level
===========================================
The implementation is split up into two different approaches.
For Internet Explorer the ``execCommand`` approach can't be used anymore. The internal undo / redo stack gets broken on every DOM manipulation. So, if any qooxdoo decorator is used this approach is a dead end. Instead an own implementation using ``innerHTML`` is used for IE browsers.
For all other browsers the base of the Undo/Redo functionality is to use the ``execCommand`` method to manipulate the content **whenever** possible. Each change which is performed with a call of ``execCommand`` is easy to undo/redo. For any manipulation which cannot be achieved using the built-in ``execCommand`` a special implementation for each browser is necessary (e.g. changing the background color of the whole document).
.. _pages/ui_html_editing/undo_redo#using_the_decorator_pattern:
Using the Decorator Pattern
---------------------------
To easily integrate the undo/redo management with the commands of the HtmlArea the ``UndoManager`` class is a decorator of the ``CommandManager`` class. It takes the method calls from the HtmlArea class, collects the info for undo the action and calls the decorated ``commandManager`` class to actually perform the requested action. This keeps both implementations clean and separated.
.. _pages/ui_html_editing/undo_redo#tracking_changes_using_stacks:
Tracking changes using stacks
-----------------------------
Two stacks keep track of the changes which are done to the content: an **undo stack** and the corresponding **redo stack**. Currently each stack holds four different types of changes:
* Command
* Content-block
* Custom
* Internal
Each entry in the stacks is represented by an object which holds additional info (the type above is among this info).
.. _pages/ui_html_editing/undo_redo#command:
Command
^^^^^^^
Every change which is performed with the ``execCommand`` method is equipped with this type. These changes are the easiest to track and to undo/redo.
.. _pages/ui_html_editing/undo_redo#content-block:
Content-block
^^^^^^^^^^^^^
Each keypress event is observed to determine changes in the content and to mark a set of content changes as an own block which is capable for an undo/redo step. For example IE and Gecko do both recognize text changes as a content block if the text changes occured between two calls of ``execCommand``.
.. _pages/ui_html_editing/undo_redo#custom:
Custom
^^^^^^
These changes are the ones which cannot be handled with the built-in ``execCommand`` method. For example changing the background color of the whole document is a custom undo/redo step which needs to be handled in a special way by each browser.
.. _pages/ui_html_editing/undo_redo#internal:
Internal
^^^^^^^^
These steps are included to keep the stacks intact if the user e.g. resizes an images with the handles provided by the browsers. It is possible to undo/redo these internal changes with the common ``execCommand`` method. The primary task here is to record these changes and add them to the stack(s).