On Wed, Feb 4, 2015 at 2:33 AM, Erik Moeller <erik(a)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.
--
Brad Jorsch (Anomie)
Software Engineer
Wikimedia Foundation
