Topic on Talk:Parsoid/Extension API

Filed https://phabricator.wikimedia.org/T347507 for this feature request

Is there a way to, within a tag handler, access parameters passed to the template the tag is in? This was possible in the legacy parser as the template's frame was passed around. However, in Parsoid it seems a legacy tag handler receives a general (or a "fake"?) frame with no arguments access, and an extension tag handler doesn't seem to have any methods to do so.

No, right now, there isn't. We never did because it was never needed in all the use cases we were working on so far. What extension are you working on right now where this is used? But, we can look into it and see what we can expose.

The way that Scribunto modules and extensions can crawl the parse frame and use stuff from parent contexts always seemed vaguely like a misfeature to us. It makes reusing page fragments and tracking dependencies between them very difficult, and seems to have been mostly used in kludgey workarounds like T331906. My current thinking about the issue is at T122934#9196348; the tl;dr is that we should have a "data context" for every page which can be *explicitly* passed into subpages/templates where needed, but that we should *not* recreate the ability to implicitly crawl the frame.

I've been considering porting PortableInfobox onto Parsoid.

The extension adds a (legacy) <infobox> tag, whose contents are custom XML nodes that describe the infobox's composition and inputs - an example template may look like this:

<infobox layout="tabular">
	<title source="name">
		<default>{{PAGENAME}}</default>
	</title>
	<image source="image">
		<caption source="caption" />
	</image>
	<data source="role">
		<label>Role</label>
	</data>
	<data source="cost">
		<label>Unlock requirements</label>
		<default>0/Unplayable[[Category:Unplayable aircraft]]</default>
		<format>{{{cost}}} credits/prestige</format>
	</data>
</infobox>

Each source attribute is the parameter from which a row draws data: the "Role" row draws its value from the {{{role|}}} parameter, the image draws its file from {{{image|}}} and caption from {{{caption|}}}, and so on. The only "direct" reference to a parameter in this snippet is in the "Unlock requirements" row (which draws from {{{cost}}} via the format, but only if the parameter is not empty when the data node is evaluated).

Naturally, given those parameters aren't delivered explicitly this approach does not work at all when rendering with Parsoid. If I'm not mistaken, this relies on immediate PPTemplateFrame_Hash's getArguments output.

I do agree that, if this had been a parser function and not a tag, drawing those arguments from seemingly nowhere is, to keep this reply short, bad. But this case is more of an alternative reference format rather than drawing data from nowhere, given all attributes are (explicitly) linked through the source attributes and default/format nodes.

Ya, I can see how this might be useful for this use case. We may not get to this right away since we are currently focused on having Parsoid read views for wikimedia wikis complete, but I'll file a phab task and we'll get to this. This information will likely be exposed via the ParsoidExtensionAPI object -- the specific details of how this is implemented will need to factor in considerations that Scott raises. This new API method will not let you crawl the frame but can give access to the enclosing template parameter strings where applicable.

Albeit cumbersome, the above would probably work with {{#tag:infobox|...}} in the template.