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.

<ui:repeat value="#{bean.books}" var="book">
   <ui:include src="#{book.type}-template.xhtml" />
</ui:repeat>

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/