I am having trouble understanding correct behaviour with groups and missing dates.
As I understood it, a group
that makes an attempt to render variables which are all empty is supposed to produce nothing: anything it would have rendered en route is to be abandoned.
The first problem I encountered was with an understandably common pattern where a group is defined along these lines
<group>
<choose>
<if variable="issued">
... render date ...
</if>
<else>
<text term="no date"/>
</else>
</choose>
</group>
In one sense that âattemptsâ to render the issued
variable; but obviously it wants to produce the no date
term if that fails, and obviously it should render. OK, I thought, the logic is that there is a flow path within which no attempt was really made to render a date variable: the first conditional fails, so that the only attempt to render anything in the group ends up being a term (not a variable) and therefore the group should print.
I therefore modified the logic of the processor so that it tracks whether any attempt has been made to render a variable (name, number, or other): if no attempt is made then any sort of rendering (including value or text) counts as success; if some attempt is made, then at least one such attempt must have succeeded for the whole group not to be discarded. So effectively groups have three states: âdidnât try to render a variableâ, âtried at least once and always failedâ, and âtried at least once and succeeded at least onceâ. The first and third lead to output, but the second causes the effort to be abandoned. This caters for the problem set out above.
But now consider this (roughly from bugreports_UndefinedStr.txt
), inlining a macro
<group delimiter="; ">
<choose>
<if variable="issued">
.. render date ..
</if>
<else>
.. print "no date" term ..
</else>
</choose>
<text variable="foo" />
</group>
Now in this case the group certainly does attempt to render at least one variable (foo
) which (let us suppose) fails. Clearly it is supposed to print the no date
term, as the test result shows. But what is the logic of this? That term is not a variable, and it doesnât print it as part of rendering a variable, but indeed because there isnât a variable to render. So, it looks as if this is a group that does attempt to render at least one variable, but fails.
My processor is religiously following instructions, and declining to print anything so long at the second <text variable/>
is in the group
: it (correctly I suppose, in a stupid computer sense of the term correct) sees this as if it were the same as
<group>
<text term="foo-term" suffix=": "/>
<text variable="foo"/>
</group>
Which, as I understand it, should not produce any output if foo
is empty.
Clearly this is silly in human terms, though it has a plausible justification in strict logic; but exactly how do I adjust the logic to make it common sense? There seem to be four possibilities (maybe more I havenât thought of):
- Treat
choose
as if it were a variable so if it prints something then that counts as âsuccessâ sufficient to warrant printing the group. - Treat the
no date
term as a special case - Treat a
term
as if it were avariable
. - Treat any output other than prefixes and suffixes as âsuccessâ.
- As previous, but only if the output precedes the attempt to render a variable.
As far as I can see the third to fifth options are wrong: if I move the logic in this direction I end up with previously passing tests starting to fail, for reasons that make sense to me, because terms and so forth will often be wanted iff there is some variable printed to which they relate. Iâm tempted by the first, as the most general, but Iâd like to do the right thing here, and since tracking success involves quite a bit of weaving values through multiple levels, Iâd sooner do it better once than work by trial and error.