This reverts the revert commit d47b95eb4a.
When no `paramOrder` is given, known parameters should appear in the
order returned from the TemplateData API.
Previously, when TemplateData was present but no paramOrder
specified, then the parameters would appear in alphabetical order as
"unknown" parameters. Now they will appear in the order listed in
TemplateData. This is similar to the fully-specified behavior when
paramOrder is present.
This will only affect the Visual Editor template dialog, and has no
effect on serialization.
Bug: T274545
Change-Id: If8315781572af688ea1c1b14b3694b828f076b4a
The results show that parameter order always follows the appearance
in the template invocation, regardless of `paramOrder`, whether the
parameters are aliased, or whether there are unknown params.
Bug: T285382
Change-Id: I76c6fe8f0a2482cf0856bbafd9f21ba9fc4919a4
This makes the code more readable and easier to reason about.
The ESLint rule responsible for this code style was removed
just recently.
Notes:
* I focus on classes that are relevant for what the WMDE team
does right now.
* I merge multiple `var` keywords only when the variables are
strongly connected.
* Caching the length in a for loop makes the code hard to
read, but not really faster when it's a trivial property
access anyway.
Bug: T284895
Change-Id: I621fed61d894a83dc95f58129bbe679d82b0f5f5
This reverts parts of I678bb24.
Brief history of this code:
2014: The dialog was designed to dynamically change the title.
There was never a tooltip.
2016: A change in OOjs changed the behavior in VE. Now the initial
title shows up as a tooltip. It never updates because VE
does not know about this. The tooltip does not match the
visible title.
2021: We revert to the behavior from 2014. We achieve this by
bypassing the codepath that creates the tooltip. This is why
….title.setLabel() is used instead of ….static.title.
Bug: T276568
Change-Id: I346a904881c3a63186d6a80afdaf717688bab42a
When no `paramOrder` is given, known parameters should appear in the
order returned from the TemplateData API.
Previously, when TemplateData was present but no paramOrder
specified, then the parameters would appear in alphabetical order as
"unknown" parameters. Now they will appear in the order listed in
TemplateData. This is similar to the fully-specified behavior when
paramOrder is present.
This will only affect the Visual Editor template dialog.
Bug: T274545
Change-Id: I32538de07641c288081042a41fe39eedfed7d939
Note that the tests expose a bug, getAllParametersOrdered fails to
list an unused parameter. Fixed in I32538de07641c.
Also, a minor fix to avoid an impossible template spec: paramOrder
must include all parameters.
Bug: T274545
Change-Id: Icfa7a765773d04ef05a76ecc09467305e311f6cb
The tooltip is useful for languages where the dialog title might get
truncated. This patch makes sure the tooltip is always the same as
the visible label.
Bug: T276568
Change-Id: I678bb243bb5ac6d1c516ee4e146f2db9ffd5afcf
This will avoid that the search breaks in edge cases where symbols
are used.
Including a fallback for ES5 browsers. The fallback should cover
almost all cases. Worst case would be not adding the asterisk even
though it might be valid.
Bug: T284554
Change-Id: Ie4aee0b77492b7a73bc251a8723a206dbd641600
We have to move the activation logic from a ve.ui.Command to the
ve.ui.Tool, as the Command is unable to refer to the Target.
Previous attempt: 4984c5ffbb
reverted in fb32aa4978.
Bug: T279313
Change-Id: I3cb74aa5123b67a6c63b8e07ea7f93a6d4a07d4f
This not really just a checkbox widget anymore it inherits from
FieldLayout and became something more in that direction.
Let's use a mixture of these things to make it a bit clearer.
See also comment in Ie81b84be288553343017c4aaf8691c4e266995f5
Change-Id: Iff1746a8e5e94b56eb6c27465405aaf6b74c2310
New changes:
5e3ee8ae9 Help dialog: Hide commands which are not in surface.getCommands()
6c7bee041 CommandHelpDialog: Rewrite for-loops
Bug: T284758
Change-Id: I408132ae6b858cf6efd81f67d3a7a3123d384c59
There are at least 3 different methods that are all named
getWikitext, not counting subclasses. They behave rather
different, most notably in terms of whitespace preservation.
Bug: T284895
Change-Id: I8b47f5bd21675a431ba2bc2d4a8cb0c55dd50f76
Most notably:
* Introduce variable names that explain much better what's
going on.
* Reduce nesting.
Bug: T284895
Change-Id: I793677d8107abb6354f9e19d79c4879a41c4bd93
This action was removed via Ib744b89 in 2019, see
https://gerrit.wikimedia.org/r/c/mediawiki/extensions/VisualEditor/+/491537/4/modules/ve-mw/ui/dialogs/ve.ui.MWTemplateDialog.js
Note the messages that are removed in this patch:
* …-action-insert was used for the "insert" action.
* …-action-apply was used for an "apply" action.
* …-action-cancel doesn't mention an action. Internally,
the cancel action is "".
Since Ibd740ad the actions are registered in the
FragmentDialog superclass, see
https://gerrit.wikimedia.org/r/c/VisualEditor/VisualEditor/+/491536/2/src/ui/dialogs/ve.ui.FragmentDialog.js
Note the messages. Cancel is unchanged. …-action-insert and
…-action-apply are still there, but both linked to the same
"done" action. The "apply" and "insert" actions are gone.
I.e. they are merged into a single "done" action, represented
by a single button that changes the label from "Insert" to
"Apply changes" when needed.
On top of that,
MWTransclusionDialog.updateActionSet() replaces "Apply
changes" with "Save".
Note: Other dialogs also mention an "insert" action. I didn't
look at these. These are not in the focus of our team's
current project.
Bug: T284895
Change-Id: I1d35ada3b5b2049ed20c2d940a1c065b704c978d
Splits out a useful intermediate calculation from getOrderedParameterNames,
exposing the full list of parameters including those that are not
present in the transclusion.
This will be used to build the sidebar checkbox list.
Bug: T274545
Change-Id: I1c6a9ea8a5e9a163751fee87f974f63c72fd1f61
The "mode" button is the button that allows to expand and
collapse the dialog. It can't be collapsed when multiple
templates are edited. That's what these lines do,
disabling the button.
"Can expand" is not the correct question. It's always
possible to expand the dialog no matter what it contains.
Bug: T284895
Change-Id: I60f3060695c80bf5541ef2156be89b85a62bf91b
