On 05/22/2012 09:47 PM, Daniel Kinzler wrote:
On 22.05.2012 21:27, Gabriel Wicke wrote:
So,
instead of {{{data}}} there would be {{#data:}}, instead of
{{{data.color}}} there would be {{#data:color}}, instead of
{{{data.color(ACME_SURVEY_2010)}}} there would be
{{#data:color|ref=ACME_SURVEY_2010}} and so on.
This could even be simplified further to
{{#data:{{{data_item}}}|color}}
The syntax is admittedly longer, but would work as-is with alternate
parsers such as Parsoid or a generic parser function API in Lua. It
would also preserve referential transparency as far as possible, which
is good for finer-grained caching.
That's pretty much what I was doing with {{#data-value:data.color}}. Turning
that into {{#data-value:{{{data}}}|color}} would actually be fine, though a bit
ugly. Perhaps it would even be nice to turn it around:
{{#property:color|{{{data}}}}}.
Sure, both are fine with me. My concern is more about using the plain
parser function API without magic globals or custom preprocessor behavior.
However, I'd still like to support the plain
template parameter syntax with
pseudo-parameters, e.g. {{{data.color}}} for retrieving the flat wikitext value
of the property.
Do you think that's ok? Or does it introduce complications with respect to Lua, etc?
{{{data.color}}} would be inaccessible to Lua templates, unless it is
expanded as a parameter in a custom preprocessor frame and then passed
by value to the Lua template. The custom preprocessor frame code would
be specific to the current PHP preprocessor, and incompatible with other
parsers.
A parser function call with explicit item parameter on the other hand
would work as-is through the generic API- be it from Lua or Parsoid.
Gabriel