Class HTMLEditorKit

java.lang.Object
javax.swing.text.EditorKit
javax.swing.text.DefaultEditorKit
javax.swing.text.StyledEditorKit
javax.swing.text.html.HTMLEditorKit
vaadinx.swing.text.html.HTMLEditorKit
All Implemented Interfaces:
Serializable, Cloneable, Accessible
public class HTMLEditorKit extends HTMLEditorKit
Emulator for HTMLEditorKit — the carrier for author CSS on an HTML JEditorPane. Supports the field's dominant render-only idiom: 
JEditorPane pane = new JEditorPane();
HTMLEditorKit kit = new HTMLEditorKit();
pane.setEditorKit(kit);
kit.getStyleSheet().addRule("body { font-family: sans-serif; }");
pane.setEditable(false);
pane.setText("<h2>Report</h2><ul><li>one</li></ul>");

Scope: the stylesheet, not the rendering pipeline

The kit's job here is to carry a StyleSheet to the pane. It does not drive rendering: Vaadin's RichTextEditor renders the pane's HTML, and the JDK's rendering path is built on View.paint(Graphics, …), permanently out of scope per R_match_swing_errors sub-bucket (b). So HTMLEditorKit.getViewFactory() answers with a real factory (inherited, so subclassing it compiles) but nothing consults it — a custom ViewFactory is inert. That costs migrated code nothing in the one idiom that actually appears in the field: a factory that refuses <img> views so a report pane never hits the network, which is already our behaviour since images outside base64 data-URLs are dropped anyway.

Headless parsing needs nothing from us

Code that uses this class purely as an HTML scraper — a ParserCallback handed to javax.swing.text.html.parser.ParserDelegator, no pane in sight — keeps working after an import swap, because the nested callback types are the JDK's own by inheritance. The one seam that does not survive is subclassing Parser itself: an override written as parse(Reader, ParserCallback, boolean) resolves the parameter to this class's inherited nested type, which is the JDK type, so it compiles — but a hand-written signature naming a vaadinx callback type would not. ParserDelegator is the documented way in, so this is a corner rather than a road.

What drops-and-WARNs

insertHTML(HTMLDocument, int, String, int, int, HTML.Tag) — splicing markup into an HTMLDocument needs the element model that is not built (there is no HTMLDocument behind the pane; the emulator keeps a PlainDocument). read / write likewise: the pane's own setText / getText are the supported way in and out.
See Also:

  • Constructor Details

    • HTMLEditorKit

      public HTMLEditorKit()

  • Method Details

    • getStyleSheet

      public StyleSheet getStyleSheet()
      This kit's own stylesheet. Unlike the JDK, the sheet is not shared with other kits — see StyleSheet for the rationale.
      Overrides:
      getStyleSheet in class HTMLEditorKit

    • setStyleSheet

      public void setStyleSheet(StyleSheet s)
      Install a stylesheet. A vaadinx sheet takes effect; a JDK-typed sheet has no way to reach the peer and WARNs, leaving the current one in place — failing to style is better than silently accepting a sheet that can never apply.
      Overrides:
      setStyleSheet in class HTMLEditorKit

    • _bindTo

      public void _bindTo(com.vaadin.swingbridge.surrogates.SJEditorPane peer)
      Framework-internal (the _ prefix marks it, as on _installSwingClass): bind this kit's stylesheet to a pane's peer. Called by JEditorPane.setEditorKit from a sibling package; the peer is remembered so a later setStyleSheet(StyleSheet) reaches it too. Not part of the emulated JDK surface — migrated code has no reason to call it.

    • insertHTML

      public void insertHTML(HTMLDocument doc, int offset, String html, int popDepth, int pushDepth, HTML.Tag insertTag)
      Overrides:
      insertHTML in class HTMLEditorKit