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