Hi,
can you review patch for this issue - MYFACES-3157 - please?
Regards,
Kočičák
Hi,
more info about this problem:
1) I did some testing of mojarra and they do the same in encodeBegin as
myfaces:
pushComponentToEL
. if (!isRendered())
despite of the specification.
2)
Hi,
more info about this problem:
1) I did some testing of mojarra and they do the same in encodeBegin as
myfaces:
pushComponentToEL
if (!isRendered())
despite of the specification.
2) Specification does not mention pushComponentToEL for encodeAll(),
only says If this component returns true
Hi,
h:form
h:panelGroup
h:inputText id=testId
rendered=#{component.id eq 'testId'}
value=#{bean.value} /
/h:panelGroup
/h:form
please notice the expression:
rendered=#{component.id eq 'testId'}
that is clearly
Hi
I have seen that. The problem is in spec javadoc, the behavior for
UIComponent.process*
and encode* is clear about the ordering.
In theory, pushComponentToEL should be called before any call to
isRendered, but after
isTransient. Look on MyFaces UIComponentBase.processRestoreState. It has this
Hi,
for spec I've created bug few days ago:
http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1002
but I didn't realize how deep impact this bug have: I did a training
about JSF implicit objects in our company and now practically every
coder uses #{component.something} :)
For myfaces:
I suspect that there are many cases where parent components are looking
at rendered on their children before deciding to traverse into these
children. If EL-binding rendered to the component is supported, then
the parent is either going to need to stop performing this optimization,
or it is
Hi,
there are such cases but not many of them: in myfaces code after quick
search I guess about 10 such cases. The main is in
UIComponentBase.encodeChildren and in RendererUtils.renderChild (well,
there was, but I removed it incorrectly as part of MYFACES-3126)
This affects all attributes of
