> You must have had a real use case that pushed you to write this component.
> Can you please describe it?
The same as all usages of <c:choose />. The index based or more than
one are just added benefits I threw in. I can provide examples, but I
shouldn't have to. Just because someone can't think of when it would
be needed, doesn't mean it never would be useful, but I can appease
you curiosity. I created the component so that people would stop using
c:choose and c:if in JSF pages and complain that they don't work in
tables and such.
1) default c:choose functionality (render the first match):
<s:limitRendered>
<h:outputText value="#{person.first} #{person.last}"
rendered="#{prefs.firstThenLast}" />
<h:outputText value="#{person.last}, #{person.first}"
rendered="#{prefs.firstThenLast}" />
</s:limitRendered>
2) render index based. This behaves much like the tr:switcher
component. But instead of using facets and facet names, it uses
<s:limitRendered value="#{wizard.currentStep}" type="index">
<h:panelGroup>
<h:outputText value="This is wizard step 1" />
</h:panelGroup>
<h:panelGroup>
<h:outputText value="This is wizard step 2" />
</h:panelGroup>
<h:panelGroup>
<h:outputText value="This is wizard step 3" />
</h:panelGroup>
</s:limitRendered>
<h:commandButton action="#{wizard.prev}"
rendered="#{wizard.currentStep gt 0}" value="Prev" />
<h:commandButton action="#{wizard.next}"
rendered="#{wizard.currentStep lt (wizard.numSteps - 1)}" value="Next"
/>
<h:commandButton action="#{wizard.finish}"
rendered="#{wizard.currentStep eq (wizard.numSteps - 1)}"
value="Finish" />
3) render multiple children. Can be used much like "-v" vs "-vvvv" can
be used for command line verbosity
<s:limitRendered value="#{verbosity}">
<h:outputText value="#{title}" />
<h:outputText value="#{usage}" />
<h:outputText value="#{description}" />
</s:limitRendered>
Now I cannot tell you all the reasons they may be useful, but I can
say that many time in Trinidad authors chose to only provide
functionality that they themselves could think of, making the
component useless for every use case they could not think of. Perhaps
I cannot think of great reasons to render more than one child at the
moment, but who is to say no one will ever want that?
The main use case is to stop this code:
<h:outputText value="a" rendered="#{value1 eq 'a'}" />
<h:outputText value="b" rendered="#{value1 ne 'a' and value2 eq 'b'}" />
<h:outputText value="c" rendered="#{value1 ne 'a' and value2 ne 'b'
and value3 eq 'c'}" />
<h:outputText value="otherwise" rendered="#{value1 ne 'a' and value2
ne 'b' and value3 ne 'c'}" />
etc.
Several times I have had the use case where I only want to render a
component if the previous one was not rendered. To get that
functionality, I always had to negate the test of the rendered of the
previous components then include the test for the current component.
This is much easier to write and definitely to maintain:
<s:limitRendered>
<h:outputText value="a" rendered="#{value1 eq 'a'}" />
<h:outputText value="b" rendered="#{value2 eq 'b'}" />
<h:outputText value="c" rendered="#{value3 eq 'c'}" />
<h:outputText value="otherwise" />
</s:limitRendered>
So for the most part, every use case in JSP to use <c:choose /> is a
use case to use limitRendered in JSF. As mentioned, the index based or
multiple support was just added functionality for rare use cases.
-Andrew
