Page MenuHomePhabricator

[Task] Apply property ordering in EntityView
Closed, ResolvedPublic

Description

The property ordering has been tried out with a gadget. It seems to be working fine. We should implement that in the main codebase now and upgrade it from the gadget.

Related Objects

View Standalone Graph
This task is connected to more than 200 other tasks. Only direct parents and subtasks are shown here. Use View Standalone Graph to show more of the graph.

Event Timeline

The current order is in http://www.wikidata.org/wiki/MediaWiki:Wikibase-SortedProperties.

These are the formats I want a parser (the current one is in WikiTextPropertyOrderProvider) to accept:

== Have sections (they are just ignored) ==
* P1
* P1 (foo)
* [[Property:P1]]
* [[Property:P1|P1]]
* [[d:Property:P1|P1]]
* {{P|1}}
* {{P|P1}}

Things I find critical:

  • Add much more test cases to the parser (see the list of formats above) and make is as robust as possible. But don't make it to "clever". It should behave in a way that's easy to understand.
  • Write documentation for this parser.
  • Do some benchmarking to make sure the re-ordering succeeds in a few milliseconds, and there are no worst cases.
  • What happens is the parser entirely fails and returns an empty list? Is there a way we can make the community aware of such a situation?
  • All code should be robust and work just fine when there is no order (null or an empty array) for some reason.
  • The caching is fine as far as I can tell. See CachingPropertyOrderProvider.

@Lydia_Pintscher: As discussed, support for overriding the order in ArticlePlaceholder on each local wiki should be tracked in a separate ticket.

Input based on today's meeting:

  • documentation of format is needed
  • when input for the parser is garbage just returning an empty list of properties
  • when the list is empty return the statements in unordered order
  • separating the statements into section comes first. Then we sort the statements within a section.
  • We will start with just the syntax that the ArticlePlaceholder currently supports. We can add more later.
  • Later: support prefixed IDs for federation
  • Properties that are not in the list go to the bottom.
  • Use the same list for now for qualifiers and references. If this causes problems we can switch to a different list for the later but that really shouldn't be necessary.

Assumptions about how the ArticlePlaceholder does it:

  • parser checks at the beginning of the line and ignores everything after the ID
  • parser only parses lines starting with a star and ignores the rest
  • parser strips any comments before processing lines

If there is anything missing for this to be picked up next week please comment.

Change 326986 had a related patch set uploaded (by Thiemo Mättig (WMDE)):
Fix PropertyOrderProvider type hint in top level factory

https://gerrit.wikimedia.org/r/326986

Change 327001 had a related patch set uploaded (by Thiemo Mättig (WMDE)):
Apply property ordering in StatementGroupListView

https://gerrit.wikimedia.org/r/327001

Change 326986 merged by jenkins-bot:
Fix PropertyOrderProvider type hint in top level factory

https://gerrit.wikimedia.org/r/326986

Change 327001 merged by jenkins-bot:
Apply property ordering in StatementGroupListView

https://gerrit.wikimedia.org/r/327001

thiemowmde removed a project: Patch-For-Review.
thiemowmde moved this task from Review to Done on the Wikidata-Former-Sprint-Board board.

Works fine, better than expected. I think it's good that statements only display in an re-ordered way once the page reloaded.

Good work. Thanks!

Receiving comments like this on a closed ticket is rare. Thank you very much, @Esc3300! \o/

Change 334343 had a related patch set uploaded (by Thiemo Mättig (WMDE)):
Fix minor pattern matching issues in WikiTextPropertyOrderProvider

https://gerrit.wikimedia.org/r/334343

Change 334343 merged by jenkins-bot:
Fix minor pattern matching issues in WikiTextPropertyOrderProvider

https://gerrit.wikimedia.org/r/334343