[jrauh01]

CheckboxElement derived two things eagerly in setValue(): it resolved a boolean value into a string, and it computed the checked flag. Both depend on checkedValue/uncheckedValue, which may not be set yet. Attributes::set() invokes setter callbacks immediately, in the order the attributes are given. So whichever attribute came first won:

// renders checked
new CheckboxElement('test', ['checkedValue' => 'a', 'uncheckedValue' => 'b', 'value' => 'a']);

// renders unchecked
new CheckboxElement('test', ['value' => 'a', 'checkedValue' => 'a', 'uncheckedValue' => 'b']);

The case reported in #140 is not the only one. With 'checkedValue' => 'a' and 'uncheckedValue' => 'b':

• 'value' => true set before checkedValue stores the default 'y' instead of 'a'. It renders as checked either way, so the mismatch only surfaces in getValue() and in hasValue(), which then reports false for a visibly checked box.
• 'value' => false set before uncheckedValue stores 'n' instead of 'b', the same silent mismatch.
• 'value' => 'b' is order-independent by accident: 'b' matches neither the default 'y' nor 'a', so the stale comparison happens to yield the correct unchecked state.
• 'checked' => true never consulted the checked value at all, which left the element checked while getValue() returned null.

The boolean cases corrupt getValue() and hasValue() even where the checkbox happens to render correctly, so guarding setCheckedValue() alone would not have been enough.

Changes

The value is now the only state a checkbox keeps, and everything else is derived from it on read:

• getValue() resolves a boolean value to the checked or unchecked value
• isChecked() compares getValue() with getCheckedValue()
• setChecked() sets the value instead of a separate flag
• hasValue() delegates to isChecked()
• the checked property is gone

After the change, all five scenarios above yield a single outcome across every attribute ordering.

Changes in behavior

setChecked() and the checked attribute now set the element's value. A checkbox that is checked without having been submitted therefore has a value: getValue() returns the checked value instead of null, and a checkbox that is both required and checked passes validation instead of failing with "This field is required."

fix #140

[lippserd]

Please clear $this->valid in setCheckedValue() and setUncheckedValue(). These setters can now change the effective value without invalidating its cached validation result.

I reproduced this with value => true and a callback validator that accepts only 'y'. Initial validation passes. Calling setCheckedValue('a') changes the value to 'a'. isValid() still returns true. An explicit validate() call correctly rejects the new value. Before this change, the same sequence retained the validated value 'y'.

Add regression tests that validate the checkbox before changing a mapping. The next isValid() call should validate the new value automatically. Test that a valid checkbox becomes invalid after the mapping changes. Also test that an invalid checkbox becomes valid.

[jrauh01]

$this->valid is now set to null in both methods. I've added three tests about it.