We have to display the year field on the Facelets page.
<h:outputText value="#{dateTOloginDate.get(Calendar.YEAR)}"/>
This always returns a 1 and not the year value. How can I achieve it?
The Calendar.YEAR is a constant field value. Constant field values are by default not available in EL scope at all. Hardcoded constant values do however work, as you encountered yourself.
There are several ways to achieve this in a more clean manner:
Use <f:convertDateTime> instead. You'll only need to get the java.util.Date instance by Calendar#getTime().
<h:outputText value="#{dateTOloginDate.time}">
<f:convertDateTime pattern="yyyy" />
</h:outputText>
Use OmniFaces <o:importConstants>. It allows you to import the constant field values of a given type into the EL scope. This way you'll be able to use exactly the intented syntax.
<o:importConstants type="java.util.Calendar" />
...
<h:outputText value="#{dateTOloginDate.get(Calendar.YEAR)}" />
Only, this is IMO an extreme use case. I'd personally prefer the <f:convertDateTime> way. It would also be more ideal if you just use java.util.Date instead of the clumsy java.util.Calendar. I don't see how it's beneficial to have a java.util.Calendar as model value type.
Related
can I pass expressions to JSF 2 passthrough-attributes?
the following code is not working. expression #{country.isoCode} is not evaluated.
<h:selectOneMenu value="#{bean.selectedCountry}" styleClass="selectlist">
<f:selectItems
value="#{bean.countries}" var="country"
itemLabel="#{country.countryName}"
pt:data-icon="flag flag-#{country.isoCode}"/>
</h:selectOneMenu>
I am using namespace
xmlns:pt="http://xmlns.jcp.org/jsf/passthrough"
and bootstrap-select. attribute "data-icon" is used to show an image. see:
http://silviomoreto.github.io/bootstrap-select/#data-icon
rendered output:
<i class="glyphicon flag flag-"></i>
EL is basically supported/evaluated over all place in a Facelet template. Also outside tags/attributes. Even in HTML comments, where many starters then fall over. So that's not the problem.
Your particular case is, unfortunately, "by design". Before rendering the first <option> element, the <f:selectItems> is is wholly parsed only once and turned into an iterator during which all EL expressions will be evaluated. Then, the component will iterate over it while rendering <option> elements during which all passthrough attributes will be evaluated. However, as the var was already evaluated during creating the iterator, it isn't available anywhere during rendering the passthrough attributes and ultimately evaluates to an empty string.
Fixing that would require quite some changes in standard JSF implementation of <f:selectItems>. I'm not sure if JSF guys would be all ears for that, but you can always try to create an issue.
You can work around this by creating physically multiple <f:selectItem> instances during view build time, with help of <c:forEach>.
<h:selectOneMenu ...>
<c:forEach items="#{bean.countries}" var="country">
<f:selectItem
itemValue="#{country}"
itemLabel="#{country.countryName}"
pt:data-icon="flag flag-#{country.isoCode}" />
</c:forEach>
</h:selectOneMenu>
See also:
JSTL in JSF2 Facelets... makes sense?
This example is from a book on JSF. The excercise is to refactor the following Facelets code while eliminating <c:if> and fn:toUpperCase(). Usage of <c:forEach> is allowed.
#{myBean.numbers} returns String["one","two","three"]
As the book is on JSF and not on Java, I suppose the existing Java-code is not to be touched. But I can't think of another way to do this solely in Facelets.
<c:forEach var="item" items="#{myBean.numbers}">
<c:if test="#{not fn:endsWith(item,'o')}">
#{item}
</c:if>
<c:if test="#{fn:endsWith(item,'o')}">
#{fn:toUpperCase(item)}
</c:if>
</c:forEach>
Only thing I can think of is using a converter that conditionally uses String#toUpperCase() and then I still do not understand why use of <c:forEach> should still be allowed:
<ui:repeat var="item" value="#{myBean.numbers}">
<h:outputText value="#{item}" converter="conditionalConverter"/>
</ui:repeat>
Is there a more "Facelets way" to do this (and still a need to use <c:forEach>)?
UPDATE:
Instead of <c:if> one could still use e.g. <h:outputPanel> and it's rendered-attribute, but there is still no Java-less replacement for fn:toUpperCase().
I am asking for learning purposes only. I suppose the <ui:repeat>-solution with a converter is the cleanest and represents most how JSF is supposed to be used. Do you think so, too?
As to <c:if>, the JSF alternative to JSTL <c:if> is the rendered attribute on any component. For example, <h:panelGroup> or <h:outputText>. Those components doesn't generate additional markup if there are no attribtues specified which should end up in HTML, like id or styleClass, otherwise they generate a <span>.
Here's an example of both:
<h:panelGroup rendered="#{not fn:endsWith(item,'o')}">
#{item}
</h:panelGroup>
<h:outputText value="#{fn:toUpperCase(item)}" rendered="#{fn:endsWith(item,'o')}" />
As to fn:toUpperCase(), JSF has no alternative. I'm not sure why you would need a JSF alternative as it's essentially not a tag, but a simple EL function which is perfectly usable in both JSTL and JSF tags. In any case, you could if necessary throw in CSS text-transform: uppercase. As this takes place entirely client side, your only problem may be the browser support.
<h:outputText value="#{item}" style="text-transform: uppercase" />
(note: this is just an example, the normal practice is to put styles in its own .css file which you load by <h:outputStylesheet>)
<h:outputText value="#{item}" styleClass="uppercased" />
I suppose the -solution with a converter is the cleanest and represents most how JSF is supposed to be used. Do you think so, too?
I'm a big fan of "Use the right tool for the job". Use JSTL tags to conditionally build the JSF component tree. Use JSF components to generate HTML. That's it. See also JSTL in JSF2 Facelets... makes sense?
In Struts2 tutorial for s:select tag I've seen:
<s:select label="Pets"
name="petIds"
list="petDao.pets"
listKey="id"
listValue="name"
multiple="true"
size="3"
required="true"
value="%{petDao.pets.{id}}"
/> ^ ^
and my question: why value="%{petDao.pets.{id}}"? why not simply value="%{petDao.pets.id}"? what do those trailing curly braces mean?
This is an OGNL list projection to get all the id values as a list from petDao.pets, meaning all values in this <s:select> will be pre-selected.
It isn't necessary; I suspect it was the result of an error in the tag's source file.
It works with it, but isn't needed, will fail IDE validation (if the IDE supports S2 and/or OGNL, e.g., IntelliJ), and I've made a note to update.
The principal reason is because %{} syntax is used to force OGNL evaluation where Struts would otherwise be treating the value as a String literal.
For example,
<s:property value="name" />
will look for a name property in the value stack i.e. is a value retrieved by calling getName().
If you wanted to force it to use literal value "name", you will need to use the %{} syntax -
<s:property value="%{'name'}" />
Source:
http://www.coderanch.com/t/420711/Struts/Struts
I'm using Primefaces and MyFaces. I would like to use the selectBooleanButton component, to control visibility of other components within a long and rather complex form.
simplified sample code:
<p:selectBooleanButton
onLabel="Comment" offLabel="Comment"
onIcon="ui-icon-check" offIcon="ui-icon-close"
value="#{not empty myBean.comment}"
onchange="toggleDisplay(this.checked,'myForm:commentPanel');" />
<h:panelGroup id="commentPanel"
style="display:#{empty myBean.comment ? 'none' : 'block'}">
<p:inputTextarea value="{myBean.comment}"/>
</h:panelGroup>
The javascript in the onchange attribute simply toggles the display style from none to block and vice-versa to hide or unhide the panel group. I want/need the components to remain in the view, I do not want to use rendered attributes to remove them completely.
Where I get into trouble is because of the EL construct used in the value attribute of the setBooleanButton component. I do realize that this EL statement is not compatible with the set operation, and this results in an exception.
What I want to be able to do is when the form is loaded, have the initial status of the selectBooleanButton components set to 'on' when the comment property has some existing text it, and 'off' when it is empty. I am looking for a way to work around this that would not require me to create a property in the model for each and every instance where I want to hide the panel, as that would result in dozens and dozens of properties because my real world form is very large with many of these comment sections.
I also posted this question on Primefaces forum, and did not receive any answers there either, so at this time there may not be a great solution to this problem, or at least not one that has been shared. What I ended up doing to work around this is to create two versions of the component, and use the rendered attribute to control which one is used, like this:
<p:selectBooleanButton
onLabel="Comment" offLabel="Comment"
onIcon="ui-icon-check" offIcon="ui-icon-close"
value="true" rendered="#{not empty myBean.comment}"
onchange="toggleDisplay(this.checked,'myForm:commentPanel');" />
<p:selectBooleanButton
onLabel="Comment" offLabel="Comment"
onIcon="ui-icon-check" offIcon="ui-icon-close"
value="false" rendered="#{empty myBean.comment}"
onchange="toggleDisplay(this.checked,'myForm:commentPanel');" />
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"/>