Forum:UsingData and transclusion boilerplates
(This topic is archived. Please do not edit this page!)
If you've ever edited an item page, you may have noticed syntax similar to the following, though perhaps with less obvious formatting:
<onlyinclude>{{ {{{tpl|Tooltip}}}
|mode={{{mode|}}}
|arg={{{arg|}}}
...
}}</onlyinclude>
This is, essentially, boilerplate code used to make data stored on those pages accessible by various templates -- in case of items, it is used by templates like {{itembox}} or {{item}} to allow editors to not have to worry about things like item quality or icon names. Variations of this syntax also exist on achievements and profession skill pages.
There are two problems here: the boilerplate is rather unwieldy (which is somewhat mitigated by the use of article boilerplates), and it blocks meaningful transclusion of item pages, which prevents us from creating unified pages for things like alliance/horde versions of the same trade skill recipe, in a fashion similar to how we now handle alliance/horde versions of some quests. The core of the issue is that we're using onlyinclude and some template expansion hackery to store and retrieve data related to the page.
I'd like to address these by moving the data storage and transclusion to a slightly different mechanism: parser functions. I have three specific ones in mind:
{{#data:TemplateName|...}}- Output is equivalent to {{TemplateName|...}}, but named arguments in ... can be used in other articles (or templates) using the following two functions (tags).
- #data tags can only be placed directly on the associated page: when transcluded, they still produce template output, but their named arguments are will not be associated with the page.
{{#using:Page|TemplateA|TemplateB|...}}- If there is a #data tag on Page, the output is equivalent to {{TemplateA|...}} being passed all of the named arguments inside Page's #data tag and
.... If there is no #data tag on Page, the output is equivalent to {{TemplateB|...}}, where ... are the named arguments in the #using tag. {{#usingarg:Page|ArgName|DefaultValue}}- If there is an ArgName named parameter inside a #data tag on Page, the output is the associated value; otherwise, the output is DefaultValue.
The latter two tags are primarily intended to appear in templates; while #data replaces the above boilerplate code:
{{#data:Tooltip
...
}}
seems like a much simpler thing to put on pages.
The extension enabling those tags is currently live; you can see some in-action examples on Project:Sandbox/1, Project:Sandbox/2 (at least while sandboxes last :P). I'm interested in any comments or questions you might have regarding this, as well as any potentially broken corner cases with the current implementation -- feel free to experiment with it in the sandboxes. Actually deploying it for use in articles is a story for another day -- as that'd require rather sweeping changes to our templates.
— foxlit (talk) 21:45, 14 January 2011 (UTC)
- Obviously SMW would be preferred, but that seems to break the wiki. A few of these functions look like they're emulating a few of the parsers found in SMW; I wonder if it would be possible to name and "function" them similarly (if we should ever have the opportunity of using SMW again...). If not, I should think better (er, semantic?) names would be preferable for the parserfunctions, though I'm not sure if I could come up with any...
- On a different note, I would suggest moving the "..." to the first parameter of #using, as that's common to both templateA and templateB cases (compare with #ifeq and a few others). --Sky (talk) 17:04, 17 January 2011 (UTC)