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
This merges all code-paths that re-select a part (i.e. an input
widget on the right side of the template dialog).
Note there is an edge-case that actually changes with this
patch. When a page is removed, and creating a new page fails,
there is an `if ( page )` check. Before, the behavior was that
nothing gets selected in this case. After this change the
behavior is the same as if a page was removed: the closest one
gets selected. Not only does this make more sense. The `if` is
only a fail-safe anyway and should not result in different
behavior.
Bug: T288827
Change-Id: Ibb0260587588fb51a876658b16a81c5a73371dc4
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
* getPartId() is unused.
* Use this.data instead of a custom this.partId.
* No need to store this.header as a property.
* Rename the event to "headerClick". That's enough when the
event comes from a widget that does have the word "part" in
it's name.
Bug: T274544
Bug: T288827
Change-Id: I8c70425403c6cd6a19e3a1cacb2b085e5c8b2e46
The base widgets we are going to use (notably OO.ui.OptionWidget
and OO.ui.SelectWidget) also have events, and some of them use
the same names. Such conflicts are really hard to track down.
This is meant to be temporary. The goal is to use the events
from the base classes and get rid of the custom ones, if
possible.
Bug: T285323
Change-Id: I0f103a5bbb8fb800e57009e3bf709f00a651fdda
The problem here is that the OO.ui.OptionWidget base class
(changed in the previous patch) also contains a .setSelected()
method, but with slightly different behavior. This results
in crazy behavior when I try to make the outer widget an
OO.ui.SelectWidget.
Renaming the method to be a custom, private helper method
avoids this problem.
The plan is to actually use the default setSelected()
behavior and get rid of the helper method. This will be done
in later patches.
Bug: T285323
Change-Id: I84e752f20a4d07007fd4e61989f9b34983410950
As preparation to introduce then new UI to add unknown parameters.
This is a few things:
- Merge the code paths when adding a MWTemplateModel
- Put code adding parameters to the dialog next to each other so
that preventing reselection happens around that block
- Reduce duplicated code when re-focusing after addition
- Move adding the placeholder page to the end
- Add and clean up inline documentation
Bug: T272487
Change-Id: Ic700edd42027a928a236ed11f2c257fffe994257
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
The plan is to change the outer …TemplateWidget (which contains
a list of template parameter checkboxes) into a SelectWidget.
But this requires the elements in the list to be a subclass of
OptionWidget.
Note this change does not have any effect, as of this patch. But
this makes the following patches smaller and easier to follow.
Additionally:
* The OptionWidget class is already a LabelElement. No need to
initialize this twice. This happens via the parent constructor
now.
* Remove CSS that is not needed any more after Idc5e048. This is
not a FieldLayout any more.
* Update some related code documentation.
Bug: T285323
Change-Id: I92e8fd2bbece9e6c55083cdfe6ed7ad16a64d688
The icons have a padding of 6px around the icon image itself. To
get to the required 16px/8px space the margin was adjusted
accordingly. Note that there's also a 2px padding around the menu.
Bug: T272482
Change-Id: I3df9f355dfd5c4e6366432555b96bf788e784280
This is what actually happens:
* We call `addParameter()`.
* This triggers an `add` event.
* This calls an `MWTemplateDialog.onAddParameter` event handler.
* This code doesn't check if a parameter already exists (because
it shouldn't). It detroys the page in the content pane on the
right and recreates it from scratch.
The only reason we do this is to focus the input field on the
right. This patch introduces a dedicated event to do this.
Bug: T288827
Change-Id: I47effe05427cfabfcf534920edee79521eaa033f
The history.replaceState call in onReviewModeButtonSelectSelect() (1)
ignores any changes to the document URL made by external tools such as
RevisionSlider, (2) replaces with an empty string the history entry
state object if it was set by external tools such as, again,
RevisionSlider. Both 1 and 2 result in a wrong URL ending up in the
address bar at some point. This patch addresses these problems, (1)
creating a new mw.Uri() object every time
onReviewModeButtonSelectSelect() is called, (2) keeping the current
history.state object.
The original variable storing the URI object is renamed to avoid
shadowing (optionally can be replaced with its value as it's used only
once).
Bug: T288636
Change-Id: Ieb97b561a6c076aa28aae231fe286ac4d1051bbd
