In latest mojarra something changed, but problem is still reproducible
with this little trick:
<h:form id="formId">
<a:myComponent id="myComponentId">
<h:inputText id="testId" rendered="#{component.id eq
'testId'}" value="#{bean.value}"/>
</a:myComponent>
<h:commandButton value="submit" />
</h:form>
and
in MyComponent.java:
@Override
public boolean getRendersChildren() {
return true;
}
@Override
public void encodeChildren(FacesContext context) throws IOException
{
...
if (getChildCount() > 0) {
for (UIComponent child : getChildren()) {
child.encodeBegin(context);
child.encodeEnd(context);
}
}
...
}
-> input never updates model (wrong)
when you replace
child.encodeBegin(context);
child.encodeEnd(context);
with
child.encodeAll(context);
-> input is not rendered (wrong)
Leonardo Uribe píše v Po 25. 07. 2011 v 14:09 -0500:
> Hi
>
> 2011/7/25 Martin Koci <[email protected]>:
> > Hi,
> >
> > how can I help to ping EG? It seems that JSF-spec team has own working
> > plan and no time for issues with no vote.
> >
> > About interoperability: I've double checked that mojarra breaks
> > specified behaviour in encodeBegin:
> >
> > pushComponentToEL -> isNotRendered -> return
> >
> > but in processDecodes the must have specified behaviour:
> >
> > isNotRendered- > return; else pushComponentToEL
> >
>
> Really? I didn't knew that. That changes things, because if they are
> not doing what javadoc says, it is clear we shouldn't follow it too. I
> have no objections to commit the patch. Anyway let me review it to
> check everything is ok.
>
> I'll send a message to the EG about this one.
>
> >
> > because example example from [1] works as expected = badly = component
> > is rendered but never decoded.
> >
> > Patch for [2] is myfaces internal only. Can you please review it and
> > apply? We can use the new method RenderUtils.isRendered later in
> > renderers where child.isRendered() optimalization is used.
> >
>
> Ok, I'll check it and commit it.
>
> regards,
>
> Leonardo Uribe
>
> > Regards,
> >
> > Kočičák
> >
> > [1] http://www.mail-archive.com/[email protected]/msg53300.html
> > [2] https://issues.apache.org/jira/browse/MYFACES-3126
> >
> >
> > 1. Leonardo Uribe píše v Po 25. 07. 2011 v 11:37 -0500:
> >> Hi
> >>
> >> The problem with these patches is the changes proposed change the
> >> default behavior, and we still don't have any response about that from
> >> the EG. See:
> >>
> >> http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1002
> >>
> >> I'm afraid the changes could be significant and cause some kind of
> >> interoperability issues between MyFaces and Mojarra. In my opinion
> >> what patches propose is correct, but we should ping the EG to see what
> >> they think about it and if it is valid to apply these changes on 2.0.x
> >> / 2.1.x branches.
> >>
> >> regards,
> >>
> >> Leonardo Uribe
> >>
> >> 2011/7/24 Martin Koci <[email protected]>:
> >> > Hi,
> >> >
> >> > please review patches for:
> >> > https://issues.apache.org/jira/browse/MYFACES-3157
> >> > https://issues.apache.org/jira/browse/MYFACES-3126
> >> >
> >> >
> >> > Thanks,
> >> >
> >> >
> >> > Kočičák
> >> >
> >> >
> >> >
> >>
> >
> >
> >
>
