Am 19.05.2014 14:21, schrieb Subramanya Sastry:
On 05/19/2014 04:52 AM, Daniel Kinzler wrote:
I'm getting the impression there is a fundamental misunderstanding here.
You are correct. I completely misunderstood what you said in your last response about expandtemplates. So, the rest of my response to your last email is irrelevant ... and let me reboot :-).
Glad we got that out of the way :)
On 05/17/2014 06:14 PM, Daniel Kinzler wrote:
I think something like <html transclusion="{{T}}" model="whatever">...</html> would work best.
I see what you are getting at here. Parsoid can treat this like a regular tag-extension and send it back to the api=parse endpoint for processing. Except if you provided the full expansion as the content of the html-wrapper in which case the extra api call can be skipped. The extra api call is not really an issue for occasional uses, but on pages with a lot of non-wikitext transclusion uses, this is an extra api call for each such use. I don't have a sense for how common this would be, so maybe that is a premature worry.
I would probably go for always including the expanded HTML for now.
That said, for other clients, this content would be deadweight (if they are going to discard it and go back to the api=parse endpoint anyway or worse send back the entire response to the parser that is going to just discard it after the network transfer).
Yes. There could be an option to omit it. That makes the implementation more complex, but it's doable.
So, looks like there are some conflicting perf. requirements for different clients wrt expandtemplates response here. In that context, at least from a solely parsoid-centric point of view, the new api endpoint 'expand=Foo|x|y|z' you proposed would work well as well.
That seems the cleanest solution for the parsoid use case - however, the implementation is complicated by how parameter substitution works. For HTML based transclusion, it doesn't work at all at the moment - we would need tighter integration with the preprocessor for doing that.
Basically, there would be two cases: convert expand=Foo|x|y|z to {{Foo|x|y|z}} internally an call Parser::preprocess on that, so parameter subsitution is done correctly; or get the HTML from Foo, and discard the parameters. We would have to somehow know in advance which mode to use, handle the appropriate case, and then set the Content-Type header accordingly. Pretty messy...
I think <html transclusion="{{T}}"> is the simplest and most robust solution for now.
-- daniel