Simon, indeed the bean is request-scoped and yes, uiCheckedSelector is initialized to false. But this is quite normal AFAIK. I would expect that the update model phase should properly set the value to true, if coming from a page where the checkbox was checked. Then it should notice that value has changed and fire an event.
The debugger sequence after checking is:

- isUiCheckedSelector();   // returns false
- checkedChanged();     //  ==> event
- setUiCheckedSelector(true);
- isUiCheckedSelector();   // rendering: returns true

while after unckecking is:

- isUiCheckedSelector();   // returns false
- setUiCheckedSelector(false);
- isUiCheckedSelector();   // rendering, returns false

Ok, setting immediate to "true" was a mistake in this context (to get the model properly updated), but even after removing it nothing changed. Indeed, it seems that a decision about event firing occurs *before* updating the model, thus using always model defaults for comparison.

-- Renzo


Simon Kitching wrote:
Hi Renzo,

My guess is that on postback, calling resultBean.getUiCheckedSelector() is always returning false. Because of this, if the chekcbox value being posted from the browser is "true" (checked), then myfaces thinks value is changed, etc.

Perhaps resultBean is request-scoped, ie a new instance is being created on postback, with a default value of false for the uiCheckedSelector?

Regards,

Simon

Renzo Tomaselli wrote:
Hi, I have a selectBooleanCheckbox inside the "header" facet of a Tomahawk DataTable, which itself is enclosed in a form.
It is written like:

<t:selectBooleanCheckbox
    value="#{resultBean.uiCheckedSelector}"
   
    immediate="true"
    valueChangeListener="#{resultBean.checkedChanged}"/>

now I noticed (from Eclipse debugger) that the listener is always called after checking, never called after unchecking.
The value setter is called regularly in both cases.
Is it a bug or is it done on purpose ? Is there anything I miss about being notified when unchecking ?
-- Renzo




Reply via email to