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

Assigned To

None

Authored By

	daniel
	Jun 6 2013, 5:03 PM

Description

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:
https://bugzilla.wikimedia.org/show_bug.cgi?id=49186

Details

Reference: bz49265

Related Objects
Search...

Status	Assigned	Task
Open	None	T87764 Bugs related to time datatype (tracking)
Resolved	Lydia_Pintscher	T50962 localize display of time values
Resolved	None	T50937 Implement value formatter for time data type
Open	None	T68654 Make geo/globe coordinate diff more readable
Resolved	None	T51404 Coordinates diffs are blank
Resolved	None	T50888 Improve data value validation and error handling in api
Resolved	None	T50860 [ui] First version of geocoordinate datatype support
Resolved	None	T47046 Normalizing file names for display
Resolved	None	T50965 time data values are not validated when saved via api
Resolved	None	T63254 Item values are not linked when Javascript is disabled
Resolved	adrianheine	T63738 Spaces in commons file names are replaced by plus signs instead of underscores
Resolved	None	T51014 Use value formatters for displaying values on Entity pages (non-JavaScript view)
Resolved	adrianheine	T51186 Property value parsing, formatting and validation should be done (only?) in the backend
Resolved	None	T48365 Need generic string value formatter
Resolved	None	T55745 Implement a factory/registry infrastructure for snak and value formatters
Resolved	None	T51387 property parser function needs to support geocoordinate datatype
Resolved	None	T54598 Coordinates do not work with normal inclusion syntax
Resolved	None	T52277 Implement value formatter for geo data type
Resolved	None	T53113 Formatter for URL datatype
Resolved	None	T51265 Spec out registry/factory for formatters and parsers in the backend

Event Timeline

• bzimport raised the priority of this task from to Unbreak Now!.Nov 22 2014, 1:56 AM

• bzimport added a project: MediaWiki-extensions-WikibaseRepository.

• 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.

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:
http://meta.wikimedia.org/wiki/Wikidata/Development/Data_values

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

"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.

Spec out registry/factory for formatters and parsers in the backendClosed, ResolvedPublicActions

Description

Details

Related ObjectsSearch...

Event Timeline

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

Related Objects
Search...