JSF: Ternary operator used to assign a value to an <f:param> fails - jsf

I am using JSF tags within an XHTML file. My intention is to enable or disable a <rich:MenuItem> context-menu item by setting the "disabled" attribute to "true" or "false" appropriately. To do this, I am using a backing bean variable in a ternary operator and setting an <f:param> value to either "true" or "false" based on the bean variable, as below:
<rich:componentControl event="oncontextmenu" for="network-tree-menu"
operation="show">
<f:param id="nestlevel" value="#{item.nestLevel > 10 ? 'true' : 'false'}"
name="nestlevel" />
</rich:componentControl>
where item is the backing bean and item.nestLevel is an integer.
I am using this <f:param> value later in the XHTML file as below:
<rich:contextMenu ...
<rich:menuItem id="abc" ajaxSingle="true" disabled="{nestlevel}"
onclick="doSomething();" value="Do something...">
</rich:contextMenu>
This is not working !! The menu item is always enabled, (I guess this is the default behaviour) even though the result of the ternary operation is "true". Is there something I am missing here w.r.t the syntax, or is there some other way I can do this conditional enabling of context-menu items within the XHTML file?
Thanks in advance.
Regards,
Nagendra U M

How about this:
<f:param id="nestlevel" value="#{item.nestLevel > 10}" name="nestlevel" />

Related

javax.el.PropertyNotWritableException when using EL conditional operator in value of UIInput

I get this error message:
javax.el.PropertyNotWritableException: /u/editProfile.xhtml #64,140 value="#{empty userProfile.cfg.gpu or userProfile.cfg.gpu == '' ? usernavmsg.EditMe: userProfile.cfg.gpu}": null
The problem is that when the value of a bean property is null the value of an inputText field switches from my ManagedBean property, to a resource string. So I cannot persist that value.
I request the profile of the user from my database in my managed bean. If a property of the said profile is null, the inplace text holder value is "Edit Me". If it's not null it's the value of that property. Which is working ! However when I submit the form and try to persist a new value or no value at all the error appears. The error only appears for the field that are null to begin with (when I requested them from the db). So the problem is that when the value is null it switch from my ManagedBean property, to a resource string.
I just have a form with this:
<h:outputLabel value="#{usernavmsg.GPU}: "/>
<p:inplace styleClass="lessDark">
<p:inputText value="#{empty userProfile.cfg.gpu ? usernavmsg.EditMe: userProfile.cfg.gpu}" />
</p:inplace>
when I submit the form I want to persist userProfile.cfg in the database which doesn't happen.
Can I work around this ? Is it even possible ?
Conditional statements in EL are indeed not writable. They are read-only. End of story. The same applies to method references in EL as in #{bean.property()}. It must really be a true value expression as in #{bean.property}.
Your approach of using a (HTML5) "placeholder" is actually wrong. For that you should be using the placeholder attribute, not the value attribute. In older versions of PrimeFaces that do not have a placeholder attribute you'll need passthrough.
<html ... xmlns:a="http://xmlns.jcp.org/jsf/passthrough">
...
<p:inputText value="#{userProfile.cfg.gpu}" a:placeholder="#{usernavmsg.EditMe}" ... />
Nowadays PrimeFaces offers a placeholder attribute.
<p:inputText value="#{userProfile.cfg.gpu}" placeholder="#{usernavmsg.EditMe}" ... />

JSF input processing order

Is there a way to specify the order in which the inputs should be set after a submit?
Here is my case:
<h:inputText id="fieldA" value=#{myBean.myObject.fieldA}" />
<h:inputText id="fieldB" value=#{myBean.myObject.fieldB}" />
<p:autoComplete id="myObject" value=#{myBean.myObject" converter="myObjectConverter" />
<h:inputText id="fieldC" value=#{myBean.myObject.fieldD}" />
<h:inputText id="fieldD" value=#{myBean.myObject.fieldC}" />
The issue I am encountering is that, as the inputs are processed in the ordered they are declared, fieldA and fieldB are set in the initial instance of myObject, then myObject is set (with a new instance thus filedA and fieldB values are lost), and finally fieldC and fieldD are set with no problem.
If I could manage to start by setting myObject first, that would solve my problem.
I will temporarily set the fields and myObject into two different attributes of my bean, and populate myObject after clicking a save button. But it looks more like a hack than a real solution.
Needless to say that declaring the autocomplete before the inputtexts is not an option.
Thanks in advance.
In shortcut:
You can use <p:inputText> tag from primefaces. Then, you can disable all inputs. Add ajax to your autoComplete, and update other inputs after processing autoComplete. Inputs disable attribute can be set to depend on whether the autoComplete is not null. This way you will make the user to enter the autoComplet first.
you can try to set immediate="true" to p:autocomplete, so that it will be processed in the APPLY_REQUEST_VALUES phase, before all other components.
The simple solution is to update h:inputTexts when p:autocomplete item is selected to reflect its values:
<p:autoComplete id="myObject" value="#{myBean.myObject}" ...>
<p:ajax event="itemSelect" process="#this" update="fieldA fieldB fieldC fieldD" />
</p:autoComplete>
but this reverts user inputs on h:inputTexts. And since you can't move p:autocomplete on top, probably this is not acceptable too.
In case you can't/don't want to use ajax, you can force an early model update:
<p:autoComplete id="myObject" value="#{myBean.myObject}" immediate="true"
valueChangeListener="#{component.updateModel(facesContext)}" ... />
but, in my opinion, this is not very user friendly...
P.S. this time it's tested :)
There's no pretty way to get around this; your situation is already less than ideal and is hacky (re: not being able to simply reorder the fields). One workaround is for you to set fieldA and fieldB as attributes of myObject. In the converter, you could then pull the values off the components. Observe
Set attributes thus
<h:inputText id="fieldA" binding=#{fieldA}" />
<h:inputText id="fieldB" binding=#{fieldB}" />
<p:autoComplete id="myObject" value=#{myBean.myObject" converter="myObjectConverter">
<f:attribute name="fieldA" value="#{fieldA}"/>
<f:attribute name="fieldB" value="#{fieldB}"/>
</p:autoComplete>
The binding attribute effectively turns those components into page-scoped variables, allowing you to then pass them as attributes on your p:autocomplete
Get the values of those variables in your converter
//Retrieve the fields and cast to UIInput, necessary
//to retrieve the submitted values
UIInput fieldA = (UIInput) component.getAttributes().get("fieldA");
UIInput fieldB = (UIInput) component.getAttributes().get("fieldB");
//Retrieve the submitted values and do whatever you need to do
String valueA = fieldA.getSubmittedValue().toString();
String valueB = fieldB.getSubmittedValue().toString();
More importantly, why can't you just reorder the fields/logical flow of your form? You can avoid all this nasty business if you did

JSF commandLink onclick EL expression re-evaluation

I have a JSF command like this:
<h:commandLink id="testId" onclick="if (#{bean.isPageOpen}) dlg.show();" />
The boolean bean.isPageOpen was false initially so the dlg widget was not opened. Now when I change the condition i.e. bean.isPageOpen returns true, the widget still does not get open.
Is the EL expression evaluated only once and never again for JSF commandLink?
Thanks,
-csn
Javascript codes is producing on page load. If you check your page source , You can see your onclick like this.
onclick="if (false) dlg.show();"
If you want to use updated value in your bean.You might use structure like this.I'm using primefaces.
<p:inputText id="textId" value="#{{bean.isPageOpen}" />
<h:commandLink id="testId" onclick="refresh(); if (document.getElementById('textId').value=='true') dlg.show();" />
<p:remoteCommand name="refresh" actionListener="#{bean.updateisPageOpen}" update ="textId"/>

<c:when test> evaluates always false

This is called 3 times, for each row once. (example table has 3 rows)
....
<ui:param name="rowIndex" value="#{cc.attrs.rowIndex}" />
<ui:param name="rowActive" value="#{cc.attrs.activeRow}" />
<c:set var="index" value="#{rowIndex}" type="java.lang.Long"/>
<c:set var="activeRowIndex" value="#{rowActive}" type="java.lang.Long"/>
<c:choose>
<c:when test="${index == 2}">
ACTIVE
</c:when>
<c:when test="${index != activeRowIndex}">
${index} - ${activeRowIndex} - INACTIVE
</c:when>
<c:otherwise>
NONE
</c:otherwise>
</c:choose>
....
Result:
0 - 1 - INACTIVE
1 - 1 - INACTIVE
2 - 1 - INACTIVE
I would have expected:
0 - 1 - INACTIVE
NONE
ACTIVE
I'm quite clueless why the result is so different from what i expected.
So i hope you can help me :-)
The variable names used suggests that you're using the composite inside a repeating component, such as <h:dataTable> or <ui:repeat>.
JSTL tags are executed during view build time, that moment when the JSF component tree is built based on XHTML source code. However, the var attribute of a repeating component is only available during view render time, that moment when the HTML output is produced based on JSF component tree.
In effects, at least the #{cc.attrs.rowIndex} is always null when JSTL runs.
When you're dependent on conditions which are only available during view render time, then you should be using the rendered attribute of a JSF component instead of JSTL <c:choose>/<c:if>.
E.g.
<c:set var="active" value="#{cc.attrs.rowIndex == 2}" />
<c:set var="inactive" value="#{not active and cc.attrs.rowIndex != cc.attrs.activeRow}" />
<c:set var="none" value="#{not active and not inactive}" />
<h:outputText value="ACTIVE" rendered="#{active}" />
<h:outputText value="#{index} - #{activeRowIndex} - INACTIVE" rendered="#{inactive}" />
<h:outputText value="NONE" rendered="#{none}" />
Note that this problem doesn't affect the <c:set>. It merely creates a EL variable mapping (an "alias"), it doesn't immediately evaluate the EL expression and store its result somewhere (as long as scope isn't definied). Also note that ${} and #{} behave exactly the same when Facelets is used instead of JSP. As the ${} is basically a heritage of legacy JSP, you should prefer exclusively using #{} to avoid confusion by yourself and your future maintainers.

Facelets: ui:param default value

How can one define a default value for a facelet template parameter?
Consider the following element using a template parameter:
<h:outputText value="#{templParam}"></h:outputText>
The above line will print the the template parameter templParam which is passed by a ui:param tag in a ui:composition using the template:
<ui:param name="templParam" value="Hello world"></ui:param>
But if ui:param tag is missing nothing will be printed. Although, how can one print e.g "Default value" in this case?
Could use this:
<h:outputText value="#{empty templParam ? 'Default value' : templParam}" />
I hope it helps.
A default value can be defined by using a ternary operator checking for null value.
<h:outputText value="#{templParam != null ? templParam : 'Default value'}"></h:outputText>
This will print "Default value" if the parameter was not passed by a ui:param tag.
After the composition tag to define the start of the template, the template parameter can be set to its default value (if it is empty) so that all following uses of it don't require checking for a null each time (and its default value is in one place in the code).
<html xmlns:c="http://java.sun.com/jsp/jstl/core" >
<ui:composition>
<c:set var="templParam" value="#{empty templParam ? 'Default value' : templParam}"
scope="request" />
<h:outputText value="Use 1: #{templParam}" />
<h:outputText value="Use 2: #{templParam}" />

Resources