Hi
Unfortunately sometimes you don't see the problems until you try to
implement what the spec says.
I agree with you about the strategy to implement (move decoded value to the
first component of the group), but I need to check this part fully to see
the spec changes. I think the javadoc/api will not change, but the
implementation needs to be clarified or refactored. I still don't
understand why append the clientId with the value, but in principle it is
not a problem.
regards,
Leonardo Uribe
2017-05-03 2:29 GMT-05:00 Bauke Scholtz <balusc_at_gmail.com>:
> 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="#{selectOneGro
>> upBean.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
>>
>>
>