There are couple of limitation(defect?) of jsf which causes this issue.
<ui:repeat value="#{myBean.myAttrs}" var="attr">
<h:outputText value="#{myBean.selectedObj.values[attr.name]}"
rendered="#{attr.dataType=='Text'}"/>
<h:selectBooleanCheckbox value="#{myBean.selectedObj.values[attr.name]}"
rendered="#{attr.dataType=='Boolean'}"/>
.... render other data type like list, date etc.
</ui:repeat>
First "render" property limitation in jsf, the component is still processed even render is false. This causes every attr type in ui:repeat will try to evaluate value for each output component. i.e. value of selectBooleanCheckbox will try to evaluate for date type. If render is false, the component won't be rendered eventually. Everything is fine even with this issue if without selectBooleanCheckbox(2nd issue).
Second issue, selectBooleanCheckbox will always assume the input value is Boolean type. So evaluate value (due to 1st issue) will fail for date type.
Is this code sniper common for display different data type dynamically in JSF? I tried to configure customization renderer, converter for the selectBooleanCheckbox. But it still fail with data type convert exception. Any idea? How to change the default "expectedType" for selectBooleanCheckBox from "Boolean" to "Object" just like other JSF input component.
--Update: the issue is only for mojarra instead of myfaces.
Related
I would like to understand when and how often an attribute's value is updated. I often see that component's attributes are updated even thought I didn't explicitly call an update on the component.
For example:
<p:panel id="panelA"
styleClass="#{controller.conditionA ? '.styleA' : 'styleB'}"
rendered="#{controller.conditionB() }">
</p:panel>
When the conditionB changes from true to false, the panels rendered attribute is updated as well without me calling an updated on the panel with panelA.
How are the both attributes styleClass and rendered evaluated and when?
Are all attributes, which have a non-static value, evaluated and updated periodically?
Instead of the panel, styleClass and rendered there could be other Primefaces components and attributes. I am interested in the general mechanism behind that.
I have a composite component representing a table, that depending on the editable attribute (which I have created) may or may not display links to edit a row.
The edit links are of type <h:commandLink> and have actionListeners pointing to a method in a backing bean. The backing bean for handling editing is provided as a <cc:attribute name="editBean"... /> like the attribute editable, when I want the table to be editable.
If I don't need the table to be editable I set the editable attribute to false and the links rendered attribute gets set to false as well.
My problem is that if I set editable to false and therefore don't set the attribute editBean either, I get errors pointing out that there is no method for handling editing (e.g. java.lang.String does not have the property xxxxx).
I had hoped that as the links are set to not be rendered at all, what has been specified in the action/actionListener would be ignored. To me it feels logical to first check the rendered attribute and then, if it's set to true, check the other attributes.
So, my questions are: why does it work like this and if there's an elegant way of handling this scenario?
Use JSTL <c:if> to conditionally build the component in JSF component tree instead of rendered attribute to conditionally render the HTML output (it's that you're using JSF 2.2, otherwise I'd have explicitly mentioned that this requires a minimum of Mojarra 2.1.18 to avoid broken view state).
<c:if test="#{cc.attrs.editable}">
<h:commandLink ... />
</c:if>
I'm using MyFaces 1.1. I have two <h:selectOneMenu>s dropdowns which each point to same valueChangeListener method.
<h:selectOneMenu id="d1" value="#{mybean.selectedChannel1}"
onchange="submit()" valueChangeListener="#{myform.channelValuechange}">
<f:selectItems value="#{mybean.channelList}"/>
</h:selectOneMenu>
<h:selectOneMenu id="d2" value="#{mybean.selectedChannel2}"
onchange="submit()" valueChangeListener="#{myform.channelValuechange}">
<f:selectItems value="#{mybean.channelList}"/>
</h:selectOneMenu>
When I change the first dropdown, then the value change listener method get fired correctly. In the method, I'm obtaining the ID of the current component as sourceId via ValueChangeEvent argument and then comparing it as follows:
if (sourceId.equals("d1")) {
// ...
} else if (sourceId.equals("d2")) {
// ...
}
However, my concrete problem is that d2 block is also called when d1 is changed.
I tried the one and other and figured that the following helped to solve the problem:
if (!event.getPhaseId().equals(PhaseId.INVOKE_APPLICATION)) {
event.setPhaseId(PhaseId.INVOKE_APPLICATION);
event.queue();
}
However, I don't feel like that it's the best solution. How is this caused and how can I solve it without using the above code?
With onchange="submit()" you're basically submitting the entire form when the current input element is changed, not only the currently changed input! In contrary to what many starters incorrectly think, there is no means of any input-specific JavaScript/Ajax magic here. As you're submitting the entire form, it would trigger the processing of all input components.
The valueChangeListener is always invoked when the submitted value of the input component does not equals() the initial model value as in the backing bean. Given that in your case both menus hit the value change listener when you change only the first one, that can only mean that the default select item value of the second menu does not equals() the initial model value in the backing bean.
You need to make sure that #{mybean.selectedChannel2} of the second menu has by default exactly the same value as the first item of #{mybean.channelList} of the second menu's list. This way the value change listener won't be invoked for the second menu when you change the first menu.
See also:
When to use valueChangeListener or f:ajax listener? (just to learn what's different in JSF 2, for the case you're interested)
I searched everywhere but could not find a solution to this. I am trying to used
required=yes to validate whether a value is present or not. I am using it inside inputtext.
The problem is it does not work inside a datatable. If I put the text box outside the datatable it works. I am using JSF 1.7 so I don't have the validateRequired tag from JSF 2.0.
I even used a validator class but it is still not working. Does anyone know why does required=yes or validator='validationClass' inside a inputtext inside a datatable is not working.
I appreciate the help.
Thanks.
First of all, the proper attribute values of the required attribute are the boolean values true or false, not a string value of Yes. It's an attribute which accepts a boolean expression.
The following are proper usage examples:
<h:inputText required="true" />
<h:inputText required="#{bean.booleanValue}" />
<h:inputText required="#{bean.stringValue == 'Yes'}" />
As to the problem that it doesn't work inside a <h:dataTable>, that can happen when the datamodel is not been preserved properly (the datamodel is whatever the table retrieves in its value attribute). That can in turn happen when the managed bean is request scoped and doesn't prepare the datamodel during its (post)construction which causes that the datamodel is null or empty while JSF is about to gather, convert and validate the submitted values.
You need to ensure that the datamodel is exactly the same during the apply request values phase of the form submit request as it was during the render response phase of the initial request to display the form with the table. An easy quick test is to put the bean in the session scope. If that fixes the problem, then you definitely need to rewrite the datamodel preserving logic. You could also use Tomahawk's <t:saveState> or <t:dataTable preserveDataModel="true"> to store the datamodel in the view scope (like as JSF2's new view scope is doing).
Finally, JSF 1.7 doesn't exist. Perhaps you mean JSF 1.2?
I have a search form tied to a backing bean that contains 4 input text fields. The design i am working from indicates that the user should be able to see the search results, but they should not be editable. i decided to use the rendered attribute to show the inputs if the managed bean is empty, and to show an output text tag if it's not:
<t:inputText styleClass="inputText" id="name" rendered="#{not searchCriteria.fieldsEntered}"
value="#{searchCriteria.name}" autocomplete="off"></t:inputText>
<h:outputText value="#{searchCriteria.name}" rendered="#{searchCriteria.fieldsEntered}"></h:outputText>
The display part works correctly, but I am noticing that only the first field is stored in the managed bean when more than 1 search field is entered.
I removed a rendered attribute from an inputText, and sure enough that's causing my problems. I can infer what's going on here, but I don't understand why.
I believe in this situation I will just remove the outputText tags and change rendered to disabled. I am just curious why my initial plan is incorrect.
The rendered="false" will cause the input element not being rendered and thus its value will not be submitted to the server side. If you're using a request scoped bean, the initial value will not be set. You'd like to either put the bean in session scope or to add a h:inputHidden along the h:outputText which transfers the value to the subsequent request.
Since you're already using Tomahawk's t:inputText I'd suggest to rather use its displayValueOnly attribute instead of the rendered attribute and a complementary h:outputText.
In a nut:
<t:inputText displayValueOnly="#{searchCriteria.fieldsEntered}" ... />