Were you able to resolve the problem. I am facing the exact same issue. It seems while building the component it does not take the rendered attribute in consideration and c:if does not affect until rendering time.
If you found a problem to this issue, please do reply. Thanks for your time.
Yet another example of why JSF and JSTL don't mix. Don't use JSTL on JSF views and components and life will be much more pleasant!
Customer surveys are for companies who didn't pay proper attention to begin with.
Joined: Aug 06, 2011
Yes Tim! I understand that but the problem is that the rendered attribute seems to be not honored in all the phases. I have used rendered attribute hardcoded to false but in some phase of JSF lifecycle it is not evaluated and I get Stack Overflow error.
Rahul Jjain wrote:Yes Tim! I understand that but the problem is that the rendered attribute seems to be not honored in all the phases. I have used rendered attribute hardcoded to false but in some phase of JSF lifecycle it is not evaluated and I get Stack Overflow error.
"rendered" is a directive to the view renderer, so its only application is to instruct the renderer as to whether or not it should generate output. That is done during the Render Response phase.
However, your "cc:Deep" element didn't have a "rendered" attribute, so it would render unconditionally.
One reason WHY you shouldn't mix JSF and JSTL is that JSTL is designed for JSPs. JSPs are compiled into servlets as straight-line interpretations of the page definition into sequential Java code text and in particular, the "c:if" tag renders into straight Java if/then logic. JSF is not compiled into executable code, even when you define a JSF View with the ".jsp" filename extension. JSF is compiled into a 2-dimensional data structure which is used by the renderer as a reference object. The renderer is obliged to observe output element (geometric) placement and precedence - meaning a render-suppressed container suppresses rendering of its children - but it can process the tree in any order it finds convenient. Including, if the environment is right, in parallel.
The only reason why stack overflow should be an issue (unless you're already at critical memory usage), is if you're mis-applying the JSF architecture. A common mistake is that people put heavy processing into propery "get" methods. Sometimes this is the only reasonably-clean way to get something done, but it should be avoided as much as possible, and such operations should always be designed realizing that the "get" methods can be invoked several times over the request/response cycle, and therefore should A) cache their results to cut overhead and B) NEVER have side-effects (in Computer Science terms, they should be idempotent).