OO.ui.ActionFieldLayout requires 3 parameters: 2 widgets and optional
configuration. But this code was passing only 1 widget. The config
object was actually used as a widget and never as config. It's a
miracle this was not throwing an error. ;-)
Replace with a more trivial FieldLayout which requires only 1 widget.
Also clean up some closely related code.
Change-Id: Idca9a39e9f442f3a5412027906de9f868fc12b76
This fixes a whole sequence of issues:
* It was actually possible to add a parameter with no name.
* It was also possible to add parameters where the name is nothing
but whitespace.
* Pressing enter was not possible.
* The button was initially enabled with the input field being empty.
* Validation code was duplicated, but incomplete, which made it
possible to add duplicate parameters with enter.
Bug: T324381
Change-Id: I598997efc63256fd59a2b4f71fb7c3d99306bd85
This placeholder was added in Ic8f9bf7. It makes sure the page
content below the button doesn't shift down the moment the button
appears. See T279869 for a screencast that demonstrates the issue.
Unfortunately something changed (possibly related to T323773) and
the size of the placeholder is not correct any more. At the moment
the page shifts up a few pixels.
Bug: T279869
Change-Id: Ie6e585d2061342c11aabb4414bb9b0bedecf3a12
Note the code style in this file is already a mixture of some early
declarations and others that happen in place. We mostly prefer the
later nowadays because it makes the code much more readable. Some of
the code touched in this patch was really a little confusing, I would
argue.
Change-Id: Ib2777c6f6c86876c016e50d7bd2fe3d82c611914
A change in OOUI made .addItems() silently ignore non-array input.
The most robust fix is to make all callers follow the documentation
instead of relying on undocumented behavior.
The change to onMapItemRemove is not strictly needed but done to make
this piece of code much more robust.
Change-Id: I95f9a058766720d3809c3e56309326c2a91f2bcd
Main change is that we don't map between strings and object
references any more but use the object references directly.
Change-Id: Iecc011f62089d902bb5cbd9ff3b4189d3258a2b4
The data structure at the top of Model.js uses types like "string",
"array" and so on. Fields that share a type behave identical. I find
it odd to repeat parts of this data structure in the code. That's
what the types are for.
Change-Id: Iae55c18ececb809a56e40d3179d2cde357309d0a
… by turning the nested `if` around and simplifying the remaining
parts a little. This patch is intentionally minimized. More
meaningful changes will be done in the next patch.
Change-Id: I56cfa5c8ac8ca29acd42bd71786f5433e884e1b2
Previously, our eslint configuration required all variables
to be declared together at the top of the scope, but that
was changed, and declaring the variables where they are needed
is clearer.
Change-Id: I87e74ceadd5374a6ba6b7a4f8f49dca03a5c4bca
The data structure in Model.js, starting at line #125, does have a
"type" property that's supposed to do this. What kind of input element
we need depends on the type. Repeating individual element names here
means we are duplicating parts of the data structure.
The mapping is unambiguous, i.e. the new code is guaranteed to do the
same as before.
This is a tiny cleanup patch in preparation for later changes.
Change-Id: I162dcd6f9a31f5ab2c6eb7027befd4736de40ca5
"children" is an array. See line #148 in Model.js. What's called "type"
here is just the numeric index in this array.
Change-Id: I73c190f754d113ac90f5df76fb8cc8b7a75fc927
This button, similar to an edit-section link, will launch the editor
and immediately open the TemplateDataGenerator UI.
Bug: T316759
Depends-On: Idb5e3c51a22361e0d9916d3c31444daeff310ed2
Change-Id: Ieb575c499c16d87c28972a55662ef0bd9cb72c06
* This is most notably when adding a new parameter. The cursor should
start in the input field.
* Focus the first input field when editing a parameter, whatever that
input field is.
* Focus the big JSON editor when editing a map.
Change-Id: I5a3df626810007e83bd2300b540df75bc1b8cac4
There is sometimes a good reason to arrange code like this, especially
when the additional variable name acts as documentation and helps
explaining what's going on. I think this is not the case here.
Change-Id: I46f4a18a4f78f4b03cf063a226de3f43ba13b1a2
The short `|| defaultValue` pattern is very common in JavaScript.
Note that in JavaScript – in contrast to PHP – empty arrays and
objects are not considered "falsy".
Change-Id: I97935c4dc2276d48d53ade3f7b4fdc28b62d89ba
This was always comparing with the English description. The effect of
this was that the comparison was always false and the value always
set, even if it didn't change, resulting in unnecessary events being
fired. So this is only about performance but not really user facing.
Change-Id: Id7a46dbac81e2595478848bbf325eece21815bec
This patch includes two bugfixes:
1. The previous rule with a `p + p` didn't do what it was supposed to
do. It was adding a margin after the 2nd, 3rd and all following <p>
elements, but not between the 1st and the 2nd. It should have been
margin-top instead. The approach in this patch is different and
avoids the need to repead the 0.5em.
2. The red background color was not applied to the input fields any
more because OOUI doesn't use <input> elements any more.
Change-Id: Ia57b742e8b3cd29c1f55cd7e918f26f70eebab18
Some time ago there was a little bit of custom CSS applied to the HTML
table rendering. This is broken since patch I74214ea from 2016. This
patch renamed all CSS classes but forgot to update the PHP code
accordingly.
I decided to not change the HTML rendering because these class names
might already be used in custom per-wiki or per-user CSS. Instead I
partly revert I74214ea.
Unfortunately, some of the styles are quite dramatic, don't look good
or just don't work. I decided to remove some. The argument is that
the HTML rendering looks the same for 6 years now. I don't see a good
reason to change it now.
In detail:
* Suggested values are not aliases and should not be rendered in
gray.
* The message "no description" is rendered in gray and italics. But
this was applied to the wrong DOM element and made everything else
gray and italic as well.
* The color #777 is not readable, violating WCAG rules. While it's ok
to dim aliases and such, it must be at least #555 or darker.
* The "nowrap" destroys the table the moment one of the parameters
does have a longer name or alias. Let the browser handle this, as
it did for 6 years now.
* Same for rendering aliases as individual, indented blocks. This
makes the table unnecessarily big when there are many aliases, and
just doesn't look right. Again, let's stick to what we had for
6 years.
Change-Id: Idfa76eed6e2d68474c79d4674efce091cb031b66
It's required via the spec. We should act as if it's always there,
even when the actual "original data object" doesn't contain it.
Bug: T307331
Change-Id: I129b0c77e701df6ebbdc39432360cea8f10575e8
<pre> behaves very similar to <nowiki> in so far that whatever it
contains doesn't get parsed as wikitext. It might contain {{{…}}}
tripple brackets, but these aren't going to be activated as template
parameters.
Bug: T91326
Change-Id: I05c24e369d97c48161c565e2ef30969ec28c6a23
This method is not used anywhere else:
https://codesearch.wmcloud.org/search/?q=getRawParams
I tried to make the code a bit more readable. Notable:
* Make use of the return value we get from the preg_… function.
* {{3,} means "the character '{' 3 or more times". {{{+ does the
same. Note the { doesn't need to be escaped when it's not
followed by a number.
* At the end, it doesn't make any difference when we scan for
optional closing brackets. The moment we find at least 3 we are
done.
The test is intentionally not moved. This is something for a later
patch.
Bug: T301337
Change-Id: I55e31ceecea2ae7c35bcfbc2d641b35f751820db
Parameter names in a template can be numeric. While it makes a lot of
sense to force a specific format in the TemplateData JSON (i.e. only
strings), it's inconvenient and confusing if numbers are rejected for
being "invalid".
Effects of this patch:
* The incoming JSON is allowed to contain numbers in the aliases
array.
* However, the API normalizes these and forces all aliases to be
strings, as it was always documented.
* The editor component accepts anything in the aliases array, but
forces all aliases to be strings. Again, as documented.
* Note that it was never possible to use numeric keys in the `params`
list. This patch is only about aliases.
At the moment this is a somewhat "hidden" feature. We might or might
not update the documentation to officially allow numeric aliases.
Bug: T298795
Change-Id: I32ea296b4520e7f21b03a1f6390db4f43b613bdd
