Hi in my project I need to visualize currency value, as far in my f:convertNumber
I use a fixed currencySymbol; everything is ok, but when I try to get the symbol with an expression language like this:
<h:outputText value="#{rowItem.value}">
<f:convertNumber currencySymbol="#{rowItem.getCurrencySymbol()}" groupingUsed="true" maxFractionDigits="2" type="currency" />
</h:outputText>
it is like the method getCurrencySymbol is not called, I am sure there is something I am missing.
That will happen if #{rowItem} is only available during view render time, such as when it's specified by <h:dataTable var="rowItem">, as the variable name itself already suggests. It can also happen if #{rowItem} gets changed between building the view and rendering the view, such as when it's coming from a dropdown component in the same form. The <f:convertNumber> is namely a taghandler, not an UI component. It gets executed during view build time, not during view render time. The desired #{rowItem} value is not per definition available during view build time.
This all is explained in JSTL in JSF2 Facelets... makes sense? In that answer, you can substitute "JSTL" with <f:convertNumber> as they both are taghandlers and thus have exactly the same lifecycle.
There's no solution in standard JSF API without creating a custom converter and changing the view or model. You can find possible solutions in this answer: How to set converter properties for each row/item of h:dataTable/ui:repeat?
The JSF utility library OmniFaces offers <o:converter> out the box for exactly this problem. Use it as follows:
<h:outputText value="#{rowItem.value}">
<o:converter converterId="javax.faces.Number" currencySymbol="#{rowItem.getCurrencySymbol()}" type="currency" />
</h:outputText>
(note that I omitted the other two properties as those are the default already when type="currency" is used)
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?
Is it possible to display the current date (today's) in JSF without using a backing bean?
I have the following code snippet , but it didn't work out.
<div class="leftSide">Today's date #{currentDate}</div>
or
<f:facet name="header">
<h:outputText value="Today's date" />
</f:facet>
<h:outputText value="#currentDate">
<f:convertDateTime pattern="MM/dd/yyyy" type="date" />
</h:outputText>
You could register an instance of java.util.Date as a request scoped bean in faces-config.xml.
<managed-bean>
<managed-bean-name>currentDate</managed-bean-name>
<managed-bean-class>java.util.Date</managed-bean-class>
<managed-bean-scope>request</managed-bean-scope>
</managed-bean>
This way it's available as #{currentDate} without the need for a custom backing bean class.
Update: the JSF utility library OmniFaces has such a bean already registered as #{now}. So if you happen to use OmniFaces already, you can just make use of it directly.
<h:outputText value="#{now}">
<f:convertDateTime pattern="MM/dd/yyyy" type="date" />
</h:outputText>
In JSF you could use the implicit EL object session that provides access to the current HttpSession. The HttpSession#getLastAccessedTime time ...
... returns the last time the client sent a request associated with this
session, as the number of milliseconds since midnight January 1, 1970
GMT, and marked by the time the container received the request.
So you could use the following code snippet in your facelet:
<h:outputText value="#{session.lastAccessedTime}">
<f:convertDateTime pattern="MM/dd/yyyy" type="date" />
</h:outputText>
This will be server time and may differ from client time with respect to different time zones.
But you could also use a javascript solution, as discussed here:
How do I get the current date in JavaScript?
Or you could do it using Omnifaces. I'm surprised BalusC hasn't told you about this solution (I think he's a great Omnifaces contributor). Maybe it's because using Omnifaces just to display a simple date in a page might be an overkill to some.
Anyway, if your project already uses Omnifaces, there are 2 managed beans exposed by default and one in particular that you may find handy. As per the tag documentation specifies, once Omnifaces is added to your project, you can use the #{now} managed bean.
For instance, to set a Primefaces calendar's max date, I just wrote the following :
<p:calendar id="myCalendar" pattern="dd/MM/yyyy"
value="#{mybean.myDate}" maxdate="#{now}"/>
I guess the #{now} managed bean can be used in many more situations, and probably yours as well.
If your project does not use Omnifaces yet, I suggest you look at their spec and see how helpful it could be for you.
For instance, I'm using their validateOrder tag to make sure two dates are properly ordered.
You can use the tag which PrimeFaces provide.
<p:clock pattern="HH:mm:ss dd-MM-yyyy"/>
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?
I want to create links using database columns. I have a backing bean where I 'm connecting to the database. There is no problem with the connection and also no problem with the links names. I can see my links on my browser. I want to use onclick function and that's exactly where the problem starts. How can I use or can I use EL in onclick?
A little example:
<h:dataTable rows="7" value="#{frontSiteMenu.links}" var="row"
styleClass="sitemenu" width="200">
<h:column>
<h:outputText value='#{row.newsGroup}' />
</h:column>
</h:dataTable>
Thanks.
I take it you are using JSPs?
Use h:outputLink instead of an a tag and change the expression use the # character:
<h:outputLink value="#" onclick="dispNewsGroup('#{row.newsGroupId}')">
<h:outputText value='#{row.newsGroup}' />
</h:outputLink>
That is untested, but should be close to what you want.
The spec says this about # vs $:
...by convention the J2EE
web tier specifications use the
${expr} construct for immediate
evaluation and the #{expr} construct
for deferred evaluation.
So, in a repeat control where the underlying values change, it is desirable to use deferred evaluation.
There are also issues with using non-JSF tags as children of some JSF controls, so it is best to stick to using JSF controls where possible (though there is a f:verbatim tag). Many of these issues go away if you move to the newer Facelets view technology.
Is there a defined behaviour in JSF, if two input fields are bound to the same session scoped Backing Bean property.
Here is my code snippet
<h:form id="myForm">
<h:inputText id="field1" value="#{TheBackingBean.theProperty}" />
<h:inputText id="field2" value="#{TheBackingBean.theProperty}" />
<h:commandButton id="continueButton" action="#{TheBackingBean.doSomething}" />
</h:form>
My question: If field1 and field2 receive different values, what will be bound to the backing bean property? Is this even allowed?
I know this is a crude scenario. My motivation is, that we have htmlunit tests running for our application. In our JSF application we want to use a cool ajaxified custom component. This doesnt work together very well with htmlunit. So my idea was, I just put in a hidden field that binds to the same property. The unit test then fills the hidden field instead of the "real" thing.
Regards
I think this kind of code is allowed, but I am not sure of the value of theProperty after the submission. What I think is that JSF will do the following:
TheBackingBean.setTheProperty(field1.value);
TheBackingBean.setTheProperty(field2.value);
However, nothing - as far as I know - specifies the order of the setter calls. Thus, after the update values JSF phase, you will not be sure if theProperty will be equal to field1.value or field2.value.
Concerning your scenario, you say that you want to bind the same property to an inputText and an hiddenText. As the hiddenText will not submit its value, unlike the inputText, this problem will not occur. Indeed, if you have this kind of JSF code:
<h:inputText id="field1" value="#{TheBackingBean.theProperty}"/>
<h:inputHidden id="field2" value="#{TheBackingBean.theProperty}"/>
then JSF will only do:
TheBackingBean.setTheProperty(field1.value);
during the submission phase.