OmniFaces:SelectItemsConverter not working with PrimeFaces: PickList - jsf

I'm trying to use SelectItemsConverter with PrimeFaces Picklist.
XHTML:
<p:pickList id="plUpdateFirma" value="#{bsvttController.dlmFirma}" var="plFirma"
itemLabel="#{plFirma.schluesselFirma}" itemValue="#{plFirma}"
converter="FirmaConverter">
<f:facet name="sourceCaption">
Vorjahr
</f:facet>
<f:facet name="targetCaption">
#{bsvttController.selSaison}
</f:facet>
<p:column>
#{plFirma.schluesselFirma}
</p:column>
</p:pickList>
Converter:
#FacesConverter(value = "FirmaConverter")
public class FirmaConverter extends SelectItemsConverter
{
#Override
public String getAsString(final FacesContext facesContext, final UIComponent component, final Object object)
{
return ((Firma) object).getSchluesselFirma();
}
}
Bean:
#ManagedBean
#ViewScoped
public class BsvttController implements Serializable
{
private DualListModel<Firma> dlmFirma;
private List<Firma> dlmFirmaSource;
private List<Firma> dlmFirmaTarget;
private Firma firma;
#PostConstruct
public void init()
{
dlmFirmaSource = FirmaPersistenz.leseFirmaAlle();
dlmFirmaTarget = new ArrayList<Firma>();
dlmFirma = new DualListModel<>(dlmFirmaSource, dlmFirmaTarget);
}
public DualListModel<Firma> getDlmFirma()
{
return dlmFirma;
}
public List<Firma> getDlmFirmaSource()
{
return dlmFirmaSource;
}
public List<Firma> getDlmFirmaTarget()
{
return dlmFirmaTarget;
}
public void setDlmFirma(DualListModel<Firma> dlmFirma)
{
this.dlmFirma = dlmFirma;
}
public void setDlmFirmaSource(List<Firma> dlmFirmaSource)
{
this.dlmFirmaSource = dlmFirmaSource;
}
public void setDlmFirmaTarget(List<Firma> dlmFirmaTarget)
{
this.dlmFirmaTarget = dlmFirmaTarget;
}
}
While debugging converter I could see that getAsString method is working fine. But after submitting the form both arraylists (dlmFirmaSource and dlmFirmaTarget) are empty.
OmniFaces showcase says that
"The omnifaces.SelectItemsConverter allows you to populate e.g. a drop-down with complex Java model objects as value of f:selectItems and have JSF convert those automatically back without the need to provide a custom converter which may need to do the job based on possibly expensive service/DAO operations."
But in case of PickList component there doesn't exist any f:selectItems tag.
Does SelectItemsConverter even support PickList component?

Does SelectItemsConverter even support PickList component?
No, it doesn't.
Since OmniFaces 1.5, you can use omnifaces.ListConverter or omnifaces.ListIndexConverter for the desired purpose. See also the ListConverter showcase example which also demonstrates the usage on <p:pickList>.

No, the SelectItemsConverter handles conversion of core JSF SelectItem objects for use with various JSF components.
The class DualListModel is a PrimeFaces specific class meant for use with advanced PrimeFaces data components. The workaround of course is to possible use a #PostConstruct method to initialize your DualListModel in the managed bean so that it does not require a converter, or you can simply implement the converter in the traditional way. From the PrimeFaces guide on the converter attribute of Pick List:
An el expression or a literal text that defines a
converter for the component. When it’s an EL
expression, it’s resolved to a converter instance.
In case it’s a static text, it must refer to a
converter id

Related

Composite Component inside ui:repeat: How to correctly save component state

I have a custom component that implements UIInput and that needs to save some state info for later reuse in postback requests. Used standalone it works fine, but inside an <ui:repeat> the postback finds the saved state of the latest rendered row of data. The log output of an action call is
INFORMATION: myData is "third foo"
INFORMATION: myData is "third foo"
INFORMATION: myData is "third foo"
INFORMATION: ok action
where I would expect
INFORMATION: myData is "first foo"
INFORMATION: myData is "second foo"
INFORMATION: myData is "third foo"
INFORMATION: ok action
I understand that myComponent is a single instance inside of ui:repeat. So what is the best way to save component state so it is restored correctly for each row in the dataset?
My XHTML form:
<h:form>
<ui:repeat var="s" value="#{myController.data}">
<my:myComponent data="#{s}"/>
</ui:repeat>
<h:commandButton action="#{myController.okAction}" value="ok">
<f:ajax execute="#form" render="#form"/>
</h:commandButton>
</h:form>
My Bean:
#Named
#ViewScoped
public class MyController implements Serializable {
private static final long serialVersionUID = -2916212210553809L;
private static final Logger LOG = Logger.getLogger(MyController.class.getName());
public List<String> getData() {
return Arrays.asList("first","second","third");
}
public void okAction() {
LOG.info("ok action");
}
}
Composite component XHTML code:
<ui:component xmlns="http://www.w3.org/1999/xhtml"
xmlns:h="http://xmlns.jcp.org/jsf/html"
xmlns:ui="http://xmlns.jcp.org/jsf/facelets"
xmlns:cc="http://xmlns.jcp.org/jsf/composite">
<cc:interface componentType="myComponent">
<cc:attribute name="data"/>
</cc:interface>
<cc:implementation>
<h:panelGrid columns="2">
<h:outputLabel value="cc.attrs.data"/>
<h:outputText value="#{cc.attrs.data}"/>
<h:outputLabel value="cc.myData"/>
<h:outputText value="#{cc.myData}"/>
</h:panelGrid>
</cc:implementation>
</ui:component>
Composite Component backing class:
#FacesComponent
public class MyComponent extends UIInput implements NamingContainer {
private static final Logger LOG=Logger.getLogger(MyComponent.class.getName());
public String calculateData() {
return String.format("%s foo", this.getAttributes().get("data") );
}
public String getMyData() {
return (String)getStateHelper().get("MYDATA");
}
public void setMyData( String data ) {
getStateHelper().put("MYDATA", data);
}
#Override
public String getFamily() {
return UINamingContainer.COMPONENT_FAMILY;
}
#Override
public void encodeBegin(FacesContext context) throws IOException {
this.setMyData( calculateData() );
super.encodeBegin(context);
}
#Override
public void processDecodes(FacesContext context) {
super.processDecodes(context);
LOG.log(Level.INFO, "myData {0}", getMyData() );
}
}
Just tried reproducing your issue and yes, now I get what you're after all. You just wanted to use the JSF component state as some sort of view scope for the calculated variables. I can understand that. The observed behavior is indeed unexpected.
In a nutshell, this is explained in this blog of Leonardo Uribe (MyFaces committer): JSF component state per row for datatables.
The reason behind this behavior is tags like h:dataTable or ui:repeat only save properties related with EditableValueHolder interface (value, submittedValue, localValueSet, valid). So, a common hack found to make it work correctly is extend your component from UIInput or use EditableValueHolder interface, and store the state you want to preserve per row inside "value" field.
[...]
Since JSF 2.1, UIData implementation has a new property called rowStatePreserved. Right now this property does not appear on facelets taglib documentation for h:dataTable, but on the javadoc for UIData there is. So the fix is very simple, just add rowStatePreserved="true" in your h:dataTable tag:
In the end, you have basically 3 options:
Use UIInput#value instead of something custom like MYDATA
As instructed by the abovementioned blog, just replace getMyData() and setMyData() by the existing getValue() and setValue() methods from UIInput. Your composite component already extends from it.
#Override
public void encodeBegin(FacesContext context) throws IOException {
this.setValue(calculateData()); // setValue instead of setMyData
super.encodeBegin(context);
}
#Override
public void processDecodes(FacesContext context) {
super.processDecodes(context);
LOG.log(Level.INFO, "myData {0}", getValue() ); // getValue instead of getMyData
}
And equivalently in the XHTML implementation (by the way, the <h:outputText> is unnecessary here):
<h:outputText value="#{cc.value}" /> <!-- cc.value instead of cc.myData -->
However, this didn't really work when I tried it on Mojarra 2.3.14. It turns out that Mojarra's implementation of the <ui:repeat> indeed restores the EditableValueHolder state during restore view (yay!), but then completely clears out it during decode (huh?), turning this a bit useless. I'm frankly not sure why it is doing that. I have also found in Mojarra's UIRepeat source code that it doesn't do that when it's nested in another UIData or UIRepeat. So the following little trick of putting it in another UIRepeat attempting to iterate over an empty string made it work:
<ui:repeat value="#{''}">
<ui:repeat value="#{myController.data}" var="s">
<my:myComponent data="#{s}" />
</ui:repeat>
</ui:repeat>
Remarkably is that nothing of this all worked in MyFaces 2.3.6. I haven't debugged it any further.
Replace <ui:repeat> by <h:dataTable rowStatePreserved="true">
As hinted in the abovementioned blog, this is indeed documented in UIData javadoc. Just replace <ui:repeat> by <h:dataTable> and explicitly set its rowStatePreserved attribute to true. You can just keep using your MYDATA attribute in the state.
<h:dataTable value="#{myController.data}" var="s" rowStatePreserved="true">
<h:column><my:myComponent data="#{s}" /></h:column>
</h:dataTable>
This worked for me in both Mojarra 2.3.14 and MyFaces 2.3.6.
This is unfortunately not supported on UIRepeat. So you'll have to live with a potentially unnecessary HTML <table> markup generated by the <h:dataTable>. It was during JSF 2.3 work however discussed once to add the functionality to UIRepeat, but unfortunately nothing was done before JSF 2.3 release.
Include getClientId() in state key
As suggested by Selaron in your question's comments, store the client ID along as key in the state.
public String getMyData() {
return (String) getStateHelper().get("MYDATA." + getClientId());
}
public void setMyData(String data) {
getStateHelper().put("MYDATA." + getClientId(), data);
}
Whilst it's a relatively trivial change, it's awkward. This does not infer portability at all. You'd have to hesitate and think twice every time you implement a new (composite) component property which should be saved in JSF state. You'd really expect JSF to automatically take care of this.

JSF reloading ViewParam after commandButton action

I'm using JSF and Primefaces. I have an edit.xhtml page with a f:viewParam receiving an entity id:
<f:viewParam name="id" value="#{backingBean.entity}" converter="entityConverter" />
I have two commandButton, one to submit and save the entity:
<p:commandButton ajax="false" value="#{bundle.save}"
action="#{backingBean.save()}"/>
Another to add an item to a collection of the entity:
<p:commandButton ajax="true" process="#this" value="#{bundle.add}"
actionListener="#{backingBean.addItem()}" />
This is my BackingBean:
#ViewScoped
#Named("backingBean")
public class BackingBean {
#EJB
MyDAO myDAO;
private Entity entity; //with getters and setters
public void addItem() {
entity.getData().add(new Item()); //another entity object
}
public void save(){
myDAO.save(entity);
}
...
}
Also I have an EntityConverter class that invoques the DAO and load the object:
#Override
public Object getAsObject(FacesContext context, UIComponent component, String value) {
try {
return myDAO.findById(Entity.class, Long.valueOf(value));
} catch (Exception e) {
return null;
}
}
If I try to add more than one items or if I click on save button, the Entity in the BackingBean class is reloaded by calling the getAsObject method of the converter class.
What I'm doing wrong?
Thanks!
For clarity the normal f:param will always behave that way. I use in all my projects OmniFaces ViewParam which fixes these issues.
Stateless mode to avoid unnecessary conversion, validation and model updating on postbacks
The standard UIViewParameter implementation calls the model setter
again after postback. This is not always desired when being bound to a
view scoped bean and can lead to performance problems when combined
with an expensive converter. To solve this, this component by default
stores the submitted value as a component property instead of in the
model (and thus in the view state in case the binding is to a view
scoped bean).
The standard UIViewParameter implementation calls the converter and
validators again on postbacks. This is not always desired when you
have e.g. a required="true", but the parameter is not retained on form
submit. You would need to retain it on every single command
link/button by . To solve this, this component doesn't call
the converter and validators again on postbacks.

Can JSF converter work with objects of different types which implements the same interface, is it possible?

I have different objects which all implements the same interfaces. All of these objects need to be selectable by <p:selectCheckboxMenu/>. Default values for those objects and selected values are placed in same Map<?,?>, and few such Maps grouped together inside another Map. It sounds complicated but please look at the code below and all will be clear.
When I select an object, converter get a list of all objects from MyBean (CDI bean), looking by uuid required object and return it, without throwing any exception. The problem begins when I try to work with selected objects. For example this line of code inside:
onObjectChange() method from MyBean:
List<AllObjects> objects= objectContainer.getControllers().get("Object 1").get("selected");
throws an exception:
java.lang.ClassCastException: [Ljava.lang.Object; incompatible with java.util.List
And indeed when I hover mouse over objectContainer I see that it contains object of type selected=[Ljava.lang.Object;#dba1b6e7} But when I evaluate same line of code inside Expressions panel of Eclipse I get the required values: MyObject1#d8f0f5f8
I don't understand in general is it possible to do what am I doing, i.e. few different objects with same interface to be selectable by <p:selectCheckboxMenu/>. And if yes, why do I have this casting problem? My colleague said that it might be a problem with my converter and I tend to agree with she, but don't know is it correct and if yes, how to solve it.
UPDATE: It looks that problem not inside Converter but due to fact that I pass Collection to collect selected values dynamically, as a value of <ui:param/>. I pass it as List<AllObjects> and get it back as Object. I can cast it then to Object[] and every object inside it to appropriated object by using introspection and it works. But why it mutates initial object? It shouldn't do this.
Thank you in advance and my code below:
This is an interface:
public interfaces AllObjects{
public String getName();
}
There are multiple objects, MyObject, MyObject1, MyObject2 which implement interfaces above:
public MyObject implements AllObjects{
...
}
This is my bean and how my objects are initialized:
public MyBean {
Map<String, Map<String,List<AllObjects>>> objectContainer = new LinkedHashMap<String, Map<String,List<AllObjects>>>();
public void init(){
Map<String,List<AllObjects>> nameValuesPairs1 = new LinkedHashMap<String,List<AllObjects>>();
List<AllObjects> allSelectedObjects1 = new ArrayList<AllObjects>();
List<AllObjects> allDefaultObjects1 = new ArrayList<AllObjects>();
nameValuesPairs.put("default",allDefaultObjects1);
nameValuesPairs.put("selected",allSelectedObjects1);
Map<String,List<AllObjects>> nameValuesPairs2 = new LinkedHashMap<String,List<AllObjects>>();
List<AllObjects> allSelectedObjects2 = new ArrayList<AllObjects>();
List<AllObjects> allDefaultObjects2 = new ArrayList<AllObjects>();
nameValuesPairs.put("default",allDefaultObjects2);
nameValuesPairs.put("selected",allSelectedObjects2);
objectContainer.put("Object 1", nameValuesPairs1);
objectContainer.put("Object 2", nameValuesPairs2);
}
public void onObjectChange(){
...
List<AllObjects> objects= objectContainer .getControllers().get("Object 1").get("selected"); //throws exception
...
}
}
My *.xhtml page:
<h:panelGroup id="object_panel">
<ui:repeat id="objects_id" var="object" value="#{myBean.objectContainer.entrySet().toArray()}">
<p:selectCheckboxMenu
value="#{object.value['selected']}" label="#{object.key}"
converter="#{myObjectConverter}"
filter="true"
filterMatchMode="startsWith"
panelStyle="width:250px">
<f:selectItems value="#{object.value['default']}" var="value" itemValue="#{value}" itemLabel="#{value.name}" />
<p:ajax event="change" process="#this #parent" listener="#{myBean.onObjectChange}"/>
</p:selectCheckboxMenu>
</ui:repeat>
</h:panelGroup>
And converter:
public class ChartParameterConverter implements Converter, Serializable {
#Inject
private MyBean myBean;
#Override
public Object getAsObject(FacesContext context, UIComponent component, String value) throws ConverterException {
AllObjects result = null;
...
//here to result assigned MyObject1 or MyObject2 type depends on condition and it being returned
...
return result;
}
...
}
Ok, it looks that <ui:repeat> and <p:selectCheckboxMenu> not work well with DataModel which I used, Map<String,Map<String,List<MyObject>>>. I've changed my DataModel in the following way:
public ObjectContainer{
private String name;
private List<MyObject> defaultObjects;
private List<MyObject> selectedObbjects;
}
and pass to <ui:param> it as List<ObjectContainer>. so my *.xhtml page looks in the following way:
<p:selectCheckboxMenu
value="#{object.selectedObjects}" label="#{object.name}"
converter="#{myObjectConverter}"
filter="true"
filterMatchMode="startsWith"
panelStyle="width:250px">
<f:selectItems value="#{object.defaultObjects}" var="value" itemValue="#{value}" itemLabel="#{value.name}" />
<p:ajax event="change" process="#this #parent" listener="#{myBean.onObjectChange}"/>
</p:selectCheckboxMenu>
</ui:repeat>
And now everything works as it should.
And I throwed away my custom converter and use SelectItemsConverter from Omnifaces's library. Highly recommended change, code become much simpler and readable.
You could do a unique Tuple for each Object, The Tuple must be converted to unique String.. And you could have the posible values in a Array..
static Map<String,Object> uniques = new LinkedHashMap<>();
static{
//you could save the possible values in a Singleton Bean
uniques.put(key,value)...
}
In your Converter
getAsString -> Return a Key from Value
getAsObject -> Return a Value by Key

JSF selectOneMenu - setting value in bean

I have selectOneMenu
<h:selectOneMenu id = "current" value = "#{helloBean.currentLanguage}">
<f:selectItems value="#{helloBean.categoryLanguages}"></f:selectItems>
<f:ajax render = "ccData"></f:ajax>
</h:selectOneMenu>
Here is HelloBean
#ManagedBean(name="helloBean")
#SessionScoped
public class HelloBean implements Serializable {
private String currentLanguage;
public void setcurrentLanguage(String currentLanguage){
this.currentLanguage = currentLanguage;
}
}
I have a problem with setting of currentLanguage. Eclipse shows an error message that #{helloBean.currentLanguage} expression is not settable. And when I run my project, I get an error
javax.servlet.ServletException: /hello.xhtml #19,74 value="#{helloBean.currentLanguage}": Property 'currentLanguage' not readable on type java.lang.String
As BalusC pointed out, Java is case sensitive.
So when you write: value=#{helloBean.currentLanguage} JSF expects that you define a setter and a getter of that attribute (currentLanguage):
public void setCurrentLanguage(String language){
this.currentLanguage = language;//Or whatever
}
(Notice the upper C in current. And add a getter)
Since you are using Eclipse, try to automatically generate access methods of your classes. (Right click -> source -> generate getter and setters)

Difference between value and binding

What is the difference between using value and binding with JavaServer Faces, and when would you use one as opposed to the other? To make it clearer what my question is, a couple of simple examples are given here.
Normally with JSF in the XHTML code you would use "value" as here:
<h:form>
<h:inputText value="#{hello.inputText}"/>
<h:commandButton value="Click Me!" action="#{hello.action}"/>
<h:outputText value="#{hello.outputText}"/>
</h:form>
Then the bean is:
// Imports
#ManagedBean(name="hello")
#RequestScoped
public class Hello implements Serializable {
private String inputText;
private String outputText;
public void setInputText(String inputText) {
this.inputText = inputText;
}
public String getInputText() {
return inputText;
}
// Other getters and setters etc.
// Other methods etc.
public String action() {
// Do other things
return "success";
}
}
However, when using "binding", the XHTML code is:
<h:form>
<h:inputText binding="#{backing_hello.inputText}"/>
<h:commandButton value="Click Me!" action="#{backing_hello.action}"/>
<h:outputText value="Hello!" binding="#{backing_hello.outputText}"/>
</h:form>
and the correspondibg bean is called a backing bean, and is here:
// Imports
#ManagedBean(name="backing_hello")
#RequestScoped
public class Hello implements Serializable {
private HtmlInputText inputText;
private HtmlOutputText outputText;
public void setInputText(HtmlInputText inputText) {
this.inputText = inputText;
}
public HtmlInputText getInputText() {
return inputText;
}
// Other getters and setters etc.
// Other methods etc.
public String action() {
// Do other things
return "success";
}
}
What practical differences are there between the two systems, and when would you use a backing bean rather than a regular bean? Is it possible to use both?
I have been confused about this for some time, and would most appreciate having this cleared up.
value attribute represents the value of the component. It is the text that you see inside your text box when you open the page in browser.
binding attribute is used to bind your component to a bean property. For an example in your code your inputText component is bound to the bean like this.
#{backing_hello.inputText}`
It means that you can access the whole component and all its properties in your code as a UIComponent object. You can do lot of works with the component because now it is available in your java code.
For an example you can change its style like this.
public HtmlInputText getInputText() {
inputText.setStyle("color:red");
return inputText;
}
Or simply to disable the component according to a bean property
if(someBoolean) {
inputText.setDisabled(true);
}
and so on....
Sometimes we don't really need to apply the value of UIComponent to a bean property. For example you might need to access the UIComponent and work with it without applying its value to the model property. In such cases it's good to use a backing bean rather than a regular bean. On the other hand in some situations we might need to work with the values of the UIComponent without any need of programmatic access to them. In this case you can just go with the regular beans.
So, the rule is that use a backing bean only when you need programmatic access to the components declared in the view. In other cases use the regular beans.

Resources