inconsistency in multiple choice macros

[Alex-Jordan]

We have a consistency issue with how the various multiple choice answer types handle when an index is used to specify the answer, and that index number happens to be one of the actual listed answers.

• With RadioButtons and CheckboxList, using an index to specify the answer, it will always be interpreted as an index.
• With PopUp, using an index to specify the answer, if that index is among the list of answers, it will be interpreted as that answer, not an index.
• With RadioMultiAnswer, it only makes sense to have the answer declaration be interpreted as an index.

What do we want the standard to be? And then we should make it consistent across those first three. And we need to update POD accordingly. (With PopUp, this issue is not currently discussed at all in the documentation.)

[Alex-Jordan]

Here is a sample problem to demonstrate the issue.

DOCUMENT();

loadMacros(qw(
    PGstandard.pl PGML.pl parserPopUp.pl parserRadioButtons.pl parserCheckboxList.pl parserRadioMultiAnswer.pl
));

@a = (3,2,1,0);

$d = DropDown([@a], 3);
$r = RadioButtons([@a], 3);
$c = CheckboxList([@a], [3]);
$rma = RadioMultiAnswer([map{[$_]}(@a)], 3);

BEGIN_PGML

[_]{$d}
[_]{$r}
[_]{$c}
[_]{$rma}

END_PGML

ENDDOCUMENT();

[Alex-Jordan]

One thing I think we should do regardless of settling on consistent default behavior, is give a way for authors to declare that they actually want the other behavior. So I propose:

1. We make PopUp behave like the others: when the answer is specified as a number, and that number is small enough to make sense as an index, then it is interpreted as an index.
2. For DropDown, RadioButtons, CheckboxList, we add an option you can pass, like literal => 1. So for example when "0" is the fourth answer, specifying "0" as an answer with literal => 1 would make the macro understand that the fourth answer is the correct answer. Instead of thinking the 0th index answer is the correct one.
3. Not sure how CheckboxList works right now, but we should make sure that if any of the specified correct answers fails to be a valid index, then all of the specified answers are interpreted as literal. Because why would someone mix indices and literal answers?

[Alex-Jordan]

I am working on a branch that updates parserPopUp.pl similar to how @drgrice1 updated parserRadioButtons.pl. It is necessarily different because with HTML select options, there is no HTML label element for each option (like there is for each radio button). Instead the HTML option element has a value attribute and a label attribute. The text inside the option is sort of irrelevant, except that it is the fallback for value and label when either is missing.

[Alex-Jordan]

Now there is consistency.