Page MenuHomePhabricator

Moving generating of HTML from EntityView into more modular formatters for Snaks/Claims
Closed, InvalidPublic


Right now all HTML is generated in the EntityView classes. When we start handing around DataValue objects, we might want to create more flexible views, allowing us to render single DataValue objects instead.

This would also allow for more flexible variations of views, e.g. a statement holding a MultiLingualText would use a basic view for that data type, the label and description claims should simply be able to use a variation of that view.

Version: unspecified
Severity: normal
Whiteboard: storypoints: 21



Event Timeline

bzimport raised the priority of this task from to High.Nov 22 2014, 1:08 AM
bzimport set Reference to bz40885.
bzimport added a subscriber: Unknown Object (MLST).
Danwe created this task.Oct 9 2012, 10:51 AM
Danwe added a comment.Oct 9 2012, 11:01 AM

It could make sense to do this after Bug 40885 so these DataValue related views could just hold a definition for which template to use and feed the templates with the right data.

Maybe use EntityHandler for providing the respective renderers. Change from inheritance to composition.

The respective renderers are required on Snak/DataValue level, not on Entity level. To make this a little clearer, this is about the PHP EntityView, mainly generating the HTML for the non-JavaScript version.
There could be a SnakView, using a strategy pattern to display different Snak types. In case of a prperty-value Snaks, there would be renderers per DataType/DataValue. Kind of similar to what we have in JavaScript.

What's the status here?

Danwe added a comment.Oct 28 2013, 1:28 PM

@Lydia: This bug is a very early but still pressing description of what we are going to do in the EntityView refactoring I guess. So it is still required but could probably be merged with any other bug describing the EntityView refactoring.

Ok thanks. Closing this one as EntityView is on the radar anyway.