Page MenuHomePhabricator

Spec out registry/factory for formatters and parsers in the backend
Closed, ResolvedPublic


Several components of the backend need to format snak values in some way; Similarly, several components have a need to parse snak values. We need a specification of how code can get access to the formatter/parser it needs.

The following things should be considered:

  • formatters and parsers can be specific to a property (data) type, or generic for a given DataValue type.
  • formatters are specific for a given output type (e.g. wikitext, html, etc).
  • formatters and parsers can depend on the user's locale.

Experience with formatters and parsers in the front end's JS code should also be discussed and considered.

Version: unspecified
Severity: normal
See Also:



Related Objects

Event Timeline

bzimport raised the priority of this task from to Unbreak Now!.Nov 22 2014, 1:56 AM
bzimport set Reference to bz49265.
bzimport added a subscriber: Unknown Object (MLST).
daniel created this task.Jun 6 2013, 5:03 PM
  • Bug 48398 has been marked as a duplicate of this bug. ***

If bug 48937 is really highest priority (set by Denny) and really depends on this bug 49265, then this bug should also have highest priority.

Is anybody working on / assigned to this?
If bug 48937 is really highest priority (set by Denny) and really depends on
this bug 49265, then this bug should also have highest priority.

Denny added a comment.Jul 5 2013, 2:25 PM

Results from the specification:

  • Information about which formatter to use for which value will be in the FormatterFactory
  • Parsers are dealt with like Formatters
  • Validators are tied to the DataType
  • Instead of a BadValue, we have an UndeserializableValue (Naming by Committee) and it only refers to UndeserializableValues, not to Type Mismatches (those will be handled differently, no agreement has been reach as to exactly how)
  • a "BadSnak" throws an exception for now and can not be handled as a datastructure around (an UndeserialiazableValue is not a BadSnak in this sense)
  • Formatters are to follow the pattern used in Ask, i.e. Options are given to the constructor, it dispatches to different formatters ber format, etc.
  • FormatterFactory is injected wherever needed

Also on Wiki here, where it can be changed:

daniel added a comment.Jul 6 2013, 1:36 PM

I'd like to add that I think it would be useful to have one FormatterFactory per desired output type, i.e. one for HTML, one for plain text, etc.

Verified in Wikidata demo time July 17th

Danwe added a comment.Jul 22 2013, 9:02 AM

"formatters and parsers can be specific to a property (data) type [...]" is not yet possible in the backend, is it? We should either reopen this or create a new bug for it.

@Danwe: this bug only calls for the specification, which is completed with comment #4. Please open a new ticket for the implementation.

Currently, we can either use a ValueFormatterFactory, selecting formatters based on the DateValue type, or we use the list of ValueFormatters in the DataValue object (no idea why there is a list there...)

Right, missed the fact that this was about specs only. Opened bug 51799.