WeBWorK Main Forum

parserRadioButtons.pl - order (last, first) and checked.

parserRadioButtons.pl - order (last, first) and checked.

by William Boshuck -
Number of replies: 3
I noticed some curious (to me) behaviour of
the objects created by parserRadioButtons.pl:
if I specify order then I get spanked for specifying
checked - it looks like I get spanked by the following
clause (in orderedChoices)

Value::Error("Item $i of the 'order' option was already specified.")
if not exists $remainingChoices{$label};

because $label is really "%$label" at this point. (I can
produce the same behaviour if checked is among either
first or last.)

I can work around this by changing the code in the
problem, or I can work around it by replacing the
foregoing clause by

Value::Error("Item $i of the 'last' option was already specified.")
if not (exists $remainingChoices{$label} or exists remainingChoices{"%$label"});
$label = (exists $remainingChoices{"%$label"} ? "%$label" : $label);

(which I'd need to do in three places; one for each of order,
first and last).

Below is a little file that illustrates the behaviour. Is this intended





$radio = RadioButtons([
'This is the first choice.',
'This is the second choice.',
'This is the third choice.',
'This is the fourth choice.',
'This is the fifth choice.'], 4,
labels => [1, 2, 3, 4, 5],
#labels => "123",
order => [1, 2, 3, 4, 5],
#order => [0, 1, 2, 3, 4],
checked => '1'

Select one of the following.
(Just click on 'Submit Answers' if
your choice is already selected.)
\{ $radio->buttons \}


In reply to William Boshuck

Re: parserRadioButtons.pl - order (last, first) and checked.

by Davide Cervone -
Thanks for the error report. You are correct that the percent signs in the keys of the choiceHash (which get copied to the remainingChoices hash) are the problem. I think the solution is really not to put the percent signs on the keys until the end of the orderedChoices routine, since they are needed only for the ans_radio_buttons() macro. That simplifies the code, and puts the percents in only when they are really needed.

I have modified the version in the CVS repository. See if that doesn't take care of things for you.


PS, the order => [0,1,2,3,4] option still produces an error message about the first item being used twice. That's because the values in the order array can be either indices into the answer array or labels from the labels array (with the later taking precedence). In this case, the labels are also numbers, so there is an ambiguity. Since 0 is not one of the labels, it references the 0th (i.e., first) answer in the array; but since 1 is a label, that is used as a label reference rather than an index, and the label '1' also refers to the first answer. So both 0 and 1 reference the same answer. There is no easy way around this but to use the (numeric) labels throughout.
In reply to Davide Cervone

Re: parserRadioButtons.pl - order (last, first) and checked.

by William Boshuck -
Yes, that part (combining order, first or last and checked)
works fine (and I am a little relieved to see the demise of
$noChecked, whose purpose I didn't quite get).

Thanks for that, and for confirming what I suspected about
order => [0, 1, 2, 3, 4]. If I drop the labels then that order
option works, of course, but only if I shorten the choices so
that makeLabels produces distinct labels or increase
maxLabelSize. (In the case at hand, each label generated
by makeLabel is 'This ... choice.') I don't know if that
counts as a bug. On one hand, the student can see which
choice they've selected by looking at the radio buttons. On
the other hand I can see why it is better to have distinct items
in the results table for different choices, not to mention that
it looks like the checker will compare labels and not choices
(the latter are never made into String objects, as far as I can

Thank you for all of your help and explanations.

In reply to William Boshuck

Re: parserRadioButtons.pl - order (last, first) and checked.

by Davide Cervone -
I hadn't considered the case where the shortened labels would not be distinct (or perhaps I did and expected you would provide your own more meaningful ones that were still short, but distinct). I don't remember.

In any case, I would (and did) consider it a bug, and so have fixed it. Just as putting the percent sign into the labels too early was a mistake, shortening the labels too early is also a mistake. So I've remove the makeLabel() call from choiceHash() and added a postprocessor for the answer checker that shortens the student's response. Since we only did that as a means of preventing the answer and answer preview from being too large anyway, that is a better way to handle it in any case. I renamed the routine labelText() since "makeLabel" wasn't really appropriate anymore.

Anyway, check out the new version in the CVS repository.


PS, the reason for $noCheck was to prevent the percent signs from being inserted when making the list of labels to use as strings to add to the String context. It was a symptom of having included the percent signs too early, and should have been a warning sign that there was a design flaw. As I recall, I wrote the radio button object pretty fast, and so maybe didn't think everything through so well.