Does $A('.classname').invoke('setValue',...) work on checkboxes?

[Szymon Wilkołazki]

Hi,

I just bumped into a weird bug in my code.
The thing is, that I am trying to update value of several checkboxes
with a value received in a result of ajax call.

Anyway, I have following construction:

<input name="someName" class="APP_CHANGELOG_LOG_ID" value=""
type="checkbox"/>

The checkboxes are unchecked by default.

In the script I do:

$$('.APP_CHANGELOG_LOG_ID').invoke('setValue',111);

But the values stays intact.

If I do this this way, it works:

$$('.APP_CHANGELOG_LOG_ID').each(
function(checkbox) {
checkbox.value = 112
});

Is it me, or the setValue does not work on checkboxes?
I just tried to do simple:

$('publishChangelogSvn').setValue(111);

in Firebug console, where publishChangelogSvn is a checkbox. It does
not matter if it is checked or not. It just do not set the value.

Docs does not mention anything about checkboxes...
http://api.prototypejs.org/dom/form/element.html#setvalue-class_method

Working with prototype 1.6.1.

Do you have had the same issue?

Best Regards
SWilk

[Szymon Wilkołazki]

Hi,

I found where is the problem.

I assumed, that the Form.Element.setValue method sets the value of an
element.

In case of checkboxes that is not true.
The method changes the state of checked/unchecked instead, and leaves
the value attribute unchanged.

The example might be found here:

http://tsalarioth.art.pl/~sw/setValueTest.html

As you can see, if you click on the button "set value of checkbox to:
" with empty input, the checkbox is unchecked. If the value is not
empty, then checkbox will be checked.

I do not understand why this behaviour was chosen, but I understand
that it can't be changed now, as it would break backward compatibility.

Anyway I think the setValue method needs better documentation, as it
is now a little bit misleading.

I will open a lighthouse DOC ticket for this.

Best regards,
SWilk

[joe t.]

i agree on that. setValue has its purpose pretty much in the name.
"Set" the "value" of a control. For checkboxes, "setChecked
(bool)" (also applying to radios?) would have made a lot more sense.

i suppose in the meantime there's Element.writeAttribute
({"value":"foo"});

However, i raise caution on that because i've had inconsistent results
in the past where the DOM recognizes the attribute as changed, but the
browser did not update the visual display of the value (text inputs at
the time), and submitted the original value. It was as though the
input tag's "value" attribute and the control's value property were
different entities. The only way i found to address it was $
('element').value = "foo"; which obviously kills the elegance of
chaining methods, but seems to address both "entities", and is how
Form.Element.Serializers returns other values.

-joe t.

[Szymon Wilkołazki]

joe t. wrote:
> i agree on that. setValue has its purpose pretty much in the name.
> "Set" the "value" of a control. For checkboxes, "setChecked
> (bool)" (also applying to radios?) would have made a lot more sense.
>

Yes, it does apply to radios to. It's a shame that the docs aren't
clear on this behavior.

You can play a little with this test page:
http://tsalarioth.art.pl/~sw/setValueTest.html

I personally think it would be better if setValue on radio and
checkbox either really set the value, or set the checked state base on
comparison:

Element.setValue = function(element, newValue) {
$(element).checked = ($(element).value == newValue);
}

This way, you could check or uncheck the element, especially radio,
based on that if value is matching. This would be useful for methods
similar to Form.unserialize();

It is of course impossible to be done at this state of the library,
where the code is used in (hundreds of) thousands of scripts among the
web.

I will probably write additional method for my needs with use of the
excellent Element.extend method.

Anyway,
I want to thank all the prototype.js developers, doc writers and
supporters for your work on the library. Great job!

Best regards,
SWilk