[jira] [Comment Edited] (MYFACES-4115) Implement h:selectOneRadio "group" (distributed radio button)
[
https://issues.apache.org/jira/browse/MYFACES-4115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15994318#comment-15994318
]
Leonardo Uribe edited comment on MYFACES-4115 at 5/3/17 6:07 AM:
-
I started this one some days ago, with the expectation that this one could be
easily solved, but later I found that implement the spec javadoc "as is" does
not work.
The problem starts in this example:
{code:xml}
{code}
The rendered markup by Mojarra (RI) is this:
{code:xml}
A A
B-B
C_C
{code}
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 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.
In my opinion this part is unstable. I guess I could find more holes in it, but
by some reason the implementation in Mojarra works, at least for the basic
example.
was (Author: lu4242):
I started this one some days ago, with the expectation that this one could be
easily solved, but later I found that implement the spec javadoc "as is" does
not work.
The problem starts in this example:
{code:xml}
{code}
The rendered markup by Mojarra (RI) is this:
{code:xml}
A A
B-B
C_C
{code:xml}
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 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.
In my opinion this part is unstable. I guess I could find more holes in it, but
by some reason the implementation in Mojarra works, at least for the basic
example.
> Implement h:selectOneRadio "group" (distributed radio button)
> -
>
> Key: MYFACES-4115
> URL: https://issues.apache.org/jira/browse/MYFACES-4115
> Project: MyFaces Core
> Issue Type: New Feature
>Reporter: Leonardo Uribe
>Assignee: Leonardo Uribe
>
> Implement h:selectOneRadio "group" (distributed radio button)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MYFACES-4115) Implement h:selectOneRadio "group" (distributed radio button)
[
https://issues.apache.org/jira/browse/MYFACES-4115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15994318#comment-15994318
]
Leonardo Uribe commented on MYFACES-4115:
-
I started this one some days ago, with the expectation that this one could be
easily solved, but later I found that implement the spec javadoc "as is" does
not work.
The problem starts in this example:
{code:xml}
{code}
The rendered markup by Mojarra (RI) is this:
{code:xml}
A A
B-B
C_C
{code:xml}
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 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.
In my opinion this part is unstable. I guess I could find more holes in it, but
by some reason the implementation in Mojarra works, at least for the basic
example.
> Implement h:selectOneRadio "group" (distributed radio button)
> -
>
> Key: MYFACES-4115
> URL: https://issues.apache.org/jira/browse/MYFACES-4115
> Project: MyFaces Core
> Issue Type: New Feature
>Reporter: Leonardo Uribe
>Assignee: Leonardo Uribe
>
> Implement h:selectOneRadio "group" (distributed radio button)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (MYFACES-4115) Implement h:selectOneRadio "group" (distributed radio button)
Leonardo Uribe created MYFACES-4115: --- Summary: Implement h:selectOneRadio "group" (distributed radio button) Key: MYFACES-4115 URL: https://issues.apache.org/jira/browse/MYFACES-4115 Project: MyFaces Core Issue Type: New Feature Reporter: Leonardo Uribe Assignee: Leonardo Uribe Implement h:selectOneRadio "group" (distributed radio button) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (TOBAGO-1646) Only the background of a selected option should be highlighted for a RadioGroup within a -before/after-facet
[ https://issues.apache.org/jira/browse/TOBAGO-1646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Noeth resolved TOBAGO-1646. --- Resolution: Fixed Fix Version/s: 3.1.0 > Only the background of a selected option should be highlighted for a > RadioGroup within a -before/after-facet > --- > > Key: TOBAGO-1646 > URL: https://issues.apache.org/jira/browse/TOBAGO-1646 > Project: MyFaces Tobago > Issue Type: Bug >Affects Versions: 3.0.0-alpha-7 >Reporter: Henning Noeth >Assignee: Henning Noeth >Priority: Minor > Fix For: 3.1.0 > > > If placing a RadioGroup within a , the whole > background of the RadioGroup turns grey. But only the selected option should > turn grey. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[RESULT] [VOTE] Release of MyFaces Trinidad 2.2.0
The vote has passed with the following results: +1 lofwyr Udo Schnurpfeil (binding) lu4242 Lenoardo Uribe (binding) deki Dennis Kieselhost (binding) I will proceed with the next steps. Regards, Bernd On Tue, May 2, 2017 at 4:06 AM, Leonardo Uribe wrote: > +1 > > 2017-05-01 13:47 GMT-05:00 Dennis Kieselhorst : > >> +1 >> >> Just noticed that trinidad-assembly contains duplicated artifacts and >> opened an issue for it: https://issues.apache.org/jira >> /browse/TRINIDAD-2554 >> > >
[RESULT] [VOTE] Release of MyFaces Trinidad 2.1.3
The vote has passed with the following results: +1 lofwyr Udo Schnurpfeil (binding) lu4242 Lenoardo Uribe (binding) deki Dennis Kieselhost (binding) I will proceed with the next steps. Regards, Bernd On Tue, May 2, 2017 at 4:05 AM, Leonardo Uribe wrote: > +1 > > 2017-05-01 13:39 GMT-05:00 Dennis Kieselhorst : > >> +1 >> > >
