On 22.05.2012 15:15, Nikola Smolenski wrote:
Including Items in an Article:
{{#data-template:Infobox
|data_item=q332211
|data_param=stuff
|foo=some value
|stuff.color=green
}}
I see no reason for creating a new parser function for inclusion of templates.
Basically, we need a way to pass a complex data object as a parameter to a
template. If we don't have that, we have two alternative choices:
1) assign per-page variables to items, e.g. make {{{thingy}}} available in the
article after a call to {{#load-data|thingy}}. Then you can use
{{Infobox|data={{{thingy}}}}}, as usual. But I think this "global variables"
approach is ugly and confusing, at least when stuff is loaded from inside templates.
2) alternatively, don't pass item from the article to the template at all.
Instead, use parser functions for every access to an item property, and specify
the item id as a parameter if necessary. That would create a lot of rundundancy
and wouldn't allow "normal" template parameter syntax to be used to access
data
properties.
To me, this seems natural, because it behaves like a function call. Being able
to pass complex objects as parameters directly would of course be better still.
Actually, if the template in question wants to pass the data object on to
another template, we kind of need this...
Also, this syntax would not allow a template to draw
data from more than one
item
Correct. This could be simple enough to overcome, though I can't think of a
*nice* way off hand. Off the top of my head, I'd do something like this:
...
|data_item_2=q556677
|data_param_2=other_stuff
|data_item_3=q114488
|data_param_3=more_stuff
...
or even:
|data_item=q332211 as stuff
|data_item_2=q556677 as other_stuff
|data_item_3=q114488 as more_stuff
which would probably be a requirement in phase3.
No, it's not. phase3 is about automatic listings, which require a different
syntax anyway. Also, in a list, all items would use the same template and the
same rendering options. No need for the ability to pass multiple items to a
single template.
Rather, I would include a template normally and use a
parser function within the
template to access the data.
So, that would be option (2) from above.
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.
How would you specify which item {{#data:}} refers to, in case it's not the
articles "default" item? How would you pass multiple items to a template?
One advantage is that commonly used syntax is always
used, instead of inventing
new syntax (as for the reference in this example).
For the most part, I tried to keep the normal syntax for template parameters,
just introducing structured names (dots and colons). The syntax for
selection-by-reference-id is indeed a bit awkward. Perhaps we can just drop it.
If this is needed, one can always use the {{#data-value}} function with
source=ACME_SURVEY_2010 (perhaps 'ref' is better than 'source').
Another advantage, this way would make data usable
directly in article text, if
that is wanted.
Yes, that's also something that is bothering me. I would propose for this case
to implement option (1) from above: use {{#load-data|stuff}} to make the item
available as {{{stuff}}} in the current scope (preprocessor frame).
That's kind of like saying "pass the item to me" instead of "pass the
item to
the template".
The parser function should be able to override itself
by template parameters - I
believe it is possible to do this.
That makes the hair in my neck stand up :)
Unrelated to the above,
"This will return the value of the color property, in the page's content
language, as plain text."
I see that there is need to also select desired content language (for example, a
lot of infoboxes display name of the topic in the content language and in the
topic's language(s)). This has the potential to introduce additional problems,
of course.
The parameter syntax is the simply way to access property values. For all fancy
needs, like picking the language, use {{#data-value}} instead. Basically, the
{{{data.foo}}} syntax is just a shorthand for the more powerful {{#data-value}}
stuff.
Except that it's not wrapped in any HTML. Perhaps there should be an option to
{{#data-value}} to turn that off completely, using form=plain or some such.
form
Specifies in what form rendered, that is, in which HTML element the value
should be wrapped.
span: wrap in <span> tags, use <span> tags for parts
div: wrap in <div> tags, use <span> tags for parts
li: wrap in <li> tags, use <span> tags for parts
I don't like this at all, since it limits the number of possibilities,
introduces yet another syntax parallel to HTML.
Yet, I don't see anything much better. A half-baked idea is to leave it to the
client wikis to create their data display templates that could be used to format
data appropriately.
Yes, this is kind of a nasty compromise.
On the one hand, it would be extremely cumbersome to have to re-implement the
table (and other) structures for representing property values with various
qualifiers, not to speak of the rendering logic for these qualifiers themselves.
On the other hand, we want to allow template authors to integrate property
values in different kinds of structures, like tables and lists.
Note that with the help of the show=... parameters, template authors can still
implement their own rendering of the value (or rather, statement) with all it's
parts, using one {{#data-value}} call for each one.
(I see Jérémie's email now, and see that we came independently to some of the
same conclusions :) )
{{#data-values}}:
But this is of course an even worse problem.
{{#data-link:data|the data item}}
Why not the usual interwiki syntax of [[wikidata:data|the data item]]?
because "data" is not an identifier for that item on the wikidata repo. YOu
would have to use something like:
[[wikidata:/id/{{{data.id}}}|the data item]]
But constructing edit links this way is very cumbersome. The main intend for
this function is to make it easy to provide an edit link in the infobox.
But perhaps a different syntax should be used for this. After all, the edit link
would, with javascript enabled, not really be a link, but a button to activate
the on-site editing feature.
Thanks for your comments!
-- daniel
--
Daniel Kinzler, Softwarearchitekt
Wikimedia Deutschland e.V. | Eisenacher Straße 2 | 10777 Berlin
http://wikimedia.de | Tel. (030) 219 158 260
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt
für Körperschaften I Berlin, Steuernummer 27/681/51985.