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
Ensure that a form field which sets 'csshelpclass' and is rendered as
a vform receives expected styling.
Change-Id: Ibe082e07fe846334bd4dc257c9c0df8db23a1957
Hidden fields are supposed to be ignored during validation; more
completely ensure this by checking in HTMLForm::trySubmit before calling
validate.
Also, more properly handle HTMLCheckFields in the isHidden check by
casting their booleans to strings.
Bug: 68132
Change-Id: I84f8239c299727b773015643048eed4684417733
- Swap "$variable type" to "type $variable"
- Added missing types
- Fixed spacing inside docs
- Makes beginning of @param/@return/@var/@throws in capital
- Changed some types to match the more common spelling
Change-Id: I41a84e8e1dec39170aa655250325ffc485eaeaef
There is now a new option named csshelpclass that can be passed in form
descriptors for HTMLForm objects. This option accepts a css class and
applies it to the help text that is provided with the help option in the
form descriptor.
Bug: 65087
Change-Id: If1bd1d12a9159895f45c9cf0fbb7992e4c7e3526
Require use of class instead of applying styling to all <div>s
This resolves a few FIXMEs and dramatically lowers the awkwardness
level of using mediawiki.ui.
'.mw-ui-vform-field' is a more descriptive name than '.mw-ui-vform-div'
and corresponds to the HTMLFormField PHP class in core which generates
<div>s with this CSS class.
We previously styled '.mw-ui-vform > div' the same way we styled
'.mw-ui-vform .mw-ui-vform-div', which was an annoying piece of magic
causing difficult to debug problems when one needed a different HTML
structure (like bug 63233). Explicitly using '.mw-ui-vform-field'
where applicable is a lot saner.
Change-Id: I6f0b8842f5fdf70b97decb165086d1a83428b259
SecurePoll is going to need the ability to have a form for stuff like
"one or more admin usernames" and "one or more poll questions, each with
one or more options".
This change implements a generic field container that simply displays as
a <ul> followed by an "add more" button, with each <li> containing
various fields including a "remove" button.
Since this is only going to show up in SecurePoll to people creating a
poll (not to general users), the current design is functional but not
necessarily beautiful. Those interested in beauty are welcome to do so
in a followup change.
Change-Id: I46fad3971739ddc961259fe32eb6e1cd265a1c06
SecurePoll will need a way to display a field only if another field has
a particular value.
We already have this for a limited case in HTMLSelectOrOtherField; this
makes it possible to specify that any particular field should be hidden
based on any other field.
Change-Id: I5d2e6fb1efba0ad97647ac140e2b9a9ac0aee06e
Swapped some "$var type" to "type $var" or added missing types
before the $var. Changed some other types to match the more common
spelling. Makes beginning of some text in captial.
Change-Id: Ifbb1da2a6278b0bde2a6f6ce2e7bd383ee3fb28a
One shortcoming in HTMLForm is that fields that use the 'options'
parameter (e.g. <select>) have no easy way for the individual labels to
be localized.
This change adds a new parameter type, 'options-messages', where the
keys are message keys rather than bare strings (similar to the
difference between 'label' and 'label-message'). It also abstracts out
the fetching of the various option parameters, and changes the necessary
field classes to use it.
Change-Id: If4175332405d26c7ff2e8fbe100bcad61762ce6f
It is already set for some fields in Special:Block, but are
discarded by HTMLForm and its fields.
Some notes:
- fields with multiple inputs (radio, select and other, select
or other) will have the same tabindex set on all elements
- Some items such as multi-select and check matrix are not yet
implemented
Change-Id: I3e1ba7f16f3a3183f231afcf60dd392ce6d6eb6b
