Page MenuHomePhabricator

Add checkboxes to param list sidebar in VE TemplateDialog
Closed, ResolvedPublic

Description

Background

As a part of making working with templates in Visual Editor easier, we will change the way in which parameters can be discovered, added and removed from a template invocation.

Requirements

For the sidebar:

  • Sidebar is open on large screens and toggle-able on small screens, see T274554: Make sidebar responsive
  • Allow for multi-part template content (more than one template or wikitext) to be displayed/stacked in the sidebar and main dialog, see T274544: Support multiple transclusions (i.e. templates) in the new template dialog sidebar
  • The sidebar will display all parameters defined for the template (in TemplateData), not just those that have been added in the template dialog. See T274543: Create a new checkbox list view for the VisualEditor template dialog
  • Include any undocumented parameters present in the wikitext, in the sidebar. See T274550: Handle undocumented template parameters for full description of behavior.
  • The icon to the left of the parameter names is removed and replaced with an OOUI checkbox. These are used to add and remove parameters to the invocation of the template, i.e. shown or removed from the main input section on the right as follows:
  • Clickable area for the add/remove function is limited to the checkbox itself and does not include the name of the parameter. Clicking on the name of the parameters allows the user to jump to this parameter in the main input section on the right, and the cursor is inserted into that parameter's field (current behavior).
  • Current behavior should not be broken: The two scrollable windows should stay in sync. If the parameter is clicked then it should jump on the right side, but if on the right a new field is in focus the sidebar should also scroll to match and highlight the current parameter. See T274552: Synchronize scroll and focus between content and outline panes
  • When a parameter is not yet added, then clicking on the parameter name adds it. Clicking on the name again though does not remove it.
  • When a parameter is removed, keep the parameter "in focus"/selected if it's a named parameter and will remain, otherwise select the next parameter after the removed one (do not jump to top).
  • If template has TemplateData and no parameters, show 'No parameters' text instead of checkboxes. See T274549: Handle "no parameter" templates
  • Truncate parameter names that are too long for the sidebar (maintain current behaviour). See T285044: Fix parameter sidebar overflowing text ellipsis
  • If deprecated parameters already have a value, show in the sidebar. If they have no value, hide in sidebar so that they cannot be added. See T274551: "deprecated" parameter handling

For the main input area of the dialog:
[x] Remove the 'Add more information' dropdown at the bottom of the main input area, where parameters are currently added to templates. Not directly related and see T272487: New input for undocumented parameters

Order: (See T274545: Wire template parameters into the checkbox list view)

  • Order param list in sidebar and main input area based on:
  • If existing, use TemplateData order (ParamOrder or order of parameters as listed in TemplateData)
  • If TemplateData is missing, auto-order based on the order of parameters in the template definition/source code
  • Add undocumented parameters to the end of the param list.

Mock and Specs

Sidebar.png (600×240 px, 15 KB)
Screen Shot 2021-02-17 at 14.23.20.png (751×300 px, 42 KB)
Related tickets

Related Objects

StatusSubtypeAssignedTask
ResolvedWMDE-Fisch
ResolvedLena_WMDE
ResolvedLena_WMDE
ResolvedWMDE-Fisch
ResolvedWMDE-Fisch
ResolvedECohen_WMDE
ResolvedWMDE-Fisch
Resolvedawight
DeclinedNone
ResolvedNone
InvalidNone
Resolvedthiemowmde
Resolvedlilients_WMDE
InvalidNone
Resolvedthiemowmde
ResolvedAndrew-WMDE
ResolvedAndrew-WMDE
ResolvedNone
ResolvedNone
Resolvedthiemowmde
ResolvedAndrew-WMDE
ResolvedWMDE-Fisch
ResolvedLena_WMDE
ResolvedNone
Resolvedawight
ResolvedAndrew-WMDE
InvalidNone
Resolvedthiemowmde
Resolvedawight
ResolvedBUG REPORTWMDE-Fisch
ResolvedBUG REPORTthiemowmde
ResolvedBUG REPORTthiemowmde
ResolvedWMDE-Fisch
DuplicateBUG REPORTNone
ResolvedECohen_WMDE
OpenNone

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Lena_WMDE updated the task description. (Show Details)

@Esanders @matmarex We're discussing how to implement this feature and are stuck on a question that I hope you can answer. Would it be acceptable if we modify (or fork) one of the content-linked models, in this case ve.dm.MWTransclusionModel, to include parts which have no wikitext representation? Specifically, we would like to include all of the potential parameters listed in a template's TemplateData to simplify some of the synchronization between the panes of a BookletLayout (probably forking this class as well).

In other words, for a newly created template transclusion like Infobox book we would create all of the parameters like name, author, ..., native_external_host, etc. but these would be invisible until actually added to the template invocation. The implementation of methods like MWTransclusionModel.getPlainObject and .getWikitext would check for the "actually used" flag, and skip over any invisible parts.

Does this break the content model on a conceptual level? Would it be better if we introduce an abstraction above the content, to hold actual and potential content, and then synchronize from this model to actual content at the end of the workflow?

Sure, I think that's a good idea!

In fact we've recently done something similar (but more hacky and less thought out) for parameters marked as "suggested" in TemplateData, which are always added to the template, and which will now disappear if not filled out (T101075#6780815). It sounds like your approach would allow handling that better (we're definitely not attached to the current implementation of it).

Please make sure though that you don't lose the ability to add parameters to the template transclusion after it's created, for parameters not listed in TemplateData.

Lena_WMDE renamed this task from DRAFT: Add checkboxes to param list sidebar in VE TemplateDialog to Add checkboxes to param list sidebar in VE TemplateDialog.Feb 16 2021, 11:25 AM

We need some specification for how to handle parameter aliases. Here's my best guess:

  • When a template spec includes parameter aliases
    • Do not show aliases in the sidebar
    • Do not show aliases in the parameter placeholder
  • When a template invocation uses aliases
    • Show in the sidebar by checking the canonical parameter
    • Show in the content pane with the canonical label or machine name
  • If both a canonical and aliased parameter are present, or two aliased parameters
    • Let's say this is ambiguous, and we're okay with losing one of the two values after saving with Visual Editor.

And another detail: Currently, if a parameter is transcluded using an alias, that alias is preserved when saving the page. Do we want to keep this behavior? Otherwise, we cause "dirty diffs" when saving a template invocation, parameter names will change from alias to canonical just because the template dialog was used.

We discussed this in the daily today and I did a bit of further exploration on the UI side. Documenting the decisions here. Broadly, we are following the existing behavior. There are two situations to consider:

Parameter is not currently part of this template invocation / is not in the wikitext yet
Show Label from TemplateData. If no documented user-facing label, then show machine name/canonical label. In this situation, the alias is never displayed (though if the parameter search is used in the dialog, implemented in T272481, then searching for the alias will show the parameter in the results list under the label or machine name).

Parameter is already part of the template invocation / is visible in existing wikitext
Show Label from TemplateData. If no documented user-facing label, then show whichever name is used in the wikitext, including if an alias is used. On save the parameter name in the wikitext should remain the same (no dirty diffs).

All situations
There is never more than one label shown at a time next to the checkbox or in the main area.


I'm not sure I understand this piece of it though. Is it covered with the above direction or not?

  • If both a canonical and aliased parameter are present, or two aliased parameters
    • Let's say this is ambiguous, and we're okay with losing one of the two values after saving with Visual Editor.

In the old sidebar view parameters without a value are displayed in grey (see bottom "fooalias" in the screenshot). Do we want to keep this behaviour in the current version as well or leave as is (see "fooalias" in the green area)?

Screenshot from 2021-07-15 15-16-48.png (510×696 px, 42 KB)

ECohen_WMDE claimed this task.
ECohen_WMDE updated the task description. (Show Details)

Closing this epic as the stuff covered by this ticket is done