| Lucas_Werkmeister_WMDE created this task. Lucas_Werkmeister_WMDE added projects: Wikidata, Wikibase-Quality, Wikibase-Quality-Constraints. Herald added a subscriber: Aklapper. |
I have some thoughts about ConstraintParameterParser.
Right now, it takes a single string or an array of strings and attempts to parse it into entity IDs. The constraint checkers don’t actually use this – mostly they operate on the strings, and otherwise they parse the entity IDs themselves again – but the result is used in ConstraintParameterRenderer, which renders the constraints into HTML for the special page and for the detailHTML key in the API response.
We want to move all the detail you need into the message itself, so that the detailHTML is no longer needed. I guess this applies to both the report widget on items and the special page. This could make ConstraintParameterRenderer completely obsolete: we should still return the raw parameters, but there’s no need to prettify them in any way if the message is already the pretty format that we show to users.
ConstraintParameterParser also sounds like the natural place to parse constraint parameters that have come from statements (which is a more complex task than the explode( ",", … ) that is currently done for parameters from templates). In change 352865, I’ve put that code into TypeCheckerHelper, but it could be moved into ConstraintParameterParser.
Taken together, this would mean: we could remove ConstraintParameterRenderer and essentially replace ConstraintParameterParser with actual parameter parsing. This would mean removing the rendered parameters from the special page and the API response, which is probably a breaking change that we have to announce, and which also can’t be done until all messages are good enough that the parameters are unnecessary. So I’m unsure about the timing here…
Cc: Jonas, thiemowmde, Lucas_Werkmeister_WMDE, Aklapper, GoranSMilovanovic, QZanden, Izno, Wikidata-bugs, aude, Mbch331
_______________________________________________ Wikidata-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
