As a plugin developer, I want to render the output of my macro in the editor

XMLWordPrintable

      NOTE: This suggestion is for Confluence Cloud. Using Confluence Server? See the corresponding suggestion.

      Sometimes macros are reasonably simple in terms of what they output, e.g. the Status Macro. In order to approximate to WYSIWYG, the only choice these macros currently have is to use the EditorImagePlaceholder in order to create an image of the rendered output.

      This is suboptimal for several reasons:

      • Browsers render HTML/CSS slightly differently, the image output will always be just an approximation
      • There are no good JVM-based HTML/CSS render engines out there, the best bet would be to either use Flying Saucer (only supports CSS 2.1) or to ship with one of the Browser's rendering engines (e.g. WebKit wrapped in QtWebKit via Qt-Jambi

      Any solution using this approach will be unnecessarily complex when the goal is to just use the output of the macro in the editor. There is also a CustomHtmlEditorPlaceholder interface available, but the implementation is also restricted to img and object tags.

      I've identified the following reasons for why the editor applies these restrictions so far:

      • the custom HTML should not be editable, as it gives the user the impression that whatever he puts inside the placeholder will be persisted for the page, but that code is just "thrown away"
      • images are single elements without a text node, thus the cursor never jumps in, and drag&drop is easy to implement

      As for the first restriction, imo that should be a decision made by the plugin developer. One possible implementation I envision for this is to utilize TinyMCE's noneditable to signalise the user that the content is not editable. Also this plugin has its quirks, if the user somehow gets into the placeholder and starts editing the only effect is that this edit gets lost. If that happens often we can iterate on making the plugin better or even add supplying JS signalising the user that he's in the wrong spot.

      As for the second restriction, it is easy to identify the placeholders root element as it contains all the attributes a normal macro contains in the editor (e.g. data-macro-name), thus Drag&Drop should be relatively easy to implement for that.

      I'd suggest modifying the CustomPlaceholderEditorMarshaller to allow custom HTML beyond <img> and <object>. For the old tags it should just behave like it did before, but for anything else it should just make the content not editable with the above mentioned noneditable plugin.

              Assignee:
              Unassigned
              Reporter:
              fabs (Inactive)
              Votes:
              2 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                Resolved: