This is split from patch Iebb982e to make it easier to review.
The name is rather ambiguous. Does "input" refer to the input
element? Is it triggered for every key press, i.e. when the
input changes? Or when it's submitted?
Change-Id: Iddbe3bfb9faf3561d8d71b96ffae507799827a95
Any of these characters results in bad wikitext, when we accept
it in a template parameter name.
Instead of displaying an error message we simply block the
button, as long as the input is not a valid parameter name.
Coming up with a message is not really worth it, I would
argue. Users typically don't have a reason to use any of these
characters. This is super rare. And even if, the behavior of
the widget is not hard to understand, I believe.
The same is done in ve.ui.MWParameterSearchWidget, a little
hidden in the .addResults() method.
Not yet approved by UX. Can be done in demo time.
Bug: T285869
Change-Id: I5576cdfb90411e5fdec93749f72939d31ecd9c56
* New help text for the case where TemplateData is present, whether
or not it includes a description.
* Remove help text when TemplateData is missing.
Bug: T288465
Change-Id: I0668ccae8eeb5ffffc626e3b7d24c1d7ed99bbed
- Change description text according to ticket
- Make sure link to template page opens in new tab
- Add missing placeholder text
Bug: T272487
Change-Id: Ie8189e9cb9db5908e8fc5fc8bf7ff20df5595094
When I press the button to expand the input field for
undocumented parameters, it needs to be focused. Otherwise I
have to click it manually all the time.
We probably forgot to list this as an acceptance criteria when
working on Ic5dcd36.
This also replaced a bit of JavaScript with CSS. I do this
mainly because I found the mixture before (one piece was
hidden via JavaScript, another via CSS) a bit confusing.
Bug: T272487
Change-Id: I0cbee63c65a37f2f1860bde007c1e5c8408ba006
This is mostly, if not exclusively visual, at the moment. The
actual state is still managed by the old sidebar.
I made the element OptionWidgets for convenience. This gives us
all the functionality we need (primarily setSelected and
isSelected), without to much clutter. However, I didn't made
the container a SelectWidget. This comes with to much stuff we
don't need at this level, e.g. cursor key navigation.
Bug: T285323
Bug: T289043
Change-Id: I20dbd2ba23ceaa9125947b25e037c0bb3c91a471
There are 2 situations:
1. Either the template name is used in a [[…]] link. In this case
we must provide the namespace. MWTemplateModel.getTitle() does
this. However, it's not a mw.Title object and therefor not really
guaranteed to be a valid title. This is fine. The worst thing
that can happen is that the link points to an error message.
But this should be entirely unreachable anyway.
2. Some messages want to display the name of the template.
Ideally without the namespace. That's what
MWTemplateSpecModel.getLabel() is for. Again this is not
guaranteed to be a valid mw.Title. But it doesn't need to. It's
only used as a label.
Change-Id: I03d0481201620a2f5c444ee32b656bcaade98aac
We should only need that label for the link. The other mechanic
would fail when editing wikitext like this:
{{{{echo|<}}|param=foo}}
Bug: T272487
Change-Id: If8d228b40bf1589181e83e8f68f3c33b4c7759c7
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
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
I found this while working on T274551, which is all about the
definition of "empty".
In the old sidebar a parameter's name is dimmed (gray) as long as
the parameter's value is empty. This stops working entirely when
there is a default value.
My first impulse was "this is a bug". When there is a default
value, both the empty string and the default value (when the user
enters it exactly) typically trigger the same behavior: The
template uses the default value, just as if the user entered it.
But this code is correct because of the way it is used. Only
parameters that are "truly" empty should be visually marked as
such. The moment there is a default value it is either impossible
to change this back to an empty string – meaning the parameter
can never be truly empty – or the empty string is meaningful user
input.
Bug: T274551
Change-Id: I90657bfe83e56afd3942428c0dd8a47b444e39c9
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
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
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 reverts commit 950a5300dc.
Reason for revert: This broke several workflows. The reason is
that MWParameterPlaceholderPage & MWParameterSearchWidget both
hold references to the MWTemplateModel. This model is not
always the same. The dialog might be the same when a template
is edited multiple times. But the model might be a new one.
From this point on the MWParameterSearchWidget pulls data from
an outdated model.
Bug: T284636
Bug: T285571
Change-Id: I7b9ea8cab8f17705ec8020f07e3732da6ba0e73c
This reflects much better how this method is meant to behave.
Note I will continue to remove documentation that doesn't
explain anything in addition to what the code already says.
Bug: T285483
Change-Id: I81fa8a5d9d0752f3aeac4015c9a27b50e054d4df
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
* 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
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
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 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
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
The names in the schema are roughly following what's
done in Schema:TemplateWizard. The information if
templates have TemplateData will be logged seperatly.
Bug: T259705
Change-Id: Iafa7256f675dbfd6a5a6de794061901780e3c55d
The first edit to a parameter will cause an event to be sent,
subsequent edits to the same parameter will not send an event.
Bug: T258920
Change-Id: Ibe663ce99a8fdf85a5add17186fb44fdbd4176bf
Record that a parameter was added, and whether it was known or
unknown--whether it's documented the TemplateData. Note that
`.isParameterKnown` returns true after an unknown parameter is added
to the template, so we need to set up the event early.
Bug: T258920
Change-Id: I5f8d8d06226474160a0a82c2e85a7fa4e22ba8cb
These constructors only take a single argument, so the api config was
being ignored and the input would fall back to the default `new
mw.Api()`.
The order is changed so that the "api" config is merely a default,
and can be changed by whatever comes later.
The UserInputWidget currently doesn't accept an "api" config. This
will be fixed in Ifb1dd9d. But this is not a blocker. Merging this
patch here before the other won't have any consequence. It will just
continue to ignore the "api" config. ;-)
Change-Id: I15c35216c717576c6767927cac06ef72198fc95a
The input field becomes a title autocomplete, showing small preview
images and searching only the File namespace.
This is consistent with how TemplateWizard behaves when editing a
File parameter.
Bug: T260886
Change-Id: I7a114e279436ec1ff6f7b8ab66443138ab12637f
A @method annotation is only necessary when the docblock is not
directly followed by a function declaration (in which case JSDuck
assumes it documents a property), e.g. when defining an abstract
function or referencing a function from another library.
I verified that JSDuck generates exactly the same output before and
after this change (docs/data-<hash>.js files are identical).
Change-Id: I7edf51a8560ab9978b42800ab1026f0b5555c3bf
There are cases where the page title and the real/desired page name
are not the same. Fixing that also fixes the suggestions that appear
in dialogs (see related bug).
Bug: T193132
Change-Id: Iafa84c05bea08ebb061ee6d1323eb50945b39815
When this code was written in 2013 (1a5bdd5bd2),
the langlinks API did not have a way to return the language names (autonyms).
This has been added in 2014 (4ba3a9aea96ee21c035c69999be23580e23f4e0a).
Change-Id: I70edb846d94b1108b079caf5915532234190da8f
Generating the templatesUsed list is relative slow, and is only
used in an obscure part of the editor, so only generate it when
needed.
Bug: T209078
Change-Id: I1cecdad65b80c4c9b1746e752ea4b41bc0fc0037
New changes:
202adf904 [BREAKING CHANGE] Unify FragmentInspector/Dialog behaviour
Local changes:
* Update dialogs to use common actions & FragmentWindow
Change-Id: Ib744b8996db48d1ee58bc873120400566c490e88
Extracted extractValue to a separate method
Added checkValidRedirect method to MWSettingsPage
Added errors when redirect address is invalid
Added 1 error message to localisation strings
Added 1 TODO (more precise error messages)
Bug: T74971
Change-Id: I8bcf16e97e5211671759acdf0846243df2c03fc2
This way users can rearrange/edit current name without exiting VE and/or copying it from somewhere else
Bug: T145339
Change-Id: I80690cdf344c2ccbdd8be486642afcf841f36c10
The initial value for the categories field is set asynchronously
(after potentially querying the MediaWiki API about the categories).
This caused the existing categories to "pop in" after the dialog was
opened (if you were on a slow network and it took more than 250ms to
query their information).
Additionally, it caused the "Apply" button to always be enabled if the
page had any categories on it (since the categories field was still
empty when extractSettings() was executed).
Bug: T207719
Change-Id: I46475a1eead91707edb8efe8cb7221a734818e16
Added 5 methods for MetaDialog (documented in code comments)
extractSettings
compareSettings
getAllWidgets
assignEvents
updateActions
Added 2 fields to MetaDialog
oldSettings
widgetList
Apply changes button now is only enabled when there are new changes
Added getFieldsets method to all subpages
Bug: T207719
Change-Id: Id51acf6c754d9a2572811775d83983e6ab9395b7
TemplateData doesn't always match up with the way the template is being used.
If a field has the `line` type, but is provided with newlines, we should avoid
mangling it by forcing it into a single-line field. As-is, any edit to the
template, even if the user only thinks they touched unrelated parameters,
would cause this.
Bug: T190191
Change-Id: I4f2a0b6c46532dcc268288cb209d0260b18f3ad7
There is something about ActionFieldLayouts with `align: 'left'` (the
default) and no label that causes Firefox to render them differently
than we expect. I am not sure if the bug is in OOUI or Firefox, but it
is easily avoided by just using `align: 'top'` instead (it looks the
same, since there is no label, and it avoids the issue).
Bug: T198274
Change-Id: Ic6077e576b504e7a0cd761c8bac24d4079ae6702
Pass through the current document when available, otherwise
assume the current surface's document.
Also add a getter for getPageName, so that can vary based
on the target document.
Bug: T193856
Change-Id: Ifdc951fdc6a43b924d102e3fcd7e59e52023757b
Add label to indicate the function of the input field underneath the
categories label in the options dialog. The <label> element is
preferred for screen readers and users with visual disabilities.
Bug: T146966
Change-Id: Ib300ca7a1fd55d320c1a1a8c8c7fd01ab8b0b9c5
Also, pass $overlay to all PageLayout subclasses used in ve.ui.MWMetaDialog
and ve.ui.MWTemplateDialog/ve.ui.MWTransclusionDialog, for consistency.
Bug: T191395
Change-Id: Ib7ed2e2c04ff7930be1161bd2b981180ee59557a
The default value of target#pageName is wgRelevantPageName
but other targets my override this, or change it dynamically
(e.g. ContentTranslation).
Also remove duplicate setter of pageName in mw.ArticleTarget,
already set in mw.Target.
Change-Id: Iebd1def1d4142978a673afec584a0b663644d176
