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
The tooltip is useful for languages where the dialog title might get
truncated. This patch makes sure the tooltip is always the same as
the visible label.
Bug: T276568
Change-Id: I678bb243bb5ac6d1c516ee4e146f2db9ffd5afcf
This will avoid that the search breaks in edge cases where symbols
are used.
Including a fallback for ES5 browsers. The fallback should cover
almost all cases. Worst case would be not adding the asterisk even
though it might be valid.
Bug: T284554
Change-Id: Ie4aee0b77492b7a73bc251a8723a206dbd641600
This not really just a checkbox widget anymore it inherits from
FieldLayout and became something more in that direction.
Let's use a mixture of these things to make it a bit clearer.
See also comment in Ie81b84be288553343017c4aaf8691c4e266995f5
Change-Id: Iff1746a8e5e94b56eb6c27465405aaf6b74c2310
Most notably:
* Introduce variable names that explain much better what's
going on.
* Reduce nesting.
Bug: T284895
Change-Id: I793677d8107abb6354f9e19d79c4879a41c4bd93
This action was removed via Ib744b89 in 2019, see
https://gerrit.wikimedia.org/r/c/mediawiki/extensions/VisualEditor/+/491537/4/modules/ve-mw/ui/dialogs/ve.ui.MWTemplateDialog.js
Note the messages that are removed in this patch:
* …-action-insert was used for the "insert" action.
* …-action-apply was used for an "apply" action.
* …-action-cancel doesn't mention an action. Internally,
the cancel action is "".
Since Ibd740ad the actions are registered in the
FragmentDialog superclass, see
https://gerrit.wikimedia.org/r/c/VisualEditor/VisualEditor/+/491536/2/src/ui/dialogs/ve.ui.FragmentDialog.js
Note the messages. Cancel is unchanged. …-action-insert and
…-action-apply are still there, but both linked to the same
"done" action. The "apply" and "insert" actions are gone.
I.e. they are merged into a single "done" action, represented
by a single button that changes the label from "Insert" to
"Apply changes" when needed.
On top of that,
MWTransclusionDialog.updateActionSet() replaces "Apply
changes" with "Save".
Note: Other dialogs also mention an "insert" action. I didn't
look at these. These are not in the focus of our team's
current project.
Bug: T284895
Change-Id: I1d35ada3b5b2049ed20c2d940a1c065b704c978d
The "mode" button is the button that allows to expand and
collapse the dialog. It can't be collapsed when multiple
templates are edited. That's what these lines do,
disabling the button.
"Can expand" is not the correct question. It's always
possible to expand the dialog no matter what it contains.
Bug: T284895
Change-Id: I60f3060695c80bf5541ef2156be89b85a62bf91b
Introduces new widgets forming the backbone of the experimental
template dialog sidebar.
FIXME: `text-overflow: ellipsis` is not working yet, the container
styles need adjustment.
Bug: T274543
Change-Id: Ie81b84be288553343017c4aaf8691c4e266995f5
Both the template description as well as the parameter
description (including default value and examples) typically
contain longer texts. These can contain longer words that
"explode" the design. This is trivial to avoid.
Note this is not meant to fix this issue in all places where
it can appear. For example, a long parameter name causes the
same issue. But:
* Technically, it's not that easy to fix.
* Even if, it's not obvious how to fix it. Cut off the
container? Add ellipsis? Or wrap? How should the
surounding stuff float then?
This is all left out because of this. Focus on what's
obvious.
Bug: T284890
Change-Id: Id6700af168f5ab5ddde97d3f5ae63829b65a3be5
* Re-focus the input field after closing the message.
* Store only the message key. That's all that's needed.
* Avoid a class property that's not needed.
* Use the config object instead of calling .setLabel() manually.
Bug: T284742
Change-Id: If8e8bb6460fa5aea8ddd46c2e27b5f08b7772896
We can skip all the up and down message passing by persisting the
parameter placeholders for each template dialog. If the parameter
list is expanded then the placeholder is deleted, on being created
again it will still have state.
To test: create a transclusion with two templates, each having many
parameters. "Add more information" to add parameters, expand the
list by clicking "Show <num> more fields", then delete the parameter
placeholder using the trash cans. Try different permutations to fool
the cache or collide with another template.
This is preparation for other template sidebar dialog work.
Bug: T284636
Change-Id: I23bdd38b173114c2a9afafc7465c4beb92d25869
These don't add any knowledge but make the code harder to read
and maintain, and are an additional source of errors.
Change-Id: Ied57741a3f985e355adfddb4e75378d5c497faa9
Begin to extract the wiring between a sidebar and the content pane of
the template dialog booklet layout. Eventually, this helper class
will present a high-level interface like "addPart(id)" and will take
care of creating the outline item, content page, and connecting
events.
Start very simple, take over the "focus" method.
Bug: T284632
Change-Id: I7bc73cc4386b99d95941fc6ed88ab5bd998de014
This reflects better what the method actually does. This patch
is a direct follow-up for the renames started in Ib029fd4.
Change-Id: Ie3e87139a5c2f5ac196e0fcc02fb897fadc99177
The names of the messages keys are very confusing. The order was set
wrong during refactoring in Ib029fd48b393d2ab7d7cff6c842789e22989e944.
We should rename the keys in a follow up in sync with translatewiki.
Bug: T284649
Change-Id: I43794d80b7df7d00441cb583ca53bcab03999e65
This dramatically simplifies the "mode" flag in
MWTransclusionDialog. The main reason to touch this code is:
The flag appears like it will be "single" when the dialog
contains a single template, and "multiple" when there are
multiple templates. But this is not true.
What the flag really does is show/hide the sidebar. The sidebar
is needed to be able to create multi-part templates. But a
dialog that already contains multiple templates can be set to
"single" mode (i.e. the user can collapse the sidebar), and
vice versa.
This patch focuses on private details inside of this class, but
keeps the terminology of a "mode" in some places. E.g. the
messages are not renamed to not cause unnecessary trouble for
translators.
Change-Id: Ib029fd48b393d2ab7d7cff6c842789e22989e944
Previously, if the checkboxes were shown on multiple lines (e.g. due
to a FlaggedRevs checkbox), there would be uneven margin at the
bottom. There was a special case to fix this only for the watchlist
expiry not-checkbox.
Change-Id: I006049cf23e6d42519bfa15b7ec30ea1bc5d08ac
This class represents a raw wikitext snippet. There is also no
base class that would require us to follow a generic
getValue/setValue naming scheme.
Change-Id: I0891a2f6c0ae0121429a47c39221e99b9653e8e3
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
This does have a few advantages:
* Less code is executed and less memory consumed when these
elements are not needed.
* Code that belongs together is together.
* No local class properties are created when they are not
needed in the code below.
This patch is kind of a proof of concept. It touches only a few
classes we currently actively work with. If this change is fine
we can change some of the other classes the same way.
Change-Id: I9f548765034f1f69799fff41aeb6c147ff28b82d
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
The main motivation for this patch is actually the comment. The
so called "spec" contains all parameters that are present in a
template, no matter if they are present in the TemplateData
documentation or not. This is critical here.
Change-Id: I5e1c79e3859a27562a9dea1d450cec196aa572ed
Depends on whether this is a new or existing template transclusion.
Split from Ib9b76cac7cd57245e8db2ef10879069a86a6269e
Bug: T276568
Change-Id: I4d22e32fef067b640e9a9389deffaace736c3405
When the existing search results don't contain an exact match
(see previous patch), perform an additional search for the
title. This uses OpenSearch. This is recommended in multiple
places and also used in the quick search field at the top of
MediaWiki.
Again, I came to the conclusion that an isolated unit test
would be complicated and not test much anyway. Better test
on-wiki.
Bug: T274903
Change-Id: Ib575248e089ff66814400202d224deff6369c772
This code detects a few edge-cases:
1. When some search results are exact matches, make sure they
are always at the very top.
2. When the prefixsearch API is used, e.g. as a fallback,
redirects show up as a separate metadata structure outside of
the pages array. Consider these and stop if there is already
an exact match.
3. CirrusSearch returns redirects as part of the pages array.
When there is an exact match, make these redirects separate
options and add them to the top.
All of this is case-insensitive, on purpose. In case two
templates with different capitalization exist, we rely on
the backend to return both. The code introduced here is fine
with this.
Notes:
* This doesn't guarantee an exact match is always there. This
requires an additional HTTP request and is done in the next
patch.
* I tried to write unit tests for this, but gave up. The setup
is complicated. An isolated unit test would not test much
anyway. Better test this on-wiki.
Bug: T274903
Change-Id: I64e1b5633e7b878a4d0d23d66229ca87e69d0045
These are the most minimal (and therefor most stable,
hopefully) hacks I could come up with so far.
Bug: T274903
Change-Id: I28ba414dd34aad756e29400eb656f0942291a923
* Create getSurfaceClasses method.
* Pass surfaceClasses to target widgets.
This ensures that the 'content' class is passed to mobile
target widgets, and the 'mw-body-content' class is added
in a less hacky way.
Change-Id: Ibce6d1a1d0fda63cca354761f1b91f808858e95b
Template names sometimes show up twice when searching for a
template in the "Add a template" dialog.
This is a bit hard to test. The code responsible for this
is not in a single place. The feature is in the upstream
TitleWidget class. It's not broken. It makes sense to
provide e.g. "foo" and "Foo" as two separate options when
the user typed "foo", but the page is named "Foo". Both are
valid, and the feature allows the user to pick either.
But the VE widget does it's own normalization. Both entries
are normalized to "Foo". Both do the same. The additional
one is pointless.
You can try this on the actual enwiki: Open VE, insert a
template, search for "Template:nHLE".
Change-Id: I65e706c4d131a2f8c605d7979a02ea56f831bf03
The "redirects" part in a prefixsearch query is always an
array, no matter if formatversion 1 or 2 is used.
The "pages" part is an object with formatversion 1, and an
array with formatversion 2.
As of now this always uses formatversion 1. This is
hard-coded in the upstream TitleWidget class.
Change-Id: I8cde8e104f8a288015da745db41016f6639b453b
Returns true if there is no meaningful user input yet.
Will be used in the next patch.
Bug: T272355
Change-Id: I4f88ce31662bbc46755f78d574c46b907581d438
Rather than invent our own size, we'll reuse the "larger" format and
tweak the dialog height to 90%.
Bug: T273971
Change-Id: Ibef85c1912267b14d83396b089b81934751a8328
Discussed in T274903#7077957. Note this might not be the
"perfect" solution. We are still experimenting, and this is
all hidden behind a feature flag. This is the change with the
most minimal impact. Actively trimming the input is another
solution, but with a bigger impact we might want to discuss
first.
Bug: T274903
Change-Id: I2ed06c04bb96c7b61bd7e87ad001e639ea6d06a2
We have two cases now that we want to cover here:
- Either we're inserting a new template and start a "fresh"
transclusion, then we want to use "search" in the headlines
- Or we're adding a new template to an exsisting
transclusion, then we want to use "add" in the headlines
Bug: T277028
Change-Id: I9fa294cf732598d58f848c75b353d2e1742eb4e8
This allows using the config variable independendly from the cirrus search extension.
This way it can be used for all subtickets of T271802.
Bug: T277028
Change-Id: I1b3bdda5fa6fbfe5c531c3b51c2c8e2a28ed1faf
Renames "Add a template" to "Template Search" in most cases and
provides inline help for the workflow.
Bug: T277028
Change-Id: I3fee87cb89b5044e785596e71ef3f1a18f2694ce
We're about to replace this jQuery element by a OOUI container, and
can take an initial step by reducing its lexical scope.
Change-Id: I4123c8d22c01040fc2f61180304254498b21f5fd
The name "description" conflicts with the TemplateData field name,
which is only one of several documentation fields.
Change-Id: I0942701204fe8499e8890740585b9a02c1d14c63
The internal name "more" conflicts with new collapsible buttons.
TODO: looks like TemplatePage has an analogous field?
Change-Id: I10b24758316a6cc3fbd236c77daffa014fcdafc6
When $wgVisualEditorTransclusionDialogInlineDescriptions is set to
true, the template dialog will use a larger format.
Bug: T273971
Change-Id: Iad3c3f4d65125c83e35414ce15f793f6a1b192ef
