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.
|
