2009/6/26 Stephen Bain stephen.bain@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)