Hi,
You're right about the oversight in the spec on this. In fact, I'm
surprised the spec changes was not reviewed properly.
Basically, when components of the group are collected, and the component of
interest doesn't have "value" attribute set, then it will delegate to the
"value" attribute of the first component of the group, if any. I'm as of
now only unsure where exactly in the spec this had to be specified.
Cheers, B
On Wed, May 3, 2017 at 8:27 AM, Leonardo Uribe <leonardo.uribe_at_irian.at>
wrote:
> Hi
>
> I have been trying to implement h:selectOneRadio "group" behavior in
> MyFaces from scratch and I have found some problems.
>
> The problem starts in this example:
>
> <h:form id="mainForm">
> <h:selectOneRadio id="radio0" group="someGroup"
> value="#{selectOneGroupBean.selectedValue}">
> <f:selectItems value="#{selectOneGroupBean.myValues}" />
> </h:selectOneRadio>
>
> <h:selectOneRadio id="radio1" group="someGroup" />
> <h:selectOneRadio id="radio2" group="someGroup" />
>
> <br/>
> <h:outputText value="Selected Value: #{selectOneGroupBean.
> selectedValue}"/>
> <br/>
> <h:commandButton value="Submit" actionListener="#{
> selectOneGroupBean.update}"/>
> </h:form>
>
> The rendered markup by Mojarra (RI) is this:
>
>
> <input type="radio" name="mainForm:someGroup" id="mainForm:radio0"
> value="mainForm:radio0:A A" />
> <label for="mainForm:radio0"> A A</label>
> <input type="radio" name="mainForm:someGroup" id="mainForm:radio1"
> value="mainForm:radio1:B-B" />
> <label for="mainForm:radio1"> B-B</label>
> <input type="radio" name="mainForm:someGroup" id="mainForm:radio2"
> value="mainForm:radio2:C_C" />
> <label for="mainForm:radio2"> C_C</label>
>
> Take a look at the "value" attribute. It appends the clientId and the
> value. This means when decode() happens, only the component with the right
> clientId takes the value. But please note only radio0 has the EL expression
> pointing to the model. Which means at some point setSubmittedValue(...) is
> called, but if is not in decode(), when?
>
> There is an inconsistency in decode(). In fact, I'm suprised the part that
> talks about that in the spec was not updated properly.
>
> There is also another problem caused by submitted values not processed by
> the validation step. The spec talks about skip processValidation(...) with
> some conditions, to avoid validation step over components that does not
> have the validators and the EL "value" expression. But if there is an stale
> "submittedValue" in a component, this value is saved/restored by the state
> saving algorithm, causing a confusion with further requests. Ok, in
> decode() you can call setSubmittedValue(null) or something like that to
> make them dissapear, but if there is an ajax requests, you cannot count on
> that, and the problem will appear.
>
> In my opinion this part is unstable. I guess I could find more holes in
> it, but by some reason the implementation in Mojarra (2.3.0) works, at
> least for the basic example.
>
> I'm still working on a implementation, but from this point I have to
> create an alternate implementation that probably will not do what the spec
> says, specially in the part related to UISelectOne.processValidators().
>
> regards,
>
> Leonardo Uribe
>
>