* The template model fires an "add" event. Listeners don't
automatically steal the focus any more.
* Instead there is a separate "focusTemplateParameterById" event
fired from all relevant places that add a parameter.
* The "remove" doesn't steal the focus any more.
Bug: T285323
Change-Id: I93f17727524bfbcf6f11647a6c2441781337c4cc
The original idea was to make the interface as narrow as
possible. However, it turns out it's better to model the
"templateParameterClick" event more closely after the "choose"
event.
This is split off to make reviewing the following patches
easier.
Change-Id: I271f576c6cd756cecfc6cb1fd64810f8da5c3575
This is split from patch Iebb982e to make it easier to review.
The name is rather ambiguous. Does "input" refer to the input
element? Is it triggered for every key press, i.e. when the
input changes? Or when it's submitted?
Change-Id: Iddbe3bfb9faf3561d8d71b96ffae507799827a95
Any of these characters results in bad wikitext, when we accept
it in a template parameter name.
Instead of displaying an error message we simply block the
button, as long as the input is not a valid parameter name.
Coming up with a message is not really worth it, I would
argue. Users typically don't have a reason to use any of these
characters. This is super rare. And even if, the behavior of
the widget is not hard to understand, I believe.
The same is done in ve.ui.MWParameterSearchWidget, a little
hidden in the .addResults() method.
Not yet approved by UX. Can be done in demo time.
Bug: T285869
Change-Id: I5576cdfb90411e5fdec93749f72939d31ecd9c56
* New help text for the case where TemplateData is present, whether
or not it includes a description.
* Remove help text when TemplateData is missing.
Bug: T288465
Change-Id: I0668ccae8eeb5ffffc626e3b7d24c1d7ed99bbed
- Change description text according to ticket
- Make sure link to template page opens in new tab
- Add missing placeholder text
Bug: T272487
Change-Id: Ie8189e9cb9db5908e8fc5fc8bf7ff20df5595094
When I press the button to expand the input field for
undocumented parameters, it needs to be focused. Otherwise I
have to click it manually all the time.
We probably forgot to list this as an acceptance criteria when
working on Ic5dcd36.
This also replaced a bit of JavaScript with CSS. I do this
mainly because I found the mixture before (one piece was
hidden via JavaScript, another via CSS) a bit confusing.
Bug: T272487
Change-Id: I0cbee63c65a37f2f1860bde007c1e5c8408ba006
This is mostly, if not exclusively visual, at the moment. The
actual state is still managed by the old sidebar.
I made the element OptionWidgets for convenience. This gives us
all the functionality we need (primarily setSelected and
isSelected), without to much clutter. However, I didn't made
the container a SelectWidget. This comes with to much stuff we
don't need at this level, e.g. cursor key navigation.
Bug: T285323
Bug: T289043
Change-Id: I20dbd2ba23ceaa9125947b25e037c0bb3c91a471
There are 2 situations:
1. Either the template name is used in a [[…]] link. In this case
we must provide the namespace. MWTemplateModel.getTitle() does
this. However, it's not a mw.Title object and therefor not really
guaranteed to be a valid title. This is fine. The worst thing
that can happen is that the link points to an error message.
But this should be entirely unreachable anyway.
2. Some messages want to display the name of the template.
Ideally without the namespace. That's what
MWTemplateSpecModel.getLabel() is for. Again this is not
guaranteed to be a valid mw.Title. But it doesn't need to. It's
only used as a label.
Change-Id: I03d0481201620a2f5c444ee32b656bcaade98aac
We should only need that label for the link. The other mechanic
would fail when editing wikitext like this:
{{{{echo|<}}|param=foo}}
Bug: T272487
Change-Id: If8d228b40bf1589181e83e8f68f3c33b4c7759c7
What this changes:
* The moment the user selects anything in the parameter search
widget, the input is cleared, no matter what happens next.
Even in case of an error. We know the input was bad in this
case. Let's get rid of it.
* The method makes sure it does not even try to add a
duplicate parameter. This should be unreachable, but better
be safe than sorry.
This is split from I5eeb973. I run into this while playing
around with different approaches related to hiding deprecated
parameters. Typically there should be no way the parameter
search widget offers a duplicate. Still I believe it's a good
idea to have this extra safety-net.
Bug: T272487
Bug: T288827
Change-Id: I04e76d73b4a3f6467d0ccf3ccff5d2f6b4114bd9
This removes the paramter placeholder page from all places where it's
not usefull anymore under the new sidebar.
The new UI will be re-added in follow up patches.
Bug: T272487
Change-Id: Ifc6f6f64fed1a1b23c92282e2a1bb40a7d401d72
I found this while working on T274551, which is all about the
definition of "empty".
In the old sidebar a parameter's name is dimmed (gray) as long as
the parameter's value is empty. This stops working entirely when
there is a default value.
My first impulse was "this is a bug". When there is a default
value, both the empty string and the default value (when the user
enters it exactly) typically trigger the same behavior: The
template uses the default value, just as if the user entered it.
But this code is correct because of the way it is used. Only
parameters that are "truly" empty should be visually marked as
such. The moment there is a default value it is either impossible
to change this back to an empty string – meaning the parameter
can never be truly empty – or the empty string is meaningful user
input.
Bug: T274551
Change-Id: I90657bfe83e56afd3942428c0dd8a47b444e39c9
Reasoning:
* format=json must be the default. Nothing else makes sense in
the context of this code. This should not be a surprise.
* formatversion=2 is only a default when the custom
getContentApi() is used, but not when mw.Api is used. One
might argue that it's safer to always specify formatversion=2.
However, this is not done in other places in this codebase.
It should never be done or always.
* I find it confusing when the action=… is missing. Let's not
rely on this default.
Change-Id: I6ca29f76bffc0849103c5bcff4aaf28fcaaa4c52
Some details:
* The config is not optional in these cases.
* This patch continues to remove some comments that don't add
any information but just repeat what the code already says.
Change-Id: I5c27cd01ad80709bb583256821d65c6b65b74b05
These methods are special in so far that they create *minimal*
wikitext where optional whitespace is not preserved. I tried
to rename the methods to reflect this, but could not find a
caller. What's used instead are the .serialize() methods.
Bug: T284895
Change-Id: Iedaa5b7efa9675151cc0553854d8aef3f9a46cbb
This reverts commit 950a5300dc.
Reason for revert: This broke several workflows. The reason is
that MWParameterPlaceholderPage & MWParameterSearchWidget both
hold references to the MWTemplateModel. This model is not
always the same. The dialog might be the same when a template
is edited multiple times. But the model might be a new one.
From this point on the MWParameterSearchWidget pulls data from
an outdated model.
Bug: T284636
Bug: T285571
Change-Id: I7b9ea8cab8f17705ec8020f07e3732da6ba0e73c
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 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
