Last modified: 2014-09-25 11:35:46 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T51186, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 49186 - Property value parsing, formatting and validation should be done (only?) in the backend
Property value parsing, formatting and validation should be done (only?) in t...
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
WikidataRepo (Other open bugs)
unspecified
All All
: Normal normal (vote)
: ---
Assigned To: Adrian Lang
u=dev c=story p=0
:
Depends on: 46365 49263 49264 49265 51111 53745 56263 56716 62184 62185 62189 62190 62377
Blocks: 48962 45046 48860 48888 48965 49014 61254 61738
  Show dependency treegraph
 
Reported: 2013-06-05 15:50 UTC by Daniel Kinzler
Modified: 2014-09-25 11:35 UTC (History)
6 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Daniel Kinzler 2013-06-05 15:50:38 UTC
Property value parsing and validation should to be implemented in the backend, and should be removed from JavaScript. Here's a few reasons:

* the web API has to validate input; validation needs parsing.
** we could restrict the API to a very simple format. This forces bot authors to re-implement the parsing functionality in order to created the form we'd required for the API from their input (notably, from Wikipedia)
* the backend needs to be able to render/format all values, for (non-JS) display, RDF output, etc. Output formats should be parseable, providing round-trip functionality. This is much easier if rendering and parsing is implemented in the same place.
* parsing and formatting should only be implemented once, if at all possible.

In the backend, I suggest to allow any number of parsers for each data format. Try each parser, until one accepts the input.
Comment 1 Daniel Kinzler 2013-06-10 09:41:39 UTC
The arguments above also apply to formatting: we need formatting in the backend, including support for localization (and even personalization, in the case of date/time format). 

As for parsing, it may be ok to only support the parsing of canonical formats in the backend, and let the frontend deal with handling the quirks of human input.
Comment 2 Daniel Kinzler 2013-11-15 13:08:13 UTC
Rough proposal:

* create wbsnakvalueparser for parsing snak values based on property ID and/or data type ID. This should have an option to apply validation, too.
* create wbsnakvalueformatter for parsing snak values based on property ID and/or data type ID. This needs to support different kinds of desired output, too (plain text, html, etc).

Note that the modules parsevalue and formatvalue provides by DataValuesCommon are not sufficient, since they can not handle DataType specific formatting or constraints, nor do they support different output formats like html.
Comment 3 tobias.gritschacher 2013-12-11 11:22:20 UTC
* Geo is using backend parsing;
* Quantity is using backend parsing;
* Time is still parsed in the frontend;
Comment 4 tobias.gritschacher 2013-12-11 11:25:36 UTC
Sorry, accidentally closed this one..
Comment 5 Adrian Lang 2014-02-20 10:23:27 UTC
Current status is that formatters are done, parsers are wip and validation is not even started.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links