PrimeFaces 3.5 parameter.DIR dynamically - jsf

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

Related

Missing parameter values in invoked method with composite components using ui:repeat

So after several days of debugging, we were eventually able to reproduce some strange interactions between composite components, ui:repeat, p:remoteCommand and partial state saving in JSF that we do not understand.
Scenario
A composite component iterates over a list of objects using ui:repeat. During each iteration, another composite component is included and arguments are passed.
<ui:composition (...)>
<ui:repeat var="myVar" value="#{cc.attrs.controller.someList}">
<namespace:myRemoteCommand someParam="SomeParam"/>
In the included composite component, there is an auto-run p:remoteCommand calling a method using parameters defined in the component's interface.
<ui:component (...)>
<p:remoteCommand actionListener="#{someBean.someMethod(cc.attrs.someParam)}"
autoRun="true"
async="true"
global="false">
However, when setting a breakpoint in someMethod(...), an empty string is passed. This only happens if partial state saving is set to false.
Solutions
We tried several solutions and the following ones appear to work (however we do not understand why and cannot foresee any further problems that could occur):
We can set partial state saving to true.
We can change the composite component pattern to ui:include.
We can remove one or both of the composite components and directly include the content instead.
Question
Why does JSF behave this way? What is this interaction between composite component, ui:repeat and argument passing that changes depending on whether we use ui:include / partial state saving or not?
We're using Primefaces 5.3, Glassfish 4.1, Mojarra 2.2.12, Java 8.
Your code is all fine. It's just that Mojarra's <ui:repeat> is broken. You're not the first one facing a state management related problem with <ui:repeat>.
Checkbox inside ui:repeat not refreshed by Ajax
Dynamically added input field in ui:repeat is not processed during form submit
Components are with the same id inside ui:repeat
<h:form> within <ui:repeat> not entirely working, only the last <h:form> is processed
Composite component with custom backing component breaks strangely when nested inside ui:repeat
ui:repeat in o:tree not working as expected
Root cause of your problem is that #{cc} is nowhere available at the moment the <ui:repeat> needs to visit the tree. Effectively, the <ui:repeat value> is null. A quick work around is to explicitly push the #{cc} in UIRepeat#visitTree() method. Given Mojarra 2.2.12, add below lines right before line 734 with pushComponentToEL(facesContext, null).
UIComponent compositeParent = getCompositeComponentParent(this);
if (compositeParent != null) {
compositeParent.pushComponentToEL(facesContext, null);
}
And add below lines right after line 767 with popComponentFromEL(facesContext).
if (compositeParent != null) {
compositeParent.popComponentFromEL(facesContext);
}
If you don't build Mojarra from source, copy the entire source code of UIRepeat into your project, maintaining its package structure and apply above changes on it. Classes in /WEB-INF/classes have higher classloading precedence than those in /WEB-INF/lib and server's /lib. I have at least created issue 4162 to address this.
An alternative is to replace Mojarra by MyFaces, or to replace the <ui:repeat> by an UIData based component which got state management right such as <h:dataTable> or <p:dataList>.
<p:dataList type="none" var="myVar" value="#{cc.attrs.controller.someList}">
<namespace:myRemoteCommand someParam="SomeParam" />
</p:dataList>
You might only want to apply some CSS to get rid of widget style (border and such), but that's trivial.
See also:
Should PARTIAL_STATE_SAVING be set to false?

JSF 2.2 - everything inside ui:repeat is evaluated, although rendered = "false"

I'm currently migrating a web application from JSF 1.2/Richfaces 3.3.3 to JSF 2.2 For data iteration, we used a4j:repeat from Richfaces. I now want to change the iterators to ui:repeat, because we want to throw out Richfaces.
However, I came across a very strange behaviour. Imagine a code snippet like this (simplified from the original):
<ui:repeat id="criterions" var="criterion" value="#{AdvancedSearchBean.criterionList}">
<h:panelGroup rendered="#{criterion.searchCriterion.displayType == 'PERSON'}">
<h:inputText value="#{criterion.searchString}"/>
</h:panelGroup>
</ui:repeat>
The part inside the panelGroup is evaluated, although the rendered condition definitely evaluates to false. If I change ui:repeat to a4j:repeat, it works fine, the part inside the panelGroup is NOT evaluated.
This is a real problem for our code, as the "criterion" variable can contain different objects (extending the same superclass). In this case, the criterion object does not contain a property with the name "searchString" (because it is not of type "PERSON") -> an error is thrown.
Can anyone explain this behaviour or has a solution?
I'm using the JSF version integrated in WildFly 8.0.0.final (Mojarra 2.2.5-jbossorg-3)
Thanks
Markus

Enum properties are not retrieved by OmniFaces in Spring / JSF projects

Given the following enum.
package util;
public enum IntegerConstants
{
DATA_TABLE_PAGE_LINKS(10);
private final int value;
private IntegerConstants(int con) {
this.value = con;
}
public int getValue() {
return value;
}
}
The constant given here should be retrieved on an XHTML page like as follows.
<ui:composition template="/WEB-INF/admin_template/Template.xhtml"
xmlns="http://www.w3.org/1999/xhtml"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:ui="http://java.sun.com/jsf/facelets"
xmlns:o="http://omnifaces.org/ui">
<ui:define name="title">Test</ui:define>
<ui:define name="content">
<h:form id="form" prependId="true">
<o:importConstants var="const" type="util.IntegerConstants"/>
DATA_TABLE_PAGE_LINKS : #{const.DATA_TABLE_PAGE_LINKS.value}
</h:form>
</ui:define>
</ui:composition>
This works in an enterprise application having JSF managed beans running on GlassFish 4.0.
This same thing, however does not work in a project that uses Spring (4.0 GA), JSF 2.2.6, PrimeFaces 5.0 final, PrimeFaces Extensions 2.0.0 final running on Tomcat 8.0.3.0.
This should not be related to Spring.
The enum given is available (its class file) in the WEB-INF/classes folder under the application's build folder.
It is difficult to find out the actual cause of the problem because no error or exception is thrown. The page on the browser is just left blank and there is nothing to see on the server terminal.
The OmniFaces version is 1.7.
Given it a try on OmniFaces 1.8-SNAPSHOT but the problem remained stationary.
Partial answer :
This worked, when I changed the value of the var attribute of <o:importConstants> from const to something different like as follows.
<o:importConstants var="literal" type="util.IntegerConstants"/>
DATA_TABLE_PAGE_LINKS : #{literal.DATA_TABLE_PAGE_LINKS.value}
Apparently, the value const appears to have been reserved somewhere but that's too difficult to believe because the same thing with the value const works fine in another application as mentioned above!
This is more related to EL than to JSF/Spring/OmniFaces. The Apache EL implementation as used by Tomcat is indeed quite restrictive as to reserved keywords. So is for example #{bean.class.name} (as in, print bean.getClass().getName()) possible in Oracle EL implementation as used by GlassFish, but not in Apache EL implementation as used by Tomcat. You should instead be writing it as #{bean['class'].name}. All other Java keywords listed in chapter 3.9 of Java Language specification which are not listed in chapter 1.17 of EL specification are also blocked by the Apache EL implementation. The const is indeed among them.
On a side note, it's recommended to start the constants var with an uppercase. This convention allows better distinguishing between managed bean instances and constant references in the EL scope. It also instantly solves your problem as Const is not the same as const.
<o:importConstants var="Const" type="util.IntegerConstants" />
DATA_TABLE_PAGE_LINKS : #{Const.DATA_TABLE_PAGE_LINKS.value}
Or just rename the enum, the var defaults namely to Class#getSimpleName().
<o:importConstants type="util.Const" />
DATA_TABLE_PAGE_LINKS : #{Const.DATA_TABLE_PAGE_LINKS.value}

role attribute of h:panelGrid

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.

Jsf default textbox value

I would like to find out how to set the default value for the textbox field in JSF, the field will be empty onFocus. If the user does not enter any value it will again show the default value.
I was able to find the solution using JS with regular html textbox but could not find anything Using JSF.
<h:inputText id="DT_INPUT" value="#{examplebean.date}" maxlength="11" size="10" />
something like
<h:inputText id="DT_INPUT" value="dd-MMM-yyyy" maxlength="11" size="10" />
but how to tie the actual value back to the bean?
Thanks,
Sai.
I would recommend you to look at some component libraries which already have components with necessary functionality. As I understand it's a jsf way. Here is an example of input text with hint.
PrimeFaces has a watermark component;
http://www.primefaces.org/showcase/ui/watermark.jsf
As a completely different alternative without the need for component libraries, you could also achieve this with just a h:outputLabel and a good shot of CSS/JS.
JSF:
<h:form id="form">
<h:outputLabel for="inputId" value="dd-MM-yyyy" />
<h:inputText id="inputId" value="#{bean.date}" />
</h:form>
CSS:
#form label {
position: absolute;
cursor: text;
color: gray;
padding: 2px;
}
JS (actually using jQuery since it insanely eases DOM traversion and manipulation):
$(document).ready(function() {
$('#form input').focus(function() {
$('label[for=' + $(this).attr('id') + ']').hide();
}).blur(function() {
if (!$(this).val().length) $('label[for=' + $(this).attr('id') + ']').show();
});
});
Here's a live demo (based on plain HTML).
you can set an initial value to examplebean.date (in the java code or the bean), and it will appear in the text field
what works with plain html, works with jsf as well, because it's transformed into html
for date components, look at richfaces, primefaces, icefaces, trinidad, etc for ready-to-use calendar components.
If I understand your question correctly, your example works okay as JSF. The tag h: implies that you are using JSF already.
In JSF , The Screen components (in HTML Terms - Input Controls) are bound to a java class properties (or Attributes) , When the JSF Page is rendered (Please refer to Debug JSF Life Cycle ), the default or the manually set values are set (if request scoped).
The values are set and retrieved using Java Expression Language.
In your example, value="#{examplebean.date}" , examplebean is your bean (which you should have configured in your faces-config) and date is the attribute (for which you will have a corresponding setter and getter) - accessing the java class properties at run time is the biggest advantage of Expression Language.
Refer BalusC Posts, Get JSF API's , Expression Language in Sun sites.

Resources