2009/6/26 Stephen Bain <stephen.b...@gmail.com>:
> In the good old days someone would have solved the same problem by
> mentioning in the template's documentation that the parameter should
> use full URLs. Both the template and instances of it would be
> readable.
>
> Template programmers are not going to create accessible templates
> because they have a programming mindset, and set out to solve
> problems in ways like Brian's code above.
>
Maybe it's the mindset that should be changed then? For one thing,
{{link}} used to use {{substr}} to check if the first argument started
with http:// , https:// or ftp:// and produced an internal link if
not, despite the fact that the documentation for {{link}} clearly
states that it creates an *external* link, which means people
shouldn't be using it to create internal links. If people try to use a
template for something it's not intended for, they should be told to
use a different template; currently, it seems like the template is
just extended with new functionality, leading unnecessary {{#if: ,
{{#switch: and {{substr}} uses that serve only the users' laziness.
To get back to {{cite}}: the template itself contains no more than
some logic to choose between {{Citation/core}} and {{Citation/patent}}
based on the presence/absence of certain parameters, and
{{Citation/core}} does the same thing to choose between books and
periodicals. What's wrong with breaking up this template in, say,
{{cite patent}}, {{cite book}} and {{cite periodical}}? Similarly,
other multifunctional templates could be broken up as well.
The reason I believe breaking up templates improves performance is
this: they're typically of the form
{{#if:{{{someparam|}}}|{{foo}}|{{bar}}}} . The preprocessor will see
that this is a parser function call with three arguments, and expand
all three of them before it runs the #if hook. This means both {{foo}}
and {{bar}} get expanded, one of which in vain. Of course this is even
worse for complex systems of nested #if/#ifeq statements and/or
#switch statements, in which every possible 'code' path is evaluated
before a decision is made. In practice, this means that for every call
to {{cite}}, which seems to have three major modes, the preprocessor
will spend about 2/3 of its time expanding stuff it's gonna throw away
anyway.
To fix this, control flow parser functions such as #if could be put in
a special class of parser functions that take their arguments
unexpanded. They could then call the parser to expand their first
argument and return a value based on that. Whether these functions are
expected to return expanded or unexpanded wikitext doesn't really
matter from a performance standpoint. (Disclaimer: I'm hardly a parser
expert, Tim is; he should of course be the judge of the feasibility of
this proposal.)
As an aside, lazy evaluation of #if statements would also improve
performance for stuff like:
{{#if:{{{param1|}}}|Do something with param1
{{#if:{{{param2|}}}|Do something with param2
...
{{#if:{{{param9|}}}|Do something with param9}}}}}}}}}}}}}}}}}}
Roan Kattouw (Catrope)
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
