The idea is to not actually store all these default values, but
fall back to the default only when needed.
Some more details:
* The only remaining property is ….name. The only reason to
have this property is to distinguish between aliases and
primary parameter names. This will be reworked in a later
patch.
* The description falls back to null because this is the
documented fallback, not undefined.
* The default value falls back to "", same as the auto-value.
Why not null you might ask. This is intentional. Both the
auto- and default value are effectively wikitext snippets,
while the example is a label in the VE UI.
Bug: T285483
Change-Id: I1be3cca18f9ad6fc1c16362b24633f7613f02539
This is done for two reasons:
1. It fixes the behavior of two methods in rare edge-case
situations. They aren't documented to return undefined.
2. It reduces the amount of stuff this class stores when it's
nothing but a default value anyway. Note this patch does this
for the template-level properties only. Another patch will do
the same for the parameter-level properties.
Bug: T285483
Change-Id: If2e4d56da1fa52e32dc94191f36d7dc6a1487829
This reflects much better how this method is meant to behave.
Note I will continue to remove documentation that doesn't
explain anything in addition to what the code already says.
Bug: T285483
Change-Id: I81fa8a5d9d0752f3aeac4015c9a27b50e054d4df
This patch also marks 2 methods as @private that are not and
should not be used outside of this class.
Bug: T285483
Change-Id: I8a8ffc4868a369b5c47068beb0e83f023872543d
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
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
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
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
Most notably:
* Introduce variable names that explain much better what's
going on.
* Reduce nesting.
Bug: T284895
Change-Id: I793677d8107abb6354f9e19d79c4879a41c4bd93
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
Introduces new widgets forming the backbone of the experimental
template dialog sidebar.
FIXME: `text-overflow: ellipsis` is not working yet, the container
styles need adjustment.
Bug: T274543
Change-Id: Ie81b84be288553343017c4aaf8691c4e266995f5
Both the template description as well as the parameter
description (including default value and examples) typically
contain longer texts. These can contain longer words that
"explode" the design. This is trivial to avoid.
Note this is not meant to fix this issue in all places where
it can appear. For example, a long parameter name causes the
same issue. But:
* Technically, it's not that easy to fix.
* Even if, it's not obvious how to fix it. Cut off the
container? Add ellipsis? Or wrap? How should the
surounding stuff float then?
This is all left out because of this. Focus on what's
obvious.
Bug: T284890
Change-Id: Id6700af168f5ab5ddde97d3f5ae63829b65a3be5
* Re-focus the input field after closing the message.
* Store only the message key. That's all that's needed.
* Avoid a class property that's not needed.
* Use the config object instead of calling .setLabel() manually.
Bug: T284742
Change-Id: If8e8bb6460fa5aea8ddd46c2e27b5f08b7772896
