Change the ui/data behavior to work with oojs and event emitters,
and replace the gui from jquery ui to oojs-ui.
Changes made:
* Recreate the templatedata editor with oojs and ooui.
* Create a standalone templatedata model with internal validation.
* Allow the user to insert language-specific strings:
* Allow adding arbitrary languages and values
* Normalize output between language object and 'simple' string
* Add new language code by searching for its name or code
* Import parameters from template code
* If the template is in subpage and there is no code in the
current page, the code will request the contents of the parent
page.
Change-Id: I985ea03dfee58984ec22ec9a157a00968bfca878
Add "maps" as an allowed root value to template data JSON.
Maps allow applications to map equivalencies between their
application-specific parameters and valid template parameters.
Each Map has arbitrary keys (from the consuming application) that
are mapped to one or more template parameters.
* Added root.maps to TemplateDataBlob
* Validates that values are strings or arrays
* Validates that values are valid params
* Added templatedata-invalid-param to i18n/en.json
* Richer error message for when invalid value is a param
* Fixed existing tests to work with new "maps" property
* Added two new tests for maps
* Test for invalid value (!string or !array)
* Test for invalid parameter
* Added specification for root.maps property and Map object
Change-Id: I3bf5e002ad6c1632e02c4c2e393b244c51f77177
These wiktext-isms from the Status object make the tests rather
obfuscated and hard to read/maintain.
Change-Id: I6438c33229ac013489893f8a2241510d9b5a7765
Add an 'autovalue' parameter property to the TemplateData spec. And
implement it in the validation for the API and in the editor.
Also added tests to make sure all parameter attributes preserve
their values before and after parsing, including the 'autovalue'
parameter.
Bug: 51428
Change-Id: Iffb376a804d39388d2b5b6ea3583ef2a292eea41
Refactor and rewrite the templatedata editor to make it more flexible and
adaptable to new types. Separating the model from the gui, and adding new and
improved unit tests.
Also added features:
* Map depracated param types into current types.
* Retrieve template code from top template page if we are in a subpage.
* Mark parameters that do not appear in the template code.
* Add parameter types and a more flexible way to add and adjust the types.
* Add a link to TemplateData documentation from the main edit page.
* Add support for paramOrder; order the parameters according to the given array.
* Make the template parameter table sortable so users can change the paraOrder.
Bug: 59745
Bug: 65951
Bug: 66920
Bug: 67310
Bug: 67621
Change-Id: I65a76c2b772ef76c5dbbe71dd433c881c097b202
Some descriptions allow for language objects. For the moment, these
should be blocked for editing so the original JSON string won't be
corrupted. The current fix blocks any input that is not a string
or an expected array in aliases as uneditable.
Bug: 60089
Change-Id: I9b13e2f3cfd805d382564e270484557567932a0f
There was a pre-existing jshint config (.jshintrc) file that this upgrades based
on the equivalent files for VisualEditor and OOjs UI.
Change-Id: I3ecb0e65cc7ff090b7457be895917fbd8b8afd18
This is a status for parameters which are not 'required' but are recommended
to be high value, if not always used, by downstream template users. This
commit does not add GUI-related changes to address this, as the interface
probably needs moving from checkbox- to dropdown-based status setting given
that there are now four, rather than three, mutually-exclusive statuses.
Change-Id: I104976e76d5ad6d586d9c818418ba6e16af53506
This adds a TemplateData manager to the edit page in the Template
namespace.
If a <templatedata> tag already exists, the tool will parse it and
display it in a visual interface that the user can then manipulate in
their own language. If there is no <templatedata> tag, the dialog will
appear empty and allow users to add and tweak their desired template
parameter data.
The tool also allows rudimentary parameter import, which picks up the
parameters from a current template into the GUI to make the user's life
easier when producing TemplateData.
The template documentation editor feature is off by default. To enable it
use $wgTemplateDataUseGUI = true in LocalSettings.
Bug: 50436
Change-Id: I863a8199c0b08cc52b320ed00dcba912dd2aeefc
Status::getHtml now wraps the html in <p> tags, unwrapping
them for now, classic parseinline style..
Change-Id: Ic9b651cbd76752346ea7cbf230af49f09ef3ec12
For example, in case of failure we were defaulting to an empty
object, even though that is invalid input.
Change-Id: I00b4ce26b04ec408b5e86b9a2242cf942300ad41
* Detail the new property in the spec.
* The property is optional (as all new properties have to be
for backwards compatibility).
* Validate value if present, and for normalisation fill it
with inferred order from the JSON parser. This means the API
output will always contain #paramOrder, however the strict
specification for it is optional and users must still account
for absence of this property.
Bug: 53608
Change-Id: I7bcd7c9146f5ae75c4bad22b0a9cd4400f196c8c
* An empty array for a Set is invalid and the implementation now
enforces this.
* Add new error message for invalid value. When Sets contain a
reference to a key that doesn't exist, it should say that that
reference in the Set is invalid instead of saying that Params
is invalid for not having it.
> { params: {}, sets: [ { params: [ "quux" ] } ] }
- Required property "params.quux" not found.
+ Invalid value for property "sets.0.params[1]".
Also:
* Abstracted handling of $case and the different assertions
on it in a helper function so that we don't have to repeat
it everywhere.
* Use the same hack as in other tests to display the status error
message in the phpunit output (true === isGood ?: getHtml).
Maybe use '' === getHtml instead, though that is also evil
since Status fatals if you call getMessage/getHtml for a good
Status object.
Change-Id: I06a6615f728cd287a4839e09eedc2d0eeb537949
Fallback for user language and content language is easiest to
resolve server-side. Also saves sending a lot of data to the
client that it doesn't need. Similar to how ResourceLoader only
sends 1 set of message values.
Bug: 50431
Bug: 52922
Change-Id: If8317ed6522a05d5a48a210ff43c97277b950a97
gzdecode() has been introduced in PHP 5.4 although gzencode() has been
there for a while. Wikimedia is still using PHP 5.3, so the
TemplateDataBlob::newFromDatabase() would trigger a fatal error whenever
it is passed compressed JSON :-(
The test does not fix the root cause (that needs a fallback function in
the TemplateData extension), but it does highlight the issue in PHP 5.3.x.
Updated a @return comment, correcting the class being returned.
bug: 54058
Change-Id: I8357b474165f4317982b9c924cf0afe68650d677
We only have 65535 bytes, let's use them wisely.
Prior to Ib2db241a in core (1.22wmf12) even binary page properties
were sometimes shown as plaintext (e.g. on Special:PagesWithProp).
Thus this introduces a "soft dependency" on that change.
No backwards-incompatible changes were made in public methods.
Added two new ones:
* Add TemplateDataBlob#getJSONForDatabase which returns compressed
JSON, use it where applicable.
* Add TemplateDataBlob::newFromDatabase which accept compressed and
uncompressed JSON, use it where applicable.
Use a long pseudorandom string in the test.
Bug: 51740
Change-Id: Ie66b0dd6b6dab6f8648e78595c41e52d9c704d57
This might not be necessary on non-MySQL databases, but I'm sure that
at least their limits aren't lower than MySQL's, so let's stay on the
safe side.
Bug: 51740
Change-Id: I9c7115a951f126844bc70755bff12e8cd5fc2be1
Previously we only compared output, we now evaluate
status as well.
For example test {} => {} was misleading since the reason
it roundtripped was because it is *invalid* and we replace
invalid blobs with an empty object in blob storage.
But in the API this'll never get used because getStatus
will have a fatal error in it. Which overrides the data.
The tests were previously looking in the data whilst ignoring
the return status.
Change-Id: I9809f126c1615c9bc9c28ce2d8bb7953058cbf6e
InterfaceText now defaults to null instead of {en:""} which
was awkward to deal with in the frontend.
As specified:
- label is InterfaceText
- type is a string and must be a one of the recognized types
Updated example for the hypothetical variant of Template:Unsigned
and removed other no longer needed example.
HTML output has been revised per conversation with Trevor,
James and Timo:
- Not sortable.
- Add label to html output.
- Aliases in the main parameter column (one per line),
but muted in styling.
- Add type to html output.
The css module styles content from the server, not content
generated by javascript. Moved module to position => top to
fix flash of unstyled content.
Change-Id: I16d3f9e460c5513935b9b55fe4cec0092b38e6c2
I ran into countless random exceptions and errors locally due to
cache I built up over time that was no longer valid. Though in
approved commits in the repository there is only 1 version as of
now, I'm sure we will make changes in the future that require a
cache invalidation since getHtml needs to be able to make
assumptions about what properties exist.
Also fixed a bug in the parse() method where the 'deprecated'
property is asserted the wrong way around. Added a test for it.
Change-Id: I5f61d6030578a711909435c8b996373e9aaa5178
* Add unit tests for all types of invalid input we check for.
* Add unit tests for all types of input we expand or otherwise
normalise.
* Implement InterfaceText expansion/normalisation.
* Fix bug that caused a string value in the root description property
to be considered invalid (it only accepted an object, it should
accept both).
Change-Id: I5a15080f1f924451a9dde8af96ea2922011981ec
