I have to check inserted date and modified date values, which both are string. If they are equal then i wont display edited email or else i will display edited email too. So i have used the below code to validate it.
<b>Created By - </b><h:outputText value="#{o.createdEmail}" /> : <h:outputText value="#{o.createdDateTime}" /><br/>
<c:set var="createdDate" value="#{o.createdDateTime}"/>
<c:set var="modifiedDate" value="#{o.modifiedDateTime}"/>
<c:if test="#{createdDate eq modifiedDate}">
<b>Edited By - </b><h:outputText value="#{o.lastModifiedEmail}" /> : <h:outputText value="#{o.lastModifiedDateTime}" />
</c:if>
Note: o is the variable reference the backend bean.
But it is always displaying it as true even though both values are different. How is this caused and how can I solve it?
Given the way how the code is written (a managed bean with name o makes no utter sense), I do a educated guess that #{o} is declared as var of <h:dataTable> or <ui:repeat>. If that is indeed the case, then that would totally explain the symptoms. JSTL tags runs during view build time, that moment when the JSF component tree is built based on XHTML source code. However, JSF components such as <h:dataTable> and <ui:repeat> runs during view render time, that moment when the JSF component tree needs to produce HTML output.
So, in effects, the #{o} is not available at the moment JSTL <c:if> runs during view build time. You should instead be using a JSF component with rendered attribute which runs during view render time, the same moment as #{o} is been put in the EL variable scope based on current iteration round.
<ui:fragment rendered="#{createdDate eq modifiedDate}">
<b>Edited By - </b><h:outputText value="#{o.lastModifiedEmail}" /> : <h:outputText value="#{o.lastModifiedDateTime}" />
</ui:fragment>
Note: this doesn't affect <c:set>. It merely creates an "alias" to the EL expression, it doesn't immediately evaluate the EL expression, so the <c:set> is completely safe here, albeit somewhat unnecessary as the value doesn't represent such a complex EL expression.
See also:
JSTL in JSF2 Facelets... makes sense?
Related
I know we can't repeat the ID of any component we have in the same view tree.
I have a page which includes another pages by certain condition Like this...
<h:panelGroup rendered="#{bean.insertMode == 'SINGLE'}">
<ui:include src="_single.xhtml" />
</h:panelGroup>
<h:panelGroup rendered="#{bean.insertMode == 'DOUBLE'}">
<ui:include src="_double.xhtml" />
</h:panelGroup>
Now In these pages I have "Almost" the same components hierarchy (Complex) with different actions behaviour (Not only method calls, also view), for example:
_single.xhtml
<p:inputText id="fieldID" value="#{bean.value}" />
<p:commandLink actionListener="#{bean.singleAction()}" />
_double.xhtml
<p:inputText id="fieldID" value="#{bean.value}" />
<p:commandLink actionListener="#{bean.doubleAction()}" />
My little example works fine, and renders as it supposed to, but I get
java.lang.IllegalStateException: Component ID fieldID has already been found in the view.
I know that JSF process the full pages even if they are not included and that's why I'm getting this exception.
Any smart way to solve this without changing the IDs of the components inside the include pages (Although it works, but the exception is annoying and seems something is wrong). I don't want also to wrap each one of the pages with some container component with a different ID so they would have a different FULL ID like formId:fieldID because the master page is also referring to these components inside these includes!
The duplicate component ID error occurs because the both includes physically end up in the JSF component tree. The <h:panelGroup rendered="false"> doesn't prevent them from ending up in JSF component tree, instead it prevents them from generating their HTML output.
Instead of conditionally rendering their HTML output, you need to conditionally build them in the JSF component tree. JSTL is very helpful in this as it runs during view build time:
<c:if test="#{bean.insertMode eq 'SINGLE'}">
<ui:include src="_single.xhtml" />
</c:if>
<c:if test="#{bean.insertMode eq 'DOUBLE'}">
<ui:include src="_double.xhtml" />
</c:if>
In case you're using Mojarra, you only need to make sure you use at least version 2.1.18 or newer, otherwise view scoped beans will behave like request scoped beans.
An alternative is to make use of EL conditional operator in src attribute (the <ui:include> itself runs as being a taghandler also during view build time):
<ui:include src="_#{bean.insertMode eq 'SINGLE' ? 'single' : 'double'}.xhtml" />
Or even use the insertMode directly as filename:
<ui:include src="_#{fn:toLowerCase(bean.insertMode)}.xhtml" />
Either way, you need to make absolutely sure that the #{bean.insertMode} is available during view build time, and also that exactly the same value is available during the restore view phase of postbacks as it was during initial render, otherwise the view would possibly be restored with the wrong include and JSF can't decode the right inputs and command anymore. Also, when you want to change the include during postback, you really need to rebuild the view (return non-null/void), or to send a redirect.
See also:
JSTL in JSF2 Facelets... makes sense?
I'm trying to use the setPropertyActionListener tag to set a value in my backing bean. However, it doesn't work as I expected.
Context: userService is an instance of my backing bean, which contains an int member, reqID. This, in turn, is the key to a map of objects that belong to a class called User. I'm trying to create a page that will list all instances of User, and provide a button to visit a separate view that shows that particular User's information. To do this, I'm attempting to set userService.reqID to the id of the chosen User so it can generate a reference to that user for the next view (which is done in the call userService.toUserInfo).
If I use the xhtml snippet below:
<ui:define name="content">
<h:form>
<h:panelGrid>
<ui:repeat value="#{userService.UserList.getUserList()}" var="user">
<li>
<h:outputText value="#{user.name}" />
<h:commandButton value="View details of #{user.name}" action="#{userService.toUserInfo}">
<f:param name="id" value="#{user.id}" />
<f:setPropertyActionListener target="#{userService.reqID}" value="#{id}"/>
</h:commandButton>
</li>
</ui:repeat>
</h:panelGrid>
</h:form>
</ui:define>
The tag does not appear to evaluate id correctly and I get a Null Pointer Exception.
Earlier, I tried changing my setPropertyActionListenerTag so it read out as:
<f:setPropertyActionListener target="#{userService.reqID}" value="id"/>
which gave me an error, because the tag was sending the string "id" as opposed to the int value of the parameter.
Is there some way to force f:setPropertyActionListener to evaluate the expression under value? Or is there another tag that will allow me to do this?
Also, is ui:param used appropriately here?
The <f:param> (and <ui:param>) doesn't work that way. The <f:param> is intented to add HTTP request parameters to outcome of <h:xxxLink> and <h:xxxButton> components, and to parameterize the message format in <h:outputFormat>. The <ui:param> is intented to pass Facelet context parameters to <ui:include>, <ui:decorate> and <ui:define>. Mojarra had the bug that it also behaves like <c:set> without a scope. This is not the intented usage.
Just use <c:set> without a scope if it's absolutely necessary to "alias" a (long) EL expression.
<c:set var="id" value="#{user.id}" />
Put it outside the <h:commandLink> though. Also in this construct, it's kind of weird. It doesn't make the code better. I'd just leave out it.
<f:setPropertyActionListener ... value="#{user.id}" />
See also:
Setting ui:param conditionally
what is the scope of <ui:param> in JSF?
Defining and reusing an EL variable in JSF page
Unrelated to the concrete problem, if you're using EL 2.2 (as you're using JSF 2.2, you undoubtedly are as it requires a minimum of Servlet 3.0, which goes hand in hand with EL 2.2), then just pass it as bean action method argument without <f:setPropertyActionListener> mess. See also a.o. Invoke direct methods or methods with arguments / variables / parameters in EL and How can I pass selected row to commandLink inside dataTable?
<h:commandButton ... action="#{userService.toUserInfo(user.id)}">
On again another unrelated note, such a "View user" or "Edit user" request is usually idempotent. You'd better use <h:link> (yes, with <f:param>) for this. See also a.o. Creating master-detail pages for entities, how to link them and which bean scope to choose and How to navigate in JSF? How to make URL reflect current page (and not previous one).
Oh, that <h:panelGrid> around the <ui:repeat><li> doesn't make sense in HTML perspective. Get rid of it and use <ul> instead. See also HTMLDog HTML Beginner tutorial.
I hope that I understood JSF correct and this all makes sense. I try to do some kind of simple templating within a page by using (conditional) includes.
The panel is updated by a selection.
<p:outputPanel id="panel">
<h:panelGroup rendered="#{not empty someBean.selectedObject}">
<ui:include src="WEB-INF/pages/#{someBean.selectedObject.pageName}.xhtml" />
</h:panelGroup>
</p:outputPanel>
If I am right the ui:include got processed in some kind of view preparation phase and the rendered attribute just before the page gets rendered. As a result I get a FileNotFoundException because it tries to load WEB-INF/pages/.xhtml. This makes quite some sense to me, but how to solve this problem without a messy hackaround like creating an empty page as a prefix for the filename (page.xhtml) and prefix every page that should be actually rendered with this string (pageSamplePage.xhtml)?
You need to conditionally build the <ui:include> instead of conditionally render it. Use <c:if> instead of rendered.
<p:outputPanel id="panel">
<c:if test="#{not empty someBean.selectedObject}">
<ui:include src="WEB-INF/pages/#{someBean.selectedObject.pageName}.xhtml" />
</c:if>
</p:outputPanel>
Otherwise, the <ui:include> still ends up in the component tree.
See also:
JSTL in JSF2 Facelets... makes sense?
Unrelated to the concrete problem, even when you intend to conditionally render parts of the view, you'd better use <ui:fragment> instead of <h:panelGroup> as it has less overhead.
Prevent usage of <c:if>, as it can break some of the standard JSF components.
We observed that its usage caused duplication of a child within UI:Panel as a side-effect, and it took a while to identify this as the root-cause.
I would like to output a bit of Facelets code conditionally.
For that purpose, the JSTL tags seem to work fine:
<c:if test="${lpc.verbose}">
...
</c:if>
However, I'm not sure if this is a best practice? Is there another way to achieve my goal?
Introduction
JSTL <c:xxx> tags are all taghandlers and they are executed during view build time, while JSF <h:xxx> tags are all UI components and they are executed during view render time.
Note that from JSF's own <f:xxx> and <ui:xxx> tags only those which do not extend from UIComponent are also taghandlers, e.g. <f:validator>, <ui:include>, <ui:define>, etc. The ones which extend from UIComponent are also JSF UI components, e.g. <f:param>, <ui:fragment>, <ui:repeat>, etc. From JSF UI components only the id and binding attributes are also evaluated during view build time. Thus the below answer as to JSTL lifecycle also applies to the id and binding attributes of JSF components.
The view build time is that moment when the XHTML/JSP file is to be parsed and converted to a JSF component tree which is then stored as UIViewRoot of the FacesContext. The view render time is that moment when the JSF component tree is about to generate HTML, starting with UIViewRoot#encodeAll(). So: JSF UI components and JSTL tags doesn't run in sync as you'd expect from the coding. You can visualize it as follows: JSTL runs from top to bottom first, producing the JSF component tree, then it's JSF's turn to run from top to bottom again, producing the HTML output.
<c:forEach> vs <ui:repeat>
For example, this Facelets markup iterating over 3 items using <c:forEach>:
<c:forEach items="#{bean.items}" var="item">
<h:outputText id="item_#{item.id}" value="#{item.value}" />
</c:forEach>
...creates during view build time three separate <h:outputText> components in the JSF component tree, roughly represented like this:
<h:outputText id="item_1" value="#{bean.items[0].value}" />
<h:outputText id="item_2" value="#{bean.items[1].value}" />
<h:outputText id="item_3" value="#{bean.items[2].value}" />
...which in turn individually generate their HTML output during view render time:
<span id="item_1">value1</span>
<span id="item_2">value2</span>
<span id="item_3">value3</span>
Note that you need to manually ensure the uniqueness of the component IDs and that those are also evaluated during view build time.
While this Facelets markup iterating over 3 items using <ui:repeat>, which is a JSF UI component:
<ui:repeat id="items" value="#{bean.items}" var="item">
<h:outputText id="item" value="#{item.value}" />
</ui:repeat>
...already ends up as-is in the JSF component tree whereby the very same <h:outputText> component is during view render time being reused to generate HTML output based on current iteration round:
<span id="items:0:item">value1</span>
<span id="items:1:item">value2</span>
<span id="items:2:item">value3</span>
Note that the <ui:repeat> as being a NamingContainer component already ensured the uniqueness of the client ID based on iteration index; it's also not possible to use EL in id attribute of child components this way as it is also evaluated during view build time while #{item} is only available during view render time. Same is true for an h:dataTable and similar components.
<c:if>/<c:choose> vs rendered
As another example, this Facelets markup conditionally adding different tags using <c:if> (you can also use <c:choose><c:when><c:otherwise> for this):
<c:if test="#{field.type eq 'TEXT'}">
<h:inputText ... />
</c:if>
<c:if test="#{field.type eq 'PASSWORD'}">
<h:inputSecret ... />
</c:if>
<c:if test="#{field.type eq 'SELECTONE'}">
<h:selectOneMenu ... />
</c:if>
...will in case of type = TEXT only add the <h:inputText> component to the JSF component tree:
<h:inputText ... />
While this Facelets markup:
<h:inputText ... rendered="#{field.type eq 'TEXT'}" />
<h:inputSecret ... rendered="#{field.type eq 'PASSWORD'}" />
<h:selectOneMenu ... rendered="#{field.type eq 'SELECTONE'}" />
...will end up exactly as above in the JSF component tree regardless of the condition. This may thus end up in a "bloated" component tree when you have many of them and they are actually based on a "static" model (i.e. the field does not ever change during at least the view scope). Also, you may run into EL trouble when you deal with subclasses with additional properties in Mojarra versions before 2.2.7.
<c:set> vs <ui:param>
They are not interchangeable. The <c:set> sets a variable in the EL scope, which is accessible only after the tag location during view build time, but anywhere in the view during view render time. The <ui:param> passes an EL variable to a Facelet template included via <ui:include>, <ui:decorate template>, or <ui:composition template>. Older JSF versions had bugs whereby the <ui:param> variable is also available outside the Facelet template in question, this should never be relied upon.
The <c:set> without a scope attribute will behave like an alias. It does not cache the result of the EL expression in any scope. It can thus perfectly fine be used inside for example iterating JSF components. Thus, e.g. below will work fine:
<ui:repeat value="#{bean.products}" var="product">
<c:set var="price" value="#{product.price}" />
<h:outputText value="#{price}" />
</ui:repeat>
It's only not suitable for e.g. calculating the sum in a loop. For that instead use EL 3.0 stream:
<ui:repeat value="#{bean.products}" var="product">
...
</ui:repeat>
<p>Total price: #{bean.products.stream().map(product->product.price).sum()}</p>
Only, when you set the scope attribute with one of allowable values request, view, session, or application, then it will be evaluated immediately during view build time and stored in the specified scope.
<c:set var="dev" value="#{facesContext.application.projectStage eq 'Development'}" scope="application" />
This will be evaluated only once and available as #{dev} throughout the entire application.
Use JSTL to control JSF component tree building
Using JSTL may only lead to unexpected results when being used inside JSF iterating components such as <h:dataTable>, <ui:repeat>, etc, or when JSTL tag attributes depend on results of JSF events such as preRenderView or submitted form values in the model which aren't available during view build time. So, use JSTL tags only to control flow of JSF component tree building. Use JSF UI components to control flow of HTML output generation. Do not bind the var of iterating JSF components to JSTL tag attributes. Do not rely on JSF events in JSTL tag attributes.
Anytime you think you need to bind a component to the backing bean via binding, or grab one via findComponent(), and create/manipulate its children using Java code in a backing bean with new SomeComponent() and what not, then you should immediately stop and consider using JSTL instead. As JSTL is also XML based, the code needed to dynamically create JSF components will become so much better readable and maintainable.
Important to know is that Mojarra versions older than 2.1.18 had a bug in partial state saving when referencing a view scoped bean in a JSTL tag attribute. The whole view scoped bean would be newly recreated instead of retrieved from the view tree (simply because the complete view tree isn't available yet at the point JSTL runs). If you're expecting or storing some state in the view scoped bean by a JSTL tag attribute, then it won't return the value you expect, or it will be "lost" in the real view scoped bean which is restored after the view tree is built. In case you can't upgrade to Mojarra 2.1.18 or newer, the work around is to turn off partial state saving in web.xml like below:
<context-param>
<param-name>javax.faces.PARTIAL_STATE_SAVING</param-name>
<param-value>false</param-value>
</context-param>
See also:
What's the view build time?
How does the 'binding' attribute work in JSF? When and how should it be used?
How to refactor snippet of old JSP to some JSF equivalent?
Should PARTIAL_STATE_SAVING be set to false?
Communication in JSF 2.0 - #ViewScoped fails in tag handlers
To see some real world examples where JSTL tags are helpful (i.e. when really properly used during building the view), see the following questions/answers:
How to make a grid of JSF composite component?
Create table columns dynamically in JSF
How to custom layout h:selectOneRadio
Conditional variable definition in JSF
How to make composite component similar to <h:selectOneRadio />
JSF 2 -- Composite component with optional listener attribute on f:ajax
Nested JSF Composite Components leading to a Stack Overflow exception
In a nutshell
As to your concrete functional requirement, if you want to render JSF components conditionally, use the rendered attribute on the JSF HTML component instead, particularly if #{lpc} represents the currently iterated item of a JSF iterating component such as <h:dataTable> or <ui:repeat>.
<h:someComponent rendered="#{lpc.verbose}">
...
</h:someComponent>
Or, if you want to build (create/add) JSF components conditionally, then keep using JSTL. It's way much better than verbosely doing new SomeComponent() in java.
<c:if test="#{lpc.verbose}">
<h:someComponent>
...
</h:someComponent>
</c:if>
See also:
Conditionally displaying JSF components
JSTL c:if doesn't work inside a JSF h:dataTable
Specify conditional rendering of element inside <ui:repeat>? The <c:if> does not seem to work
use
<h:panelGroup rendered="#{lpc.verbose}">
...
</h:panelGroup>
For switch-like output, you can use the switch face from PrimeFaces Extensions.
I would like to output a bit of Facelets code conditionally.
For that purpose, the JSTL tags seem to work fine:
<c:if test="${lpc.verbose}">
...
</c:if>
However, I'm not sure if this is a best practice? Is there another way to achieve my goal?
Introduction
JSTL <c:xxx> tags are all taghandlers and they are executed during view build time, while JSF <h:xxx> tags are all UI components and they are executed during view render time.
Note that from JSF's own <f:xxx> and <ui:xxx> tags only those which do not extend from UIComponent are also taghandlers, e.g. <f:validator>, <ui:include>, <ui:define>, etc. The ones which extend from UIComponent are also JSF UI components, e.g. <f:param>, <ui:fragment>, <ui:repeat>, etc. From JSF UI components only the id and binding attributes are also evaluated during view build time. Thus the below answer as to JSTL lifecycle also applies to the id and binding attributes of JSF components.
The view build time is that moment when the XHTML/JSP file is to be parsed and converted to a JSF component tree which is then stored as UIViewRoot of the FacesContext. The view render time is that moment when the JSF component tree is about to generate HTML, starting with UIViewRoot#encodeAll(). So: JSF UI components and JSTL tags doesn't run in sync as you'd expect from the coding. You can visualize it as follows: JSTL runs from top to bottom first, producing the JSF component tree, then it's JSF's turn to run from top to bottom again, producing the HTML output.
<c:forEach> vs <ui:repeat>
For example, this Facelets markup iterating over 3 items using <c:forEach>:
<c:forEach items="#{bean.items}" var="item">
<h:outputText id="item_#{item.id}" value="#{item.value}" />
</c:forEach>
...creates during view build time three separate <h:outputText> components in the JSF component tree, roughly represented like this:
<h:outputText id="item_1" value="#{bean.items[0].value}" />
<h:outputText id="item_2" value="#{bean.items[1].value}" />
<h:outputText id="item_3" value="#{bean.items[2].value}" />
...which in turn individually generate their HTML output during view render time:
<span id="item_1">value1</span>
<span id="item_2">value2</span>
<span id="item_3">value3</span>
Note that you need to manually ensure the uniqueness of the component IDs and that those are also evaluated during view build time.
While this Facelets markup iterating over 3 items using <ui:repeat>, which is a JSF UI component:
<ui:repeat id="items" value="#{bean.items}" var="item">
<h:outputText id="item" value="#{item.value}" />
</ui:repeat>
...already ends up as-is in the JSF component tree whereby the very same <h:outputText> component is during view render time being reused to generate HTML output based on current iteration round:
<span id="items:0:item">value1</span>
<span id="items:1:item">value2</span>
<span id="items:2:item">value3</span>
Note that the <ui:repeat> as being a NamingContainer component already ensured the uniqueness of the client ID based on iteration index; it's also not possible to use EL in id attribute of child components this way as it is also evaluated during view build time while #{item} is only available during view render time. Same is true for an h:dataTable and similar components.
<c:if>/<c:choose> vs rendered
As another example, this Facelets markup conditionally adding different tags using <c:if> (you can also use <c:choose><c:when><c:otherwise> for this):
<c:if test="#{field.type eq 'TEXT'}">
<h:inputText ... />
</c:if>
<c:if test="#{field.type eq 'PASSWORD'}">
<h:inputSecret ... />
</c:if>
<c:if test="#{field.type eq 'SELECTONE'}">
<h:selectOneMenu ... />
</c:if>
...will in case of type = TEXT only add the <h:inputText> component to the JSF component tree:
<h:inputText ... />
While this Facelets markup:
<h:inputText ... rendered="#{field.type eq 'TEXT'}" />
<h:inputSecret ... rendered="#{field.type eq 'PASSWORD'}" />
<h:selectOneMenu ... rendered="#{field.type eq 'SELECTONE'}" />
...will end up exactly as above in the JSF component tree regardless of the condition. This may thus end up in a "bloated" component tree when you have many of them and they are actually based on a "static" model (i.e. the field does not ever change during at least the view scope). Also, you may run into EL trouble when you deal with subclasses with additional properties in Mojarra versions before 2.2.7.
<c:set> vs <ui:param>
They are not interchangeable. The <c:set> sets a variable in the EL scope, which is accessible only after the tag location during view build time, but anywhere in the view during view render time. The <ui:param> passes an EL variable to a Facelet template included via <ui:include>, <ui:decorate template>, or <ui:composition template>. Older JSF versions had bugs whereby the <ui:param> variable is also available outside the Facelet template in question, this should never be relied upon.
The <c:set> without a scope attribute will behave like an alias. It does not cache the result of the EL expression in any scope. It can thus perfectly fine be used inside for example iterating JSF components. Thus, e.g. below will work fine:
<ui:repeat value="#{bean.products}" var="product">
<c:set var="price" value="#{product.price}" />
<h:outputText value="#{price}" />
</ui:repeat>
It's only not suitable for e.g. calculating the sum in a loop. For that instead use EL 3.0 stream:
<ui:repeat value="#{bean.products}" var="product">
...
</ui:repeat>
<p>Total price: #{bean.products.stream().map(product->product.price).sum()}</p>
Only, when you set the scope attribute with one of allowable values request, view, session, or application, then it will be evaluated immediately during view build time and stored in the specified scope.
<c:set var="dev" value="#{facesContext.application.projectStage eq 'Development'}" scope="application" />
This will be evaluated only once and available as #{dev} throughout the entire application.
Use JSTL to control JSF component tree building
Using JSTL may only lead to unexpected results when being used inside JSF iterating components such as <h:dataTable>, <ui:repeat>, etc, or when JSTL tag attributes depend on results of JSF events such as preRenderView or submitted form values in the model which aren't available during view build time. So, use JSTL tags only to control flow of JSF component tree building. Use JSF UI components to control flow of HTML output generation. Do not bind the var of iterating JSF components to JSTL tag attributes. Do not rely on JSF events in JSTL tag attributes.
Anytime you think you need to bind a component to the backing bean via binding, or grab one via findComponent(), and create/manipulate its children using Java code in a backing bean with new SomeComponent() and what not, then you should immediately stop and consider using JSTL instead. As JSTL is also XML based, the code needed to dynamically create JSF components will become so much better readable and maintainable.
Important to know is that Mojarra versions older than 2.1.18 had a bug in partial state saving when referencing a view scoped bean in a JSTL tag attribute. The whole view scoped bean would be newly recreated instead of retrieved from the view tree (simply because the complete view tree isn't available yet at the point JSTL runs). If you're expecting or storing some state in the view scoped bean by a JSTL tag attribute, then it won't return the value you expect, or it will be "lost" in the real view scoped bean which is restored after the view tree is built. In case you can't upgrade to Mojarra 2.1.18 or newer, the work around is to turn off partial state saving in web.xml like below:
<context-param>
<param-name>javax.faces.PARTIAL_STATE_SAVING</param-name>
<param-value>false</param-value>
</context-param>
See also:
What's the view build time?
How does the 'binding' attribute work in JSF? When and how should it be used?
How to refactor snippet of old JSP to some JSF equivalent?
Should PARTIAL_STATE_SAVING be set to false?
Communication in JSF 2.0 - #ViewScoped fails in tag handlers
To see some real world examples where JSTL tags are helpful (i.e. when really properly used during building the view), see the following questions/answers:
How to make a grid of JSF composite component?
Create table columns dynamically in JSF
How to custom layout h:selectOneRadio
Conditional variable definition in JSF
How to make composite component similar to <h:selectOneRadio />
JSF 2 -- Composite component with optional listener attribute on f:ajax
Nested JSF Composite Components leading to a Stack Overflow exception
In a nutshell
As to your concrete functional requirement, if you want to render JSF components conditionally, use the rendered attribute on the JSF HTML component instead, particularly if #{lpc} represents the currently iterated item of a JSF iterating component such as <h:dataTable> or <ui:repeat>.
<h:someComponent rendered="#{lpc.verbose}">
...
</h:someComponent>
Or, if you want to build (create/add) JSF components conditionally, then keep using JSTL. It's way much better than verbosely doing new SomeComponent() in java.
<c:if test="#{lpc.verbose}">
<h:someComponent>
...
</h:someComponent>
</c:if>
See also:
Conditionally displaying JSF components
JSTL c:if doesn't work inside a JSF h:dataTable
Specify conditional rendering of element inside <ui:repeat>? The <c:if> does not seem to work
use
<h:panelGroup rendered="#{lpc.verbose}">
...
</h:panelGroup>
For switch-like output, you can use the switch face from PrimeFaces Extensions.