On 05/17/2014 06:14 PM, Daniel Kinzler wrote:
Am 17.05.2014 17:57, schrieb Subramanya Sastry:
On 05/17/2014 10:51 AM, Subramanya Sastry wrote:
So, going back to your original implementation, here are at least 3 ways I see
this working:

2. action=expandtemplates returns a <html>...</html> for the expansion of
{{T}}, but also provides an additional API response header that tells Parsoid
that T was a special content model page and that the raw HTML that it received
should not be sanitized.
Actually, the <html></html> wrapper is not even required here since the new API
response header (for example, X-Content-Model: HTML) is sufficient to know what
to do with the response body.
  But that would only work if {{T}} was the whole text that was being expanded 
(I
guess that's what you do with parsoid, right? Took me a minute to realize that).
expandtemplates operates on full wikitext. If the input is something like

   == Foo ==
   {{T}}

   [[Category:Bla}}

Then expanding {{T}} without a wrapper and pretending the result was HTML would
just be wrong.

Parsoid handles this correctly. We have mechanisms for injecting HTML as well as wikitext into the toplevel page. For example, tag extensions currently return fully expanded html (we use action=parse API endpoint) and we inject that HTML into the page. So, consider this wikitext for page P.

== Foo ==
{{wikitext-transclusion}}
  *a1
<map ..> ... </map>
  *a2
{{T}} (the html-content-model-transclusion)
  *a3

Parsoid gets wikitext from the API for {{wikitext-transclusion}}, parses it and injects the tokens into the P's content. Parsoid gets HTML from the API for <map..>...</map> and injects the HTML into the not-fully-processed wikitext of P (by adding an appropriate token wrapper). So, if {{T}} returns HTML (i.e. the MW API lets Parsoid know that it is HTML), Parsoid can inject the HTML into the not-fully-processed wikitext and ensure that the final output comes out right (in this case, the HTML from both the map extension and {{T}} would not get sanitized as it should be).

Does that help explain why we said we don't need the html wrapper?

All that said, if you want to provide the wrapper with <html model="whatever" ....>fully-expanded-HTML</html>, we can handle that as well. We'll use the model attribute of the wrapper, discard the wrapper and use the contents in our pipeline.

So, model information either as an attribute on the wrapper, api response header, or a property in the JSON/XML response structure would all work for us. I don't have clarity on which of these three is the best mechanism for providing the template-page content-model information to clients .. so till such time I understand that better, I dont have an opinion about the specific mechanism. However, in his previous message, Gabriel indicated that a property in the JSON/XML response structure might work better for multi-part responses.

Subbu.

Regarding trusting the output: MediaWiki core trusts the generated HTML for
direct output. It's no different from the HTML generated by e.g. special pages
in that regard.

I think something like <html transclusion="{{T}}" model="whatever">...</html>
would work best.

-- daniel

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Reply via email to