Hide rendering meta data from the edited document

One of the main problems we currently have on the new GWT-based WYSIWYG editor is the presence of rendering meta data in the edited document. The rendering needs this meta data to recompute some parts of the wiki syntax that might otherwise get lost during the wiki-HTML-wiki conversion. We have to make sure the meta data is not corrupted by the editing operations taken by the user. Let's take the example of image meta data. If you write the following in the wiki editor:

image:logo.jpg

and then switch to WYSIWYG editor, the HTML generated look like this:

<!--startimage:logo.jpg--><img src="/xwiki/bin/download/Sandbox/Test/logo.jpg" class="wikimodel-freestanding" alt="logo.jpg" /><!--stopimage-->

The meta data are here the startimage and stopimage comments plus the class attribute on the image tag. While the class attribute is pretty safe from corruption, it's not the same for the comments. They bring the following problems:

• In some cases the user can place the caret between the image tag and one of the comments. The text inserted there will be ignored by the parser.
• If the user clicks on the image and deletes it the comments remain in the DOM and the image declaration will still be present in the wiki syntax.
• The comments are not dragged with the image.
• In Firefox the user can delete both of the comments with Delete and Backspace keys.

We face similar problems in the case of link and macro meta data. The solutions we had so far are:

• The hard way: we listen to all sort of DOM events and user actions to ensure meta data integrity.
• The ideal way: we put all meta data in (custom) attributes because, as I previously mentioned, they are safe from corruption. That is because, although they are bind to an element, they are not part of the content flow.

The solution we're proposing here is to hide meta data from the edited document. Precisely, the meta data will be attached to an element but it won't be anymore part of the content flow. Let's get back to our previous example. We can have the following:

// the target element, part of the content flow
<img src="/xwiki/bin/download/Sandbox/Test/logo.jpg" class="wikimodel-freestanding" alt="logo.jpg" />

// the meta data, a document fragment, attached to the JavaScript object representing the element, but out of the DOM tree
<!--startimage:logo.jpg-->com.xpn.xwiki.wysiwyg.client.dom.Element#placeholder<!--stopimage-->

To achieve this we have to overwrite to methods:

// Element
public void setInnerHTML(String html) {
  // set the inner HTML
  // notify the listeners, which will extract the meta data from the resulted DOM subtree and attach it to the corresponding elements
}

public String getInnerHTML() {
  // walk the subtree rooted in this element and compute the inner HTML taking into account the meta data
}

Each WYSIWYG plugin can register an InnerHTMLListener on the edited document to be notified when some element's inner HTML changes. Plugins like Image, Link or Macro will simplify the DOM tree by extracting the meta data and placing it in a Element's instance field using:

public void setMetaData(DocumentFragment metaData) {
  // attaches the meta data to the underlying JavaScript object
}

public DocumentFragment getMetaData() {
  // returns the meta data or null if there's not meta data attached to this element
}