Class HTMLDocument

java.lang.Object
javax.swing.text.AbstractDocument
javax.swing.text.DefaultStyledDocument
javax.swing.text.html.HTMLDocument
vaadinx.swing.text.html.HTMLDocument
All Implemented Interfaces:
Serializable, Document, StyledDocument
public class HTMLDocument extends HTMLDocument
Emulator for HTMLDocument — the read-only element model behind an HTML JEditorPane: 
pane.setContentType("text/html");
pane.setText("<h2>Report</h2><p id=\"total\">42</p>");

HTMLDocument doc = (HTMLDocument) pane.getDocument();   // the JDK type
Element total = doc.getElement("total");
Element root  = doc.getDefaultRootElement();
Extends the JDK class (D_htmldocument) rather than porting it, which is what makes that cast compile — javax.swing.text.html.HTMLDocument stays JDK on the import swap — and what makes the element tree the JDK parser's own work rather than emulation.

Read-only: a projection of the pane's markup

The pane owns the markup; this model is reparsed from it on every change (setText, setPage, a browser edit). So getText(0, getLength()) here is the rendered text, as on a real HTMLDocument, while the pane's getText() keeps returning markup.

The six HTML mutators (setInnerHTML(Element, String), setOuterHTML(Element, String), insertAfterStart(Element, String), insertBeforeEnd(Element, String), insertBeforeStart(Element, String), insertAfterEnd(Element, String)) WARN and change nothing: writing through them would mean serializing this model back to RTE-subset HTML. A console or transcript pane that appends through them rewrites to pane.setText(pane.getText() + html).

HTMLDocument.setBase(URL) / HTMLDocument.getBase() round-trip but redirect nothing — links resolve against the pane's loaded page (SD_hyperlink_listener) and RTE takes only base64 data-URL images (SD_sjeditorpane_rte).

getElement(id) serves server-authored markup only. The editor does not carry id attributes back out, so once content has round-tripped through a browser edit the ids are gone and the lookup answers null. What setText / setPage put in is fully addressable; what the user typed over is not.

Reparsing is eager, skipped when the markup is unchanged, so the model is never stale and DocumentListeners fire at the change rather than at the next read. Warm cost is ~0.1 ms for a small pane, ~1.9 ms for a 200-paragraph document; a lazy dirty-flag refresh would fit behind _setMarkup if that ever bites. A document user code builds itself — new javax.swing.text.html.HTMLDocument(), kit.createDefaultDocument() — is untouched JDK behaviour, mutators included; this class is only what a pane hands out.

See Also: