| daniel added a comment. |
In T174032#3990566, @Anomie wrote:What does matter is what changes if any get made in DifferenceEngine.
I don't expect any, since DifferenceEngine is per content model. You'd just have one DifferenceEngine for each slot.
ApiParse has several modes, and MCR only matters when the page parameter is specified.
Wrong. It obviously also matters if pageid or oldid are used.
True. My point was that it doesn't matter if text is given.
And it should also be possible to specify multiple slots explicitly with text parameters.
That would be nice (for ApiParse as well as ApiComparePages), but I'm not sure it's really needed. We do need it for ApiEdit, of course.
In that case, it should be possible to again handle this just like the ApiQueryRevisionsBase case: add a slots parameter, and return output for multiple/all slots if requested, be introducing another level in the result structure.
I can't think of any reasonable method of doing page views where that would make sense for any existing use of action="" Maybe a method that blindly concatenates them in alphabetical order by slot name?
I'm confused - why would you concatenate the output if the slots param is given? I can only
Neither your proposal nor mine works with parsing the slots individually and returning separate HTML blobs for each one. Yours has another layer on top of parsing individual slots that somehow combines them all, while mine only directly parses the main slot and lets other slots either be transcluded or implicitly add themselves like Cite's automatic adding of references if no <references/> was present.
That's both "combining", the question is just what does the combining. But I'D only do any kind of combining if the slots param is not given.
But being able to render non-main slots separately is a requirement in my mind. And I also see no reason not to support that. It seems straight forward.
That leaves the question what exactly should happen if no slots parameter was specified.
The output should be the same HTML blob that is inserted into the skin chrome when viewing a page or is shown inside the <div id="wikiPreview"> when previewing an edit.
Yes - which is "whatever PreparedEdit::getCombinedParserOutput() returns".
If a "slots" parameter affects the output at all, it should most likely behave the same as viewing a non-main slot if we add that ability to the web UI.
Yes, indeed. As I said, I think this is a requirement. This would bypass any "combining" logic external to the ContentHandler, but would not prevent cross-slot access (transclusion) by the ContentHandler (or whatever it uses to generate the ParserOutput, e.g. Parser).
Cc: gerritbot, Aklapper, daniel, Giuliamocci, Adrian1985, Cpaulf30, Lahi, PDrouin-WMF, Gq86, Baloch007, E1presidente, Ramsey-WMF, Cparle, Darkminds3113, SandraF_WMF, Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, Tramullas, Acer, LawExplorer, Lewizho99, Maathavan, Susannaanas, Aschroet, Jane023, Wikidata-bugs, PKM, Base, matthiasmullie, aude, Ricordisamoa, Lydia_Pintscher, Fabrice_Florin, Raymond, Anomie, Steinsplitter, Mbch331
_______________________________________________ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
