This was done in 3 rather "random" places:
1. Whenever a template is manually added. But rather late, after the
template was added, in an event handler that is about focus
behavior. It should not continue to manipulate the template that
was just added.
2. When the dialog opens with a template preloaded by name, as it is
done from the citation menu.
3. When the dialog is about to finish loading.
This patch fixes 2 issues:
* Get rid of a duplicate call (number 2 and 3) when using the
citation menu.
* Move number 1 to a place where it's executed much earlier, and
only when the user clicks "add template" in a template placeholder.
There is no other way to add a template to an existing transclusion,
but it's still a more appropriate place I feel.
Bug: T311069
Change-Id: I8a65ad703b95ba2092e9ef73493e9903e96b0dd6
Such comments don't add any new information. The method signature
alone already tells the full story.
We did this already to a lot of the template related code we touched.
This is just a bit of cleanup to make it consistent.
Change-Id: I932b620910924a16dc0d31d6c8a3ab11818316fe
The numeric part of these ids is never used on it's own. There is no
need to expose it.
Note we renamed the method not long ago in I6eeab8b to reflect better
what it does. This is the next step. We just forgot it back then.
Change-Id: I5da82855e99ea3a42a5d91379c6974ae9c154518
Same random finds while working on something else. I carefully
checked and made sure these methods are actually called without the
optional parameter.
Change-Id: Iab36fd130258322985b5d6e7f8e1f7b4ee235ba2
It's not a getter, but a generator. I found the name confusing.
Getters typically don't return something different every time you
call them.
Change-Id: I6eeab8b6a8644e430003f6e1ad77ab4b28e0d8c9
This is a more radical change, compared to the previous patch.
I will post more detailled explanations as comments on Gerrit.
Change-Id: I6909b3f0b2c153b7ee9995441e995ffa793eab40
Some cleanup to improve readability and reduce the amount of code.
Relevant bits:
* One method name was wrong. It can actually return parameter ids,
not only top-level part ids.
* I got rid of some fail-safe checks that are never needed or moved
them to a more central place.
Change-Id: I08f2ad7bc7d3f985d6189dff170dda554f3d37c2
I moved some code around and found that quite a lot of code wants to
know:
* Is the length of this transclusion exactly 1?
* I need that 1st part.
There is more that can potentially moved from the dialog to the model.
But I don't want to make this patch to big.
Bug: T292371
Change-Id: Ia94ed0450d04dd97c4c41f5bf7c266f9a534e821
The TemplateData extension is not limited to the Template: namespace.
And even if pages outside of the Template: namespace typically don't
have TemplateData information, the API is still able to automatically
extract parameter information from every page.
Or:
It's rare that a page outside of the Template: namespace is used as
a template. But if it is, this is not a mistake. The code here in
VisualEditor should not try to be "more clever" than the user is. If
this is what the user want's to do, let's not block them.
Bug: T291883
Change-Id: Iaf3fd5530b74fab7cedfc85ce04c8c40632df11f
The previous patch Id314ee8 was incomplete. The event changed.
The id in the event is not guaranteed to be a top-level partId any
more, but can be a template parameter's id.
Note: "Parameter id" and "pageName" is the same. The fact that
these ids match is how the left and the right side of the dialog
communicate.
Bug: T289043
Bug: T291151
Change-Id: I391f0f8edb96398fd33a2e0b01003013c52776da
Method names have been changed in I8fa47ed, assuming these are
private. It looks like some hacks exist out there. Let's make
these peoples life easier.
Change-Id: I63c80761fe06e2f3a4bb104fe3e8c17d1c7faa02
It appears like it's currently not possible to reach this code
with an invalid template name like `{{foo}}`. But this is not
guaranteed.
The purpose of this code is to call the TemplateData API. This is
pointless when a title is invalid. We know a page with this name
can't exist. So we skip it.
But that's all this code cares about. It should not crash. Nor
does it need to report this situation.
This is related to the discussion in Ic364e75.
Change-Id: If9bacc91b1c7bb110b33bfd395e1cbdf538e6c22
Names like "fetch" or "resolve" are heavily ambiguous and
continue to confuse me. I hope these new names reflect better
what's going on.
Bug: T288827
Depends-On: I587a203a9370e4742f87586b4f1867b37459c375
Change-Id: I8fa47ed313e7d7b2c114a5638a67c4f3c8b830f1
Notably:
* Don't require the model in the new sidebar via dependency
injection, but connect the event handlers later. This is
relevant because we currently create the new sidebar in the
wrong spot. Removing the hard dependency allows us to split
the code and utilize initialize() and getSetupProcess()
correctly. This will be done in a following patch.
* The change event now includes the new position. This makes
it very easy to add this missing feature to the new sidebar.
Also:
* Stop triggering change events when nothing changed. These
events are expensive. They bubble all the way up to the
TransclusionModel, and to all linked
onTransclusionModelChange() handlers.
* Update event documentation to make this more visible.
Bug: T274544
Change-Id: Iafe29f18a6fed14d9c3124c9756aa840886afbbc
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
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
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
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
This property is a reference to a static variable with the
same name, initialized at the very top of the file. All
instances of the class use the same cache. They all use the
shared specCache directly, not the reference.
Depends-On: I0084410b7eab29048451ad67c18d6c2180c4f1b1
Change-Id: I9fd79ce3abd533dbb48a210e596802ea9e692855
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
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
There are 2 methods with the same name, but they are very
different. This makes it much easier to understand the
difference, I hope.
Change-Id: Ie1f049b2b14e1fe23f078e281ee797da29dfe3db
The idea is to possibly rename some of these classes, based on
these descriptions. But this should be done in later, separate
patches.
Change-Id: I7f9e5b2382711b434d6dd618489fa3ed8b7a46b4
This parameter name was deprecated and replaced in 1.31. See also
Ie5fe2097cda45968bb080643d3afcac0b2868a6c
Change-Id: Ie9d6c70d3dfe3954504d3d698c122dceede7603d
When a template does not have user-provided TemplateData documentation,
the TemplateData API falls back to extracting possible parameters from the raw wikitext
to generate an API response with a list of potential parameters. However, it also
sets the "notemplatedata" field in the response, causing the VisualEditor to think
the response contains no useful information and ignore it. This appears to have been
an unintended side-effect of I97a1bfc9f9ead082a673a91b9d2053630a90309c.
This patch ensures that the VisualEditor will correctly consider such responses from
TemplateData by modifying ve.dm.MWTransclusionModel to check if the response contains
a parameter map. Some unit tests were added for the class to verify this behavior.
Bug: T243868
Change-Id: I72005880d9301a53224473900efe2917379e8708
