Uploaded image for project: 'XWiki Platform'
  1. XWiki Platform
  2. XWIKI-24845

Display a live preview of the macro output in the macro configuration dialog

    XMLWordPrintable

Details

    • Improvement
    • Resolution: Unresolved
    • Major
    • None
    • 18.7.0
    • WYSIWYG Editor
    • Unknown

    Description

      Context

      When a macro is inserted through the WYSIWYG editor, the configuration dialog shows only a form of
      parameters. To know what the macro will actually produce, the user has to validate the dialog, look
      at the result in the editor, reopen the dialog and adjust. For macros with many parameters – chart,
      liveData, documentTree, gallery, notifications – this turns into a slow trial-and-error loop, and
      for someone who does not already know the macro it gives no way to tell what a given parameter does.

      Proposal

      Show, inside the macro configuration dialog, a rendering of the macro as it would appear once
      inserted, computed from the parameter values currently filled in the form and refreshed when they
      change.

      This is not the "preview image" of the Macro Browser proposal

      The Macros Editor Integration
      proposal specifies a "preview image" for the Macro Browser: one static illustration shipped per
      macro, shown on hover while browsing the list of macros, and hidden for macros that provide none.
      That answers "what does this macro look like in general?".

      The present issue is about rendering the macro being configured, with the values the user is
      currently typing. The two are complementary and can coexist: the static image while picking the
      macro, the live rendering while configuring it.

      Points to settle

      • Which macros can be previewed at all. A preview means executing the macro. Macros with side
        effects, macros that need a real insertion context (footnote, putFootnotes, figureCaption,
        wikimacrocontent, wikimacroparameter) and macros whose output only makes sense within the whole page
        (id, toc) either cannot be previewed or need a degraded rendering.
      • Rights and cost. The preview executes the macro server-side with the current user's rights, so it
        must go through exactly the same restrictions as the real rendering. It also has to be debounced and
        cancellable, so that typing in a parameter does not trigger one rendering per keystroke.
      • Macro content. Whether the preview renders the content currently being edited, a placeholder
        content, or no content at all.
      • Error display. With incomplete parameters a macro will often fail; the preview must show that
        gracefully instead of a rendering error stack trace.
      • Layout. Where the preview sits in the dialog, and how it behaves for very tall or very wide
        output. Note that the Macros Editor Integration proposal already requires the dialog buttons to stay
        visible and only the dialog body to scroll.

      Attachments

        Issue Links

          Activity

            People

              Unassigned Unassigned
              Lucas C Charpentier Lucas
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

                Created:
                Updated: