On 05/13/2014 05:37 PM, Daniel Kinzler wrote: > Hi all! > > During the hackathon, I worked on a patch that would make it possible for > non-textual content to be included on wikitext pages using the template > syntax. > The idea is that if we have a content handler that e.g. generates awesome > diagrams from JSON data, like the extension Dan Andreescu wrote, we want to be > able to use that output on a wiki page. But until now, that would have > required > the content handler to generate wikitext for the transclusion - not easily > done.
It sounds like this won't work well with current Parsoid. We are using action=expandtemplates for the preprocessing of transclusions, and then parse the contents using Parsoid. The content is finally passed through the sanitizer to keep XSS at bay. This means that HTML returned from the preprocessor needs to be valid in wikitext to avoid being stripped out by the sanitizer. Maybe that's actually possible, but my impression is that you are shooting for something that's closer to the behavior of a tag extension. Those already bypass the sanitizer, so would be less troublesome in the short term. We currently also can't process transclusions independently to HTML, as we still have to support unbalanced templates. We are moving into that direction though, which should also make it easier to support non-wikitext transclusion content. In the longer team, Parsoid will request pre-sanitized and balanced HTML from the content API [1,2] for everything but unbalanced wikitext content [3]. The content API will treat it like any other request, and ask the storage service for the HTML. If that's found, then it is directly returned and no rendering happens. This is going to be the typical and fast case. If there is however no HTML in storage for that revision the content API will just call the renderer service and save the HTML back / return it to clients like Parsoid. So it is important to think of renderers as services, so that they are usable from the content API and Parsoid. For existing PHP code this could even be action=parse, but for new renderers without a need or desire to tie themselves to MediaWiki internals I'd recommend to think of them as their own service. This can also make them more attractive to third party contributors from outside the MediaWiki world, as has for example recently happened with Mathoid. Gabriel [1]: https://www.mediawiki.org/wiki/Requests_for_comment/Content_API [2]: https://github.com/gwicke/restface [3]: We are currently mentoring a GSoC project to collect statistics on issues like unbalanced templates, which should allow us to systematically mark those transclusions by wrapping them in a <domparse> tag in wikitext. All transclusions outside of <domparse> will then be expected to yield stand-alone HTML. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
