Rather than have a master list in autoinfuse.js (duplicated in
hide-if.js), we put this information in each field class and put it
in the generated HTML as a separate 'data-' attribute. This also
allows new fields defined by extensions to be correctly autoinfused.
Change-Id: I3da75706209cbc16b19cc3f02b355e58ca75fec9
For plain HTML forms, we just put the required data in the 'data-hide-if'
attribute. For OOUI, it's not so easy - while we could just call
->setAttribute(...) on the FieldLayout, this would disappear when
infusing (since it's not part of the config), and we have no control over
when some piece of JavaScript decides to infuse the element. Even if we
managed to handle it first, infusing replaces the DOM nodes for elements
with new ones, which would "disable" our event handlers.
To solve this, I'm creating two new layouts HTMLFormFieldLayout and
HTMLFormActionFieldLayout (subclassing FieldLayout and ActionFieldLayout)
with a common trait (mixin) HTMLFormElement. This is all implemented both
in PHP and JS. Right now it only serves to carry the 'hide-if' data from
PHP to JS code, but I imagine it'll be extended in the future for other
HTMLForm features not yet present in the OOUI version (e.g. 'cloner'
fields).
The code in hide-if.js has been modified to work with jQuery objects or
with OOjs UI Widgets with minimal changes. I had to duplicate the map of
HTMLFormField classes to modules they require there (from autoinfuse.js),
which is ugly - I'm fixing this in a follow-up commit
I3da75706209cbc16b19cc3f02b355e58ca75fec9.
Bug: T141558
Change-Id: I3b06a6f75eed01d3e0bdc5dd33e1b40b7a2fc0a2
This is not really what we had in mind when developing the infusion
feature and I think it's not helpful. Most of the time there is just
no benefit; a ButtonWidget generated in PHP and in JS behaves and
looks pretty much the same, and rebuilding it through infusion is a
small performance hit. If you're not adding any event handlers, it only
makes sense for various dropdowns, which have themed styling.
For the primary use case of adding JS behaviors to PHP widgets you
need to call OO.ui.infuse() anyway to get a reference to the JS
widget, and not infusing automatically should make it easier to reason
about your code. Infusion tries to be very transparent, but it can't
hide the fact that the DOM is re-built, making your references to DOM
nodes from before infusion useless and losing anything from PHP that
wasn't included in the config (e.g. custom attributes).
This commit removes automated infusion from mediawiki.page.ready
and adds some custom code in mediawiki.special.movePage and
mediawiki.htmlform. I see only two extensions using infusable OOjs UI
widgets in Gerrit (ArticlePlaceholder and ExtensionDistributor) and
neither should be affected by this change.
Change-Id: I56608c537fc57c5c54960b0603694f2612f45618
Calling HTMLForm::setFormIdentifier() will set an internal identifier
for this form. It will be submitted as a hidden form field, allowing
HTMLForm to determine whether the form was submitted (or just viewed).
Setting this serves two purposes:
* If you use two or more forms on one page, it allows HTMLForm to
identify which of the forms was submitted, and not attempt to
validate the other ones. (T102114)
* If you use checkbox or multiselect fields inside a form using the
GET method, it allows HTMLForm to distinguish between the initial
page view and a form submission with all checkboxes or select
options unchecked. (T29676)
Bug: T102114
Bug: T29676
Change-Id: Ib6ce3fd8941be86211cff5c6932b5e84982490fa
'notice', 'notice-message' and 'notice-messages' can be used
as a parameter to the HTMLForm field to show the notices.
Only added implementation for OOUI forms because I'm not sure
what to do for others.
Bug: T104423
Change-Id: I512f3936bc3335df1bdf76505cfc39da6be99bed
Improves Ida647973a which unified message handling for form fields
but did not make the functionality available to HTMLForm itself.
Change-Id: I2e6195ba13afbd8b993acb47409fab1be91c547e
Fix a test in If4e0dfb : in the unlikely but valid case when
some form field object returns null from loadDataFromRequest,
handle it correctly and do not replace it with the default value.
Bug: T133163
Change-Id: Id8b48cfc6288d11a79a5838e72bb80b14137a7b0
- do not return anything when the button was not clicked
- return boolean true (instead of the button text) when it was clicked
Unbreaks submit fields which currently don't return anything so there is
no easy way to tell whether they have been clicked.
Change-Id: If4e0dfb6ee6674f0dace80a01850e2d0cbbdb47a
*-message(s) settings were documented as message key strings or arrays
of message key strings, but some actually accepted [key, params...]
arrays as well. They did not accept Message objects, which would be
the cleanest and most flexible method of message passing.
The patch adds a new method to process these settings (which accepts
a messages key, a [key, params...] array or a Message object), and
makes all *-message(s) usage call that.
Change-Id: Ida647973a58bea83fdbd53335e63b5a8615c16e4
Fix the OOUI field element implementation to conditionally add
labels to the FieldLayout (only if the label isn't empty). Also
add setShowEmptyLabel( false ) to HTMLButtonField (labels usually
aren't set outside of the button, the button itself should have a label).
Bug: T129821
Change-Id: I0499bb82245273519e77c80e78bc431588875a85
Depends on I0e5c956b9358b510c8473b1cfe6465ea1b5c07ef in OOjs UI.
This mostly reverts dd04b31052 and parts
of e85bd04bcd.
In addition to cleanup, it fixes bugs in HTMLFormFieldWithButton
(which did not add some attributes in OOUI mode) and HTMLMultiSelectField
(which did not do the mapping, losing some attributes in OOUI mode).
Change-Id: I0d1a5288e9edb73a0c3a8431feca9fcc67b72b6a
Switch to OOUI HtmlForm and replace mediawiki.userSuggest with
OOUI HtmlForm type user.
Bug: T117734
Change-Id: I37d9acbdd272c0cc2f2e120aada2e9fcea215509
Hidden elements doesn't need an extra element in the DOM, but OOUIHTMLForm
would render one, wrapped into a fieldLayout div.
Fix this by adding the possibility to bypass the output, and only construct
a HTMLFormField element and run the output method.
Bug: T117768
Change-Id: I8c9d2ff862f1b14d72a9bb9e1a51e8745af6d1f4
HTMLFormField subclasses are supposed to handle error display but
some (like hidden fields) have no means of doing this. Add
a HTMLFormField::canDisplayErrors() method which can be overridden
to return false, in which case HTMLForm will take care of the
error display.
Also adds a 'rawmessage' message which can be used to wrap
arbitrary text. This can be passed to methods which expect a message
specifier array but do not allow a message object (so the RawMessage
class cannot be used), such as HTMLFormField::trySubmit().
Bug: T112635
Change-Id: I5d73536805774ff2ee0ec64b5442650c4888dc84
HTMLFormField::getAttributes() is unfortunately reused both for
generating HTML tag attributes and generating OOUI widget
configuration. For boolean ones passing '' for true (empty string)
works for HTML (where the attribute only has to be present), but not
for OOUI (where the configuration option has to be truthy).
It would be cleanest to pass true/false, which is the expected input
for OOUI widgets and which the Html class handles intuitively, but it
seems that these values often end up in the Xml class's methods
instead (somebody remind me why do we even have that?). So let's play
it safe and pass the name of the parameter instead, which is okay for
both HTML/XML (both disabled="" and disabled="disabled" work the same)
and OOUI widgets.
(Note also that the whole thing relies on the default value of these
boolean parameters/attributes being false.)
This was not spotted before because we had hacks for this problem in
all the important places. This commit reverts three such hacky
patches that missed the underlying problem:
* e25eb30ea8
* 70910cd13c
* 8a164ff9f9
Change-Id: Ic6a1f3758cba62147f7fe8127cc0a83c695b0212
Depends on Ie14a35fac70d62ff7d102caaa56654ebde11d7dd in OOUI.
Part 2 follows after some cleanup in intermediary commits
in Ifbf38878d41906184f97169b22002f788711a311.
As a bonus, HTMLFormField::getOOUI() now always produces a
OOUI\FieldLayout in OOUI mode. This will let us clean up some code
where we had to take errors HTML from HTMLForm
(I91af6efa8762e9676efea532381292e221255862).
Bug: T98894
Change-Id: I860a96858c4fcac62d63b46e35a9153f22c0a9c9
Doxygen uses a single "\" as a start sign for a command.
Anything after "OOUI" will be interpreted as a command
(and throws a warning "Unknown command" or something else) when
you create the doc. The doc itself will show the following
as the return values of the function:
Returns
OOUI|OOUI
See: https://phabricator.wikimedia.org/F214499
As a workaround you can escape the backslash with a second
backslash (OOUI\\FieldLayout) or this notation should work, too:
OOUI::Fieldlayout
Follow up: I9050c4a09cbb841ad26ca01a25f706227e35e3be
Change-Id: I0c9300e72e00e1d827c63074cbaa51a935828695
The @return doxygen parameter can take a class with a namespace, but
the \ needs to be escaped with an additional \. "\value" is usually interpreted
as a special command.
Actually with "@return OOUI\Widget", e.g., you'll get this output in your docs:
return OOUI
and an error message in the doxygen generation with something like "unknown command \Widget".
With "@return OOUI\\Widget" you'll get the expected output:
return OOUI\Widget
without any error message.
Change-Id: I14c4d7521f81ddd8c7b56facc1f0ae34f86b2299
Autofocus needs to be boolean true to work in OOUI (empty string is interpreted
as false), and it's working in div layout, too, so there is no need to transform
it into a string.
Change-Id: I8cb57e0b701c7bc07e75ae60ecd98911ac37d30f
Catchable fatal error: Method OOUI\HtmlSnippet::__toString()
must return a string value in
/var/www/html/w/vendor/oojs/oojs-ui/php/Element.php on line 245
$this->getHelpText() can return null.
Maybe OOUI\HtmlSnippet should be doing the casting instead, but it
currently doesn't.
Follow-up to 3ec3f08ca5.
Change-Id: I0bb2a1594ea5ffd86bf8abd41c13f9451df256d5
HTMLFormField::getHelpText() returns HTML and should not be escaped.
Depends upon 1dbef2766f23 in OOUI.
Bug: T104422
Change-Id: I33c8ebb448e345db7bf8b8ad540336b5b9d6aea1
* Transform all input fields to use HtmlForm as preparation for enabling
MediaWiki UI eveywhere.
* Remove protected whitespace for HTMLCheckField (adds empty line to div-layout)
* Add a new HTMLForm input field "Text with Button" and "Namespaceselector with Button"
Bug: T73434
Change-Id: I53cc019c3ca94cec8f3c05500d0c604c1af7f688
* Convert Special:LinkSearch to use HTMLForm for preparation of MediaWiki
UI everywhere
* Add support for dir= tag in HTMLTextField
Bug: T73439
Change-Id: I8503c391a40f1654f8570578a9de9015d86c9845
* Prepare the usage of MediaWiki UI.
* Add new HTMLForm output mode "inline" (very close to "raw")
Bug: 71436
Change-Id: I12240aaf624dff5219b344648b20373594b5ec46
Various fields use this differently than I thought, breaking things.
Let's add a separate variable.
Change-Id: Ia974a42c2a905cbc9e8405d9f03c10c8ad692864
…and in general, work with the existing HTMLForm design for defining
display formats, rather than against it.
Breaking changes:
* HTMLForm::isVForm() is now deprecated.
* You can no longer do this:
$form = new HTMLForm( … );
$form->setDisplayFormat( 'vform' ); // throws exception
Instead, do this:
$form = HTMLForm::factory( 'vform', … );
When using FormSpecialPage, override the new getDisplayFormat() method
instead of calling $form->setDisplayFormat() in the alterForm() method.
(Other display formats are not affected, only 'vform'.)
Bug fixes:
* Correctly suppress empty labels for VForm fields
* Correctly disable <fieldset/> wrappers for VForms
Other benefits:
* Reduce code duplication related to $getFieldHtmlMethod
* Introduce HTMLForm::factory() method for constructing HTMLForms
Related cleanup:
* Correctly style 'reset' buttons in MediaWiki UI mode
* Label $wgHTMLFormAllowTableFormat as a mobile-specific hack
* Display checkboxes normally in MediaWiki UI mode (removed weird
override that only broke things). Also, always render checkboxes
in VForms as .mw-ui-checkbox.
* self:: → static::
Bug: T85285
Change-Id: I086a84f1c8cc6a16710709b7806c7f5f96462b32
Pass the HTMLForm parent instance in the constructor so context
is available when parsing a message.
Change-Id: I532c0d95698cbcc57294b9bd2725f33838f393a9
