Page MenuHomePhabricator

Property value parsing, formatting and validation should be done (only?) in the backend
Closed, ResolvedPublic

Description

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.


Version: unspecified
Severity: normal
Whiteboard: u=dev c=story p=0
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49265
https://bugzilla.wikimedia.org/show_bug.cgi?id=56261

Details

Reference
bz49186

Related Objects

StatusAssignedTask
OpenNone
ResolvedLydia_Pintscher
ResolvedNone
ResolvedNone
ResolvedNone
ResolvedNone
ResolvedNone
Resolvedadrianheine
ResolvedNone
Resolvedadrianheine
ResolvedNone
ResolvedNone
ResolvedNone
ResolvedNone
ResolvedNone
ResolvedNone
ResolvedNone
ResolvedNone
ResolvedNone
ResolvedNone
ResolvedNone
ResolvedNone
ResolvedNone
Resolvedadrianheine
DeclinedNone
DeclinedNone

Event Timeline

bzimport raised the priority of this task from to Normal.Nov 22 2014, 1:51 AM
bzimport set Reference to bz49186.
daniel created this task.Jun 5 2013, 3:50 PM

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.

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.

  • Geo is using backend parsing;
  • Quantity is using backend parsing;
  • Time is still parsed in the frontend;

Sorry, accidentally closed this one..

Current status is that formatters are done, parsers are wip and validation is not even started.