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
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
