Forum:Template output different when passed as parameter

I've had a streak of stupid mistakes lately, but there's no way I'm wrong with this one. (Now watch it turn out that I am...)

I have a template (tests) that finds the date of the next inauguration for a given political office, based on semantic queries. But the semantic features aren't the problem or I would have asked on the Nabble list. If the template's output is passed as a parameter to , it changes...! I'm using identical input and output formats for the parser function, so what goes in should come out. EDIT: I should also mention that I tried directly inputting the date to and it worked.

= January 1, 2012 = January 1, 2009

But it gets weirder; the rules of arithmetic seem to be ignored. 2009 shouldn't be allowed as the year number because it's an odd number. After the semantic queries have been evaluated, the opening condition is like this:

I have no idea how 2009 gets past that condition; even if the second argument were regarded as empty and therefore defaulted to the current year, the condition should return false because (2009 mod 2 != 0).

If this involves too much semantic content, just say so and I'll head over to Nabble. I would just rather not ask them about an ordinary problem, as that's not what the list is for.

Thanks. --Jesdisciple (talk) 03:58, 30 June 2009 (UTC)


 * Alright, I have a minimal test case for this now... And I'm finally right! ...sort of.  Removing the newline in the following code fixes the problem (the linebreak is invisible in the calling page until you view source).  Note that the template is calling itself from outside of its tags.

January 1, 2012


 * So, is this a bug or should I never use newlines for clarity in my templates? --Jesdisciple (talk) 15:55, 30 June 2009 (UTC)


 * I haven't played with your example but your experience reminds me of unwanted newlines I encountered once. Read this: The parser function #if: generates a newline whenever called. I had used numerous  in a particularly complex template and was plagued by unwanted newlines. In the end the only solution was to ensure that any template code using consecutive #if parser functions be written on the one line which is allowed to wrap but not to have any linefeed character.
 * Yes it made the template markup more difficult for the human eye to parse but the rendered output is all that matters in this case, correct? najevi 19:19, 30 June 2009 (UTC)


 * Actually, #if: strips whitespce (including newlines) off teh ends of its parameters; the newline gets inserted if you chain them like so:


 * The solution is to write


 * because now the linebreak is not "outside" in the wikicode, where it propagates, but "inside" the #if: where it gets removed. -- ◄mendel► 22:10, 30 June 2009 (UTC)


 * Najevi: No, I'm being maintenance-minded - so I care how the code will look to the next guy that has to tweak it (or me three months later, for that matter).


 * Mendel: Yes, this is what I had to do in the end with my #ifexpr. I wish wiki syntax didn't lose so much of the expressiveness of PHP...  At least SMW brings some of it back. --Jesdisciple (talk) 22:30, 30 June 2009 (UTC)
 * It may be possible to write a template that removes line breaks from its input. -- ◄mendel► 23:22, 30 June 2009 (UTC)


 * I doubt it... #replace would be the tool for that, but, as a parser function, it will automatically strip leading and trailing whitespace; a lone newline could be considered either or both.  You could surround it with dots or something to set it apart, but that's ugly and not maintainer-friendly.  It just gives something else to know about and pay attention to, and wiki syntax is kinda ugly as it is.


 * I thought about using or  but these have similar problems.


 * What I would really like is something like PHP's  and  .  Code can go anywhere and everywhere - just surround it with small tags - and text is only output from within the tags by explicit command.  If there's a stretch of non-code or the coder prefers wiki syntax as it is right now, fine: Don't use the tags.  But I don't seriously think that will be implemented; it involves designing and documenting a new syntax, and expanding (probably doubling or more) the existing interpreter. --Jesdisciple (talk) 00:23, 1 July 2009 (UTC)