c:forEach vs ui:repeat in Facelets
Posted by Roger Keays, 7 June 2007, 12:28 PM
This is probably one of the most frequently asked questions on the Facelets mailing list. Why doesn't my c:forEach
tag work correctly? Unfortunately, there are may ways to misuse the
jstl tags available in Facelets, so the answer isn't always simple.
Here is an explanation of the differences between c:forEach and ui:repeat, along with some examples which will hopefully save you some headaches.
TagHandlers vs Components
The most important thing to understand about the jstl tags in Facelets is that they do not represent components
and never become a part of the component tree once the view has been
built. Rather, they are tags which are actually responsible for building the tree in the first place. Once they have done their job they expire, are no more, cease to be, etc etc.
Here is a table of the semantics of several common tags. I just
discovered, reading the Facelets code, that validators and converters
are classified separately. I had always thought they were just tag
handlers, but I imagine they behave in much the same way.
TagHandlers
Components
Other
c:forEach
c:choose
c:set
c:if
f:facet
f:actionListener
f:valueChangeListener
ui:include
ui:decorate
ui:composition
any custom tag file
ui:repeat
ui:fragment
ui:component
f:view
f:verbatim
f:selectItems
h:inputText
h:datatable
any custom UIComponent
f:validator
f:converter
One of the problems here is that there is no naming convention to
indicate which tags correspond to which constructs. You've just got to
know, or find out.
When is the view built?
Now that you understand that tag handlers are only effective when
the tree is built, the next logical question should be well, when is
tree built?
The short answer is that a new view is built for every request which
is not a postback. During a postback, the view is reconstructed from
saved state. Quite confusing, and not very obvious I know, but there
you have it.
Common laments
The most common pitfalls are either with the JSF lifecycle, EL evaluation or combining tag handlers with components.
My c:if always evaluates to false
Yes, the c:if is always evaluating to false! But it is only ever evaluated once - when the tree is built. The h:outputText component never makes it into the tree. Solution: replace the c:if with:
...
You could also use the rendered attribute on the h:outputText component in this example.
My ui:include fails inside ui:repeat
The EL for the ui:include is evaluated when the view is built and is invalid since it relies on a variable only made available by the ui:repeat during rendering. Use c:forEach in this case.
My recursive tag never stops
myTag.xhtml:
The stop condition in this recursion is supposed to be when you run out of children. The problem is that the custom eg:myTag is just a tag handler, like a special version of ui:include. When the view is built, the ui:repeat has no influence on the building process and can't stop the recursion. Use c:forEach here instead of ui:repeat. Or better still, convert your tag file to a real UIComponent.
You might also recognise that the ${child} EL expression is meaningless during build time in this example, unless you use c:foreach.
My list doesn't change size after deleting or adding an item
When your view was built you only had, say, 5 items. If you post
back to this view and add or delete an item, your view still has 5 h:outputText components in it since it was restored from saved state. In this simple case, you should use ui:repeat and your tree will always contain one h:ouputText component which is iterated over with differing values of ${item}.
If you rely on using c:forEach to
dynamically include different form components you could run into
difficulty. Always try to think about what the resulting tree looks
like and remember it doesn't change on a postback.
Suggestions for the future
Probably the best relief to this problem would be to come up with a
better syntax or naming convention to distinguish between tag handlers
and components. I imagine you could also improve compilation
performance if you did this.
Secondly, we need better terminology. I've used the terms tag handler and component in this blog which isn't too bad. The Facelets' FAQ [1] uses the terms build-time tags and render-time tags
which is a bit misleading because render-time tags (components) are
involved in all phases of the JSF lifecycle, not just the Render View
phase.
Whatever happens, tag handlers are very useful (would you use facelets without ui:decorate?) so let's not get rid of them.
References