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 :-).
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.
Why use the model attribute? Why would you care about the original model? All
you need to know is that you'll get HTML. Exposing the original model in this
context seems useless if not misleading.
Given that I misunderstood your larger observation about
expandtemplates, this is not relevant now. But, I was basing this on
your proposal from the previous email which I'll now go back to.
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.
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).
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.
Subbu.
A separate property in the JSON/XML structure avoids the need for escaping
(and associated security risks if not done thoroughly), and should be
relatively straightforward to implement and consume.
As explained above, I do not see how this would work except for the very special
case of using expandtemplates to expand just a single template. This could be
solved by introducing a new, single template mode for expandtemplates, e.g.
using expand="Foo|x|y|z" instead of text="{{Foo|x|y|z}}".
Another way would be to use hints the structure returned by generatexml. There,
we have an opportunity to declare a content type for a *part* of the output (or
rather, input).
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
