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
Separation of concerns:
* The template model knows which parameters are currently used,
but doesn't know what's documented.
* The spec knows what's documented, but doesn't know what's
currently used.
Change-Id: I97cac00d6775a17a07059d0e8a7a116adc6080b3
There are some methods that behave different when a parameter
placeholder (where the parameter name is "") is present. Some
skip placeholders, some don't. This is critical to cover
before we make further changes to this class.
What I also do in this patch:
* Use shorter variable names to make the code easier to read.
* Don't reuse the `transclusionData` variable but use a copy
of the expected value. This makes the assertions much
easier to understand.
* Bring every test in the same "setup" → "execute" → "assert"
order.
Change-Id: I41a691c56bc509b132dc719ff820ae1ade4ccc3a
For example, checking if a parameter is required works just fine
for unknown parameters. They are never required. Since I16708b0
we don't need to guard the spec related methods any more.
Change-Id: Id90e4cb810dc9faca3b26f122a534f276ee31709
It's good practice to make transparent elements transparent
for mouse clicks as well, i.e. make it possible to select text
behind the fade effect.
Bug: T283943
Bug: T286235
Change-Id: Ib5022a74c70e4b7cb5e2a0faad20bd9abcc0da36
Introduced in 2 separate patches by the same author. This
patch removes the line that was introduced last.
Change-Id: I77575f7afe0f9276c7b54ee44d828e7ccb87c978
Before the method fetchRequestAlways() was doing two entirely
different things. Note how the two function arguments are
split now. Each method uses only one of them.
Change-Id: I592a1f29fd9c677a0ff18115cccda36950172001
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
A lot of the checks are redundant. The first check still is
redundant because the later two cover everything as well. But
I left it for performance reasons.
Additionally:
* There was no test for the method.
* This patch also updates a few pieces of documentation in the
same class.
Change-Id: I10f2944a844cc070bdc08dec6719929b383e34fa
If a known parameter is present using one of it's aliases, then
only the aliased name should be shown to the user. This patch,
therefore, resolves the issue of the same parameter being added
to the sidebar twice.
When adding a parameter that is aliased, it will receive the same
position as the non-aliased parameter it is replacing.
Bug: T274545
Change-Id: If4e58c941fd0f0e690d3603935f5a5d3f9938163
This also removes a few lines of text that don't explain
anything that would not be obvious from the code or @return
tag anyway.
Change-Id: I2f8f02dd61c50d9990d72c0e8ea79d679c9b11f2
It's allowed in values, but not in parameter names. The moment
a parameter name contains an `=` the parameter name will be cut
off at this point, and what's behind the `=` will become part
of the value.
You can test this on any live wiki. Open VisualEditor. Edit any
template. Add a parameter with a name like `a=` and some value.
Switch to wikitext mode and back. Edit the template. The `=` is
now part of the value.
Bug: T98065
Change-Id: I5e00e8fac987471243605816b041d3638927ac3b
This fixes a minor issue in the spec class. In the first step,
parameters from the template are added to the list of known
parameters. Later, aliases are resolved. The original behavior
was that such a parameter moved to the end of the list. This
is rather unexpected.
This dosn't have much of an impact. The pretty much only place
where the parameter order from the spec can be seen is in the
parameter search widget. Still I believe it's worth fixing.
Bug: T285483
Change-Id: I455818451811e92bba3e9320c2d41e1db8d563f2
I don't want this code to crash when the TemplateData API
returns an unexpected result.
Bug: T285483
Change-Id: I237cbfbb85892a53a08d9e7e34cf4974775d627a
This is just not necessary. It removes a level of indirection
that possibly makes it harder to understand the code. It makes
it easier to possibly get rid of unused methods.
Change-Id: Iaf8b213a5e1ae64a24b5bcdf2a0b200d5d3cbf46
This doesn't "extend". It was never used like this. What it
actually does is to link between a (cached) TemplateData blob
and the spec class that want's to use it.
Is this the best possible name?
* fillFromTemplateData( … )?
* propagateTemplateDocumentation( … )?
* readDocumentationFrom( templateData )?
* …?
Do we want to rename the "spec" class as well?
* MWTemplateDocumentation?
* MWTemplateMetadata?
* MWTemplateDataAccessor?
* …?
Bug: T285483
Change-Id: I6c52ef42d411c2f47fc0080768d36ebda4dd2a55
Just store the JSON blob from the TemplateData API as is.
This comes with a bunch of nice consequences:
* Less code.
* Less class properties that don't do anything but copy what's
in the TemplateData blob.
* Easier to understand what's going on. The `this.templateData`
property is now a reference to the *actual* TemplateData
documentation.
* No need to cache the documentedParamOrder. Just do it when
needed.
This also removes an unused feature from the `extend()` method
that didn't made sense anyway. Before it was possible to merge
conflicting documentations. But this is not only unused, it's
impossible to have multiple documentations for the same
template.
The method acts as a straight setter now. The next patch will
rename it accordingly.
Bug: T285483
Change-Id: I3ffc202577e9a20fc7491234601ccd981113f866
Instead of faking entries in this.params, let's use a separate
tiny data structure to keep track of parameters we have seen so
far, and in which order.
This finally allows to easily distinguish between documented and
undocumented parameters.
Bug: T285483
Change-Id: Idf62b0661178a3bbef7e817edf016dbd572d415b
When what you type is a partial match, you can't add it as an
unknown parameter, even if that would be the correct action. The
reason for this unexpected edge-case is a mistake in the code
where a variable called "exactMatch" is set when a *partial*
"nameMatch" was found.
Bug: T285940
Change-Id: I6d12e2d7251a19d7d5f8be544c3c32a3ac14fcf0
The so called "spec" class keeps track of parameters that have
been used before, no matter if documented via TemplateData or
not. Removed parameters are still "known" (i.e. have been seen
before).
This feature allows to easily find previously used parameters
names when an undocumented parameter was removed and the user
tries to add it again.
Bug: T285483
Change-Id: Ia1555eea87cd99e7a3f386f4279ec5a80fb98a79
