I've got a problem with JBossEL in NetBeans. Jboss EL provides method execution besides java bean binding. So th code :
<h:outputText value="#{welcomeController.getWelcome(request)}" />
is correct and works fine. But NetBeans shows me an error:
The function getWelcome must be used with a prefix when a default namespace is not specified
How to make NetBeans compatilble with JbossEL ?
I'm using Facelets if it helps.
Just ignore and run.
If those errors annoy you, just disable/reconfigure the JSP EL validator somewhere in the IDE settings.
Related
I'm using exaples from the official Java EE tutorial In which contains the follow:
<h:panelGrid columns="2"
headerClass="list-header"
styleClass="list-background"
rowClasses="list-row-even, list-row-odd"
summary="#{bundle.CustomerInfo}"
title="#{bundle.Checkout}"
role="presentation">
But compiler says that attribute role is not defined for h:panelGrid component. How to fix this?
That attribute was introduced in JSF 2.2. As evidence, the role attribute is mentioned in JSF 2.2 <h:panelGrid> documentation, but not in JSF 2.1 <h:panelGrid> documentation.
Your question history confirms that you're using JSF 2.2 on GlassFish 4.0, so this compiler warning is actually wrong. This is not exactly a JSF problem, but an IDE problem. The IDE is somehow thinking that you're not using JSF 2.2, but JSF 2.1 or older. I.e. your toolset is working against you. You didn't mention which IDE you're using, so it's not possible to post the right answer.
If the project runs fine and the JSF page produces the right HTML output (i.e. the role attribute actually ends up in generated HTML <table> element as you can see by rightclick, View Source in webbrowser), then everything is well and it's just the IDE who's pretending to be smarter than it actually is.
I'd start peeking around in IDE project's properties to check if the JSF versions are all right. The JSF facet in project's properties must be set to version 2.2, not lower. The faces-config.xml must be declared conform JSF 2.2, not lower.
Trying to make the new RTL Support in PrimeFaces 3.5 work dynamically, I appended the following in web.xml:
<context-param>
<param-name>primefaces.DIR</param-name>
<param-value>#{facesBean.direction}</param-value>
</context-param>
As you can see, the parameter value is an EL expression, evaluated from the bean property : direction:
private String direction = "ltr";
//......
public String getDirection() {
if (FacesContext.getCurrentInstance().getViewRoot().getLocale().getLanguage() == "ar") {
direction = "rtl";
} else {
direction = "ltr";
}
return direction;
}
However this does not work (I am too naive to believe it could work that simple way, since web.xml is not loaded the same way as xhtml files...)
If I tell explicitly for example ACCORDION to react to direction value, it does successfully (If locale language is changed to ar, dir receives rtl value, and if it is changed to fr or en, value received by dir attribute is ltr):
<p:accordionPanel dir="#{facesBean.direction}" id="accordion_services" dynamic="true" cache="true"
style="text-align: justify;" >
<p:tab title="#{i18n.seep}">
<h:panelGrid columns="2" cellpadding="10">
<!-- Remainder of code here ...... -->
I could apply that latter solution to every PrimeFaces component that has the DIR attribute, but that is anti-productive and would consume great amount of time.
The application scope DIR parameter is the ideal solution and it's claimed that it supports EL expressions. So I am interested in making it work.
Any clues?
Thanks.
JBoss AS 7.1
Mojarra 2.1
PrimeFaces 3.5
Latest Firefox/Chrome
Reference: Page 491 from PrimeFaces 3.5 user guide:
*Global Configuration
Using primefaces.DIR global setting to rtl instructs PrimeFaces RTL aware components such as datatable, accordion, tabview, dialog, tree to render in RTL mode.*
`<context-param>
<param-name>primefaces.DIR</param-name>
<param-value>rtl</param-value>
</context-param>`
Parameter value can also be an EL expression for dynamic values. In upcoming PrimeFaces releases, more components will receive built-in RTL support. Until then if the component you use doesn’t provide it, overriding css and javascript in your application would be the solution.
491
RTL currently does NOT support EL in web.xml (I am using PF 3.5)
I have created a feature request for PF team
I have posted this question again in PF forum and I got an answer here
See also:
using JSF EL expression inside web.xml
UPDATE
its fixed and will be available in the upcoming Primefaces 4.1
I would like to display a text in jsf screen by passing an attribute to a method implemented in backing bean. I have to pass a dynamic value as an attribute. I tried the below but it seems to be an incorrect syntax -
<h:outputText value="#{getValue(#{item.product}).component.address}" />
Apart from the syntax error (you can never nest EL expressions like as #{#{}}), the following is valid in EL 2.2 which is in turn part of Servlet 3.0 / Java EE 6:
<h:outputText value="#{bean.getValue(item.product).component.address}" />
So if you have a Servlet 3.0 compatible target runtime (Tomcat 7, Glassfish 3, JBoss 6, etc) with a Servlet 3.0 compatible web.xml, then you can invoke non-getter methods with arguments like this.
However, based on your question history you're using JSF 1.2 and the chance is big that you're also targeting an older container where the above wouldn't work. If it is a Servlet 2.5 container, then you could use JBoss EL to get this EL syntax to work.
See also:
Invoking methods with parameters by EL in JSF 1.2
JSF 1.2 w/ EL 2.1 (the usual pairing) doesn't support calling methods with parameters on beans using EL expressions.
There exists one hack, abusing the fact that JSF EL expressions work on maps:
value="#{myBean['product']}"
This will assume myBean is implementing Map interface and will call get method with 'product' as parameter. I don't know if the key can be dynamically computed but it's worth a try.
Syntax would be:
value="#{myBean[item.product].component.address}"
Assuming here that myBean implements Map interface and returns the appropriate object and item.product is returns a string.
I am not sure this will work, but it's your only option beside implementing a getter that looks up item.product value in its implementation.
We have a web application, which uses weblogic jsf 1.2 implementation from deployable-libraries(jsf-1.2.war). We started to use weblogic jsf impl after having some problems with compatibility of packed jsf-impl and weblogic 10.3.4.
So the problem is that, we have outputLink with several params, these params' values could contain spacial chars, so we explicitly encode them(we have taglib function for this purpose), but jsf impl on weblogic 10.3.4 also encodes these chars, so we have double encoded link URL. Does anybody know is there a possibility to disable this option on weblogic and encode params only manually.
Just do not encode it yourself with a custom taglib. The <f:param> will already implicitly do it.
<h:outputLink value="page.jsf">
<h:outputText value="Click" />
<f:param name="foo" value="#{bean.foo}" />
<f:param name="bar" value="#{bean.bar}" />
</h:outputLink>
That's all. The #{bean.foo} and #{bean.bar} in above example can just return the raw and unencoded string value.
Update as per the comments, this suggests that those two servers JBoss AS 4.2.3 and WebLogic 10.3.2 are using a specific JSF implementation/version which exposes a bug in URL-encoding of <f:param>. As far, I can only find the following related reports (it's not clear if you're using MyFaces or Mojarra, so I searched in both):
Mojarra (a.k.a. Sun RI): http://java.net/jira/browse/JAVASERVERFACES-791 fixed in 1.2_10.
MyFaces: https://issues.apache.org/jira/browse/MYFACES-1832 fixed in 1.1.6 and > 1.2.2(?).
I recommend to replace/upgrade the JSF version of the servers in question to a newer version than the ones mentioned in those reports, or to ship JSF libraries along with the webapp itself and add web.xml context parameters to instruct the server to use the webapp bundled JSF instead.
I'm using:
Tomcat 6.0
Jsf 1.2 - Mojarra Implementation
Tomahawk 1.1.9
I imported the taglib
<%# taglib uri="http://java.sun.com/jsp/jstl/functions" prefix="fn" %>
when i call:
<h:outputText value="#{fn:indexOf('ciao','i')}"></h:outputText>
Output is 1
when i use
<t:outputText value="#{fn:indexOf('ciao','i')}"></t:outputText>
it throws a server exception, like there are some problems referencing right library.
javax.el.ELException: Function 'fn:indexOf' not found
at org.apache.el.lang.ExpressionBuilder.visit(ExpressionBuilder.java:171)
at org.apache.el.parser.SimpleNode.accept(SimpleNode.java:145)
at org.apache.el.lang.ExpressionBuilder.prepare(ExpressionBuilder.java:133)
at org.apache.el.lang.ExpressionBuilder.build(ExpressionBuilder.java:147)
Any hint? Thank you everybody for help :)
I was able to reproduce exactly this problem with Mojarra 1.2_14 and Tomahawk 1.1.9 on Tomcat 6.0.18. The same problem also occurred at Tomcat 6.0.20, although the line numbers of the org.apache.el.* methods in the stacktrace were slightly different.
To exclude Tomcat's jsp-el from being suspect, I tested at Glassfish v3 as well, which is using a different EL impl. It produced basically the same exception, although with different EL classes in stacktrace (com.sun.el.* instead of org.apache.el.*).
Interesting fact is however that it indeed works flawlessly when using Facelets instead of JSP, as commented by Bozho. This would mean that the JSP EL implementations of both Tomcat and Glassfish are broken.
I would start filing an issue for Tomcat 6 here http://tomcat.apache.org/bugreport.html and see what the Apache guys says about this.