On Wed, Feb 4, 2015 at 2:33 AM, Erik Moeller erik@wikimedia.org wrote:
If not, then I think one thing to keep in mind is how to organize the transformation code in a manner that it doesn't just become a server-side hodgepodge still only useful to one consumer, to avoid some of the pitfalls Brian mentions.
I think the MobileFrontend extension has probably run into these pitfalls already.
Say you want to reformat infoboxes on the mobile web, but not do all the other stuff the mobile app does. Can you just get that specific transformation? Are some transformations dependent on others? Or say we want to make a change only for the output that gets fed into the PDF generator, but not for any other outputs. Can we do that?
Maybe what we really need is a way to register transformation classes (e.g. something like $wgAPIModules). Then have ApiParse have a parameter to select transformations and apply them to wikitext before and to HTML after calling the parser. And we'd probably want to do the wikitext-before bit in ApiExpandTemplates too, and add a new action that takes HTML and applies only the HTML-after transforms to it.
Or we could go as far as giving ParserOptions (or the ParserEnvironment I recently heard Tim propose) a list of transformations, to allow for transformations at some of the points where we have parser hooks. Although that would probably cause problems for Parsoid.