Jakub is a Java EE developer since 2005 and occasionally a project manager, working currently with Iterate AS. He's highly interested in developer productivity (and tools like Maven and AOP/AspectJ), web frameworks, Java portals, testing and performance and works a lot with IBM technologies. A native to Czech Republic, he lives now in Oslo, Norway. Jakub is a DZone MVB and is not an employee of DZone and has posted 156 posts at DZone. You can read more from them at their website. View Full User Profile

JSF: Beware the Difference Between Build-Time and Render-Time Tags in Facelets

  • submit to reddit

This is to remind me that I should never ever forget the cruical difference between build-time-only tags (i.e. having tag handlers only) and render-time tags that have corresponding components. The problem is that their lifespan is different and thus mixing them can easily lead to nasty surprises. Build time tags are used to modify the building of a component tree and have no effect during its rendering, where only the components participate.

A typical mistake is the nesting of ui:include (build-time) inside ui:repeat (render-time) using the var that ui:repeat declares:
<ui:repeat value="#{bean.books}" var="book">
   <ui:include src="#{book.type}-template.xhtml" />

This won’t work as intended because the var is only made available at the render time while ui:include is already evaluated at that point as it was invoked at the build time.

This is why combining JSTL and JSF isn’t recommended in general. The complication with Facelets is that there is no clear distinct mark such as the namespace prefix that would distinguish build-time and render-time tags. In adition to JSTL also f.ex. f:actionListener, f:facet, ui:include, and any custom tag file are build-time while  e.g. f:selectItems, ui:repeat,h:inputText, and any custom UIComponent are render time. An addition to that it seems that f:converter and f:validator are yet another special case [3] (though more like build-time tags).

So make sure that you know which tags are build-time and which are render-time and when it is meaningful to mix them and when you should absolutely avoid it.

References (highly recommended to read through):

  1. Andrew: Build time vs. render time  (2008) – mainly about JSP but the last section relates it to Facelets, which have the same problem with its tag handlers as JSP with its (non-JSF) tags
  2. BalusC: Why @ViewScoped fails in tag handlers (2011, JSF 2.0) – the author lists render-time alternatives for build-time tags where available
  3. Roger Keays: c:forEach vs ui:repeat in Facelets  (2007)


From http://theholyjava.wordpress.com/2011/10/28/jsf-beware-the-difference-between-build-time-and-render-time-tags-in-facelets/

Published at DZone with permission of Jakub Holý, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


André Pankraz replied on Mon, 2011/10/31 - 8:38am

i'm not sure but this seems to have improved in JSF 2. in 1.2 mixing c:set/if with render time components was really a problem and i had to explain this to many new JSF developers.

maybe former releases didn't build the view tree 2 times like JSF 2? it happens here in the view restore phase for model updates and _again_ before the final rendering phase. if this was different in 1.2 it explains why you don't notice this problem anymore besides the classic ui:repeat example - and this new View Scope that nobody uses anyway ;


i find this tip "replace c:if etc with rendered=" really problematic. for single components this might be OK, but for big sub components you will notice a severe difference in memory and CPU consumption. rendered=false components are in the view tree.

Jakub Holý replied on Tue, 2011/11/08 - 4:26pm

@André Good point regardin rendered="false" and memory consumption, thanks!

Robert Craft replied on Thu, 2012/01/26 - 5:35am

Very nice and thoughtful post. I am now clear with the Difference Between Build-Time and Render-Time Tags in Facelets. Also the code sample is really helpful. Nice efforts.

Spring Framework

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.