Thread:VisualEditor/Feedback/Suggestions for editing templates transclusions


 * In my opinion, the visual editor should allow editing template transclusions by presenting editing them in a visual table containing the list of positional parameters and the list of named parameters in two colums (one column for the name, one column for the value. It should also allow viewing the template page by pressing a button opening a scrollable frame (for getting access to its documentation), so that we can add the correct parameters in this editable table, as instructed in the template doc page. This editable table should be done within a popup dialog, because most templates will have a very different layout when rendered, not suitable for editing.
 * On the non-mobile version of MediaWiki, this popup could be a frame docked below the menu bar, and not using more than half the screen height. It should be also dockable on the right, for users that have wide screens: the left side shows the visual content of the page, and shows the rendered template as it is edited, the right side is for editing that template, and this docked template transclusion editor can be subdivided in two parts to showing the doc page of that template.
 * In addition we should be allowed to select another template name, keeping the parameter list (and if we do that, the doc page shown should reflect this change).
 * To select templates, we should be allowed to navigate in the list of categories for the current template (just like with the CatALot extension).
 * Similar navigation in categories should be possible as well when adding a cateofy to a page, when we don't know the exact name of the category, we wi still find other relevant categories, instead of beaing presented only a list of categories containing some existing words.
 * When editing template transclusions, all whilespaces should be preserved unless we actually edit a field (template name, parameter name, parameter value. This would preserve HTML comments most of the time and would minimize the number of changes in diffs.
 * Note also that template parameter names, or or template names way also transclude other templates (or could contain invokations of parserfunctions). These subparts present these fields should be marked as non editable.
 * Some whitespaces that are present at start or end of fields for parameter names or values or template names should be preserved (only duplicate SPACE characters may be simplified in the middle of the editable field, and whitespaces characters BEFORE a newline. HTML comments should be kept as much as possible, and should be made accessible in the editor, treated as an editable subelement.
 * When template transclusion parameters (or template name) contain another template transclusion, this creates the opportunity of recursive editing. The UI can still be made cleanly, by clicking on this field to open a new tab in this editor. When such a recursive edit is done, the visual rendering on the right side should also give the rendered result of this invokation to show its result, replacing temporarily the rendering of the full page (the full page can still be seen by selecting the first tab automatically created, the second tab being for the 1st level of edited template invokation. We can close the secondary tabs by confirming or cancelling the edit of one level of invokation (this also close tha tabs for its sublevels).
 * So in summary: we click the redenred box where the template transclusion appears in the visual page, this adds a row of tabs docked just below the menu bar, and a docked properties pane splitted in two parts : one part for the editable parameters in a table or in a vertical list, another scrollable part for showing the rendered template doc page, and each editable field in the 1st part is just a clickable list of field names, whose value appears in the visual preview (it activates a tab at the top), where actual values are entered visually (we constantly can click on the FULL PAGE tab to view the result in the full page.
 * And remember: ALL fields in a template transclusion (tempalte name, parameter name, parameter value) may contain one or more transclusions or invokations of parser functions, each one should have a rendered view accessible from a tab at the top, and viewable in its context ov invokation as if it was clickable element for editing it, or deletable. HTML comments should also be visible or invisible with a checkbox option in the top menu bar, as if they were inline content (i.e. in a subbox). And probably the preview pane should allow showing either the pre-rendered content, or the associated wikicode (if the wikicode is active, the properties pane is disabled or hidden, but tabs remain present at the top; the wikicode or visual rendering mode is a property associated with each open tab).

Similar editing should be possible as well for working with invokations of parser functions (which are mostly like template transclusion because they are just a list of editable subfields), or for inclusions of extension tags (like the search box), except that most parameter names or order are known, and that they don't have their own doc page which is located elsewhere on the Mediawiki.org site. One basic design idea would be that each extension tag or parser function should have a way to register a "hook" for filling a list of properties, some with fixed self-explanatory names subject to translations), specific to the extension (and with status giving their type and mandatory/optional status), some just listed in a defined order without names (or a name equal to an integer number starting by "1"):


 * These hooks would handle themselves if they can strip whitespaces, and would also provide some validation for fields editable as plain text, and saying if values may embed other tags, or if it should remain plain-text, or if the value must be one in a list of provided values.
 * The VisalEditor would provide the Interface itself in the properties pane, would create the necessary tabs and navigation. The VisualEditor may provide several layouts for editing these properties: either a pane-less mode where data is entered directly in the preview pane, or an edit within a "bubble" pane appearing on top of the page, for basic tags, or the full properties pane docked on the side from the preview pane.
 * The hooks will also generate the wiki code, that they will also render themselves (a hook could also generate additional wiki code that won't be saved in the article but which is required to give some meaning to the edited tag or function with an API like "getPreviewCode". To implement this API, when the inner parameters can embed additional tags edited separately, they will call a part of the API that calls the appropriate "getPreviewCode recursively in the appriate hooks for their tags. Note that the preview code will often be a bit different from the code that will be saved (it will limit some interactions with it, for example the visual preview of links don't work as links, buttons are inactive, tables don't sort, videos are not played when clicking on them, and a yellowish frame surrounds the element when the mouse hovers them in the preview pane, all of this depending on the type of edit mode best chosen for implementing the tag editor and integrating in the VisualEditor...)
 * When saving (or when the preview pane is replaced in edit mode by the wikicode edit mode, these hooks will only generate the editable wiki code containing everything, within unparsed contents for the parameter, i.e. the complete syntax of the tag and all its parameters and contents (in that case the properties pane is hidden or disabled; we have a top button above the wikicode editor that allows switching between the wikicode edit mode and the visual edit mode).
 * One of these tag/function extensions would manage the inclusion of images and media ; another would manage the inclusion of reference notes (and the hhok would provide an additional wiki code  that will not be saved in the the edited wikicode only in the view pane, but that will be appended in the preview pane that shows the note call in its context where it is inserted in the page); another will manage parser functions (one for each parser functions extension, another will manage template transclusions.
 * The hooks will also indicate if they have a documentation page to display below the properties pane, by an API like "getDocumentationURI" to help understand its usage, and may be links to the applicable policies (so the documentation pane will include a scrollable frame (links on the documenttion page may open a new tab in the browser to avoid complications, if you don't want to use HTML frames).
 * All this would finally allow editing complex codes (with lots of "{}" braces) in a much easier way, with less errors: just click one tag in visual mode to access to the subtag and its parameters in a new pane and with its new navigatable visual tab).
 * Note that when an extension hook provides flags for editable fields, if one of these flags says that the parameters will have its leaning and trailing whitespaces ignored and stripped by the rendering, the wiki editor should allow using a "pretty-printing" mode using automtic indentation (but a hook may also provide itself an API like "getPrettyCode" to format this code, or other presentation features like syntax coloring (recursive as well when subtags are embedded, using some code generators for fixing things like indentation levels).
 * All these hooks will be optional (the Visual editor will provide a default reasonnable interface, that each extension may override with their hooks to get easier editing mode. For example, the default will not validate the edited values of editable fields. The Visual editor will understand the wiki syntax using braces, colon and pipes by default, and the HTML or XML syntax of tags (with a leading tag name, a list of attribute names, their values, the inner content, and the end-tag marker (possibly abbreviated as "" in special tags like "tvar", or unnessary for some HTML5 tags where they are implied like in "li" elements).

Finally the current editing of categories in the "Page properties" menu is really a bad idea (it is also counter-intuitive). It should be done like in CatALot, by editing them at the bottom of the visual page, where they are effectively displayed, like in CatALot. I really suggest the integration of a working mode like CatALot, integrated and adapted in a specific version for the VisualEditor (CatALot should remain a separate extension).