Skip to main content

JSF Tip #62 - Understanding rendered="false"

Posted by mriem on June 3, 2014 at 1:03 AM PDT

Note this blog is obsolete, see https://www.manorrock.com/blog/ for the current blog

In JSF you will see people from time to time use rendered="false". But what does it mean?

Well, because in JSF the actual request is page based it builds up a representation of the page when the page gets loaded. When it is building up this representation it builds up the entire page, even the parts that are not going to be rendered.

Eg.

  ...
  <h:body>
    <h:outputText id="id1" rendered="true" value="2"/>

    <h:outputText id="id2" rendered="false" value="3"/>

  </h:body>
  ...

So for the above page it will have 2 output texts in the component tree, but when it is rendered you will only see the following

  2

If you want the page to not put it into the component tree altogether you will need to use the c:if tag that allows you to dynamically pick and choose what gets included in the component tree.

Enjoy!

Related Topics >>

Comments

Mixing JSTL with JSF is not a good practice, because JSTL ...

Mixing JSTL with JSF is not a good practice, because JSTL gets interpreted and executed before JSF, which may lead to unexpected output.

This why we have the rendered attribute, actually :-)

@kocko - Since you are clearly not aware that you basically ...

@kocko - Since you are clearly not aware that you basically insulted the JSF2.3 spec lead, and oblivious of where the JSF lifecycle fits in relation to JSTL, I will give you a simple example:

Snippet 1:

<p:inputText value="#{controller.inputTextValue}" rendered="false"/>

#Initial Request
bound controller get called in phase 6 Render Response

#Postback
bound controller get called in phase 1 Restore View

Visible on page: false
In component tree: true

Snippet 2:

<c:if test="false">
<p:inputText value="#{controller.inputTextValue}" />
</c:if>

#Initial Request
bound controller get NOT called

#Postback
bound controller get NOT called

Visible on page: false
In component tree: false

What Manfred was referring to was the constructed component tree, and that even when the rendered attribute is false the tree for the component is still constructed and it still participates in the lifecycle . . . If you want to avoid this (Since it could be expensive depending on what you do in your get method), you can use the jstl c:if method. This does NOT mean go mix jstl in between jsf tags, it means understand when you can, and in what order they are executed. jstl executes first top to bottom, and then jsf executes after. Keep in mind the phases and that this sequence can be repeated multiple times per request . . .

@kocko - Since you are clearly not aware that you basically ...

@kocko - Since you are clearly not aware that you basically insulted the JSF2.3 spec lead, and oblivious of where the JSF lifecycle fits in relation to JSTL, I will give you a simple example:

Snippet 1:

<p:inputText value="#{controller.inputTextValue}" rendered="false"/>

#Initial Request
bound controller get called in phase 6 Render Response

#Postback
bound controller get called in phase 1 Restore View

Visible on page: false
In component tree: true

Snippet 2:

<c:if test="false">
<p:inputText value="#{controller.inputTextValue}" />
</c:if>

#Initial Request
bound controller get NOT called

#Postback
bound controller get NOT called

Visible on page: false
In component tree: false

What Manfred was referring to was the constructed component tree, and that even when the rendered attribute is false the tree for the component is still constructed and it still participates in the lifecycle . . . If you want to avoid this (Since it could be expensive depending on what you do in your get method), you can use the jstl c:if method. This does NOT mean go mix jstl in between jsf tags, it means understand when you can, and in what order they are executed. jstl executes first top to bottom, and then jsf executes after. Keep in mind the phases and that this sequence can be repeated multiple times per request . . .