Is there a defined behaviour in JSF, if two input fields are bound to the same session scoped Backing Bean property.
Here is my code snippet
<h:form id="myForm">
<h:inputText id="field1" value="#{TheBackingBean.theProperty}" />
<h:inputText id="field2" value="#{TheBackingBean.theProperty}" />
<h:commandButton id="continueButton" action="#{TheBackingBean.doSomething}" />
</h:form>
My question: If field1 and field2 receive different values, what will be bound to the backing bean property? Is this even allowed?
I know this is a crude scenario. My motivation is, that we have htmlunit tests running for our application. In our JSF application we want to use a cool ajaxified custom component. This doesnt work together very well with htmlunit. So my idea was, I just put in a hidden field that binds to the same property. The unit test then fills the hidden field instead of the "real" thing.
Regards
I think this kind of code is allowed, but I am not sure of the value of theProperty after the submission. What I think is that JSF will do the following:
TheBackingBean.setTheProperty(field1.value);
TheBackingBean.setTheProperty(field2.value);
However, nothing - as far as I know - specifies the order of the setter calls. Thus, after the update values JSF phase, you will not be sure if theProperty will be equal to field1.value or field2.value.
Concerning your scenario, you say that you want to bind the same property to an inputText and an hiddenText. As the hiddenText will not submit its value, unlike the inputText, this problem will not occur. Indeed, if you have this kind of JSF code:
<h:inputText id="field1" value="#{TheBackingBean.theProperty}"/>
<h:inputHidden id="field2" value="#{TheBackingBean.theProperty}"/>
then JSF will only do:
TheBackingBean.setTheProperty(field1.value);
during the submission phase.
Related
We do have a small page which is using the viewParam to convert a given Id to a concrete object. This converter is called on leaving (blur) of an inputText field, which is validated. Why? Could I rework this, so that the converter is not called every time?
This is annoying, because the converter calls the set-method for the corresponding object in the BackingBean and this bean is then null, if the page is called the first time for creating this object.
<f:metadata>
<f:viewParam name="id" value="#{bean.object}"
converter="#{objectConverter}"
converterMessage="#{msgs['converter.msg.object']}"/>
<f:viewAction action="#{bean.init}"/>
</f:metadata>
<p:inputText id="text" value="#{cc.attrs.value}"
styleClass="inputTextValidated"
required="#{cc.attrs.required}"
requiredMessage="#{cc.attrs.requiredmessage}"
label="text" validatorMessage="#{cc.attrs.msg}" title="#cc.attrs.title}"
readonly="#{cc.attrs.readOnly}">
<cc:insertChildren/>
<p:ajax update="msg_text" event="blur"/>
</p:inputText>
<p>
<p:message id="msg_text" for="text" display="msg"/>
</p>
If we do not use a converter but just the viewAction to convert the Id to the corresponding object (or create a new object if applicable), everything is fine. Is this the only/correct solution for this problem?
We do use primefaces 6.1 with CDI. The converter is a #Named and #ApplicationScoped bean implementing the Converter Interface.
Using p:fragment around the inputtext-field did not help either.
That is the nature of how JSF works. If you want to not have it do that I suggest you check out OminFaces ViewParam: http://showcase.omnifaces.org/components/viewParam
From their documentation:
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.
I'm trying to use the setPropertyActionListener tag to set a value in my backing bean. However, it doesn't work as I expected.
Context: userService is an instance of my backing bean, which contains an int member, reqID. This, in turn, is the key to a map of objects that belong to a class called User. I'm trying to create a page that will list all instances of User, and provide a button to visit a separate view that shows that particular User's information. To do this, I'm attempting to set userService.reqID to the id of the chosen User so it can generate a reference to that user for the next view (which is done in the call userService.toUserInfo).
If I use the xhtml snippet below:
<ui:define name="content">
<h:form>
<h:panelGrid>
<ui:repeat value="#{userService.UserList.getUserList()}" var="user">
<li>
<h:outputText value="#{user.name}" />
<h:commandButton value="View details of #{user.name}" action="#{userService.toUserInfo}">
<f:param name="id" value="#{user.id}" />
<f:setPropertyActionListener target="#{userService.reqID}" value="#{id}"/>
</h:commandButton>
</li>
</ui:repeat>
</h:panelGrid>
</h:form>
</ui:define>
The tag does not appear to evaluate id correctly and I get a Null Pointer Exception.
Earlier, I tried changing my setPropertyActionListenerTag so it read out as:
<f:setPropertyActionListener target="#{userService.reqID}" value="id"/>
which gave me an error, because the tag was sending the string "id" as opposed to the int value of the parameter.
Is there some way to force f:setPropertyActionListener to evaluate the expression under value? Or is there another tag that will allow me to do this?
Also, is ui:param used appropriately here?
The <f:param> (and <ui:param>) doesn't work that way. The <f:param> is intented to add HTTP request parameters to outcome of <h:xxxLink> and <h:xxxButton> components, and to parameterize the message format in <h:outputFormat>. The <ui:param> is intented to pass Facelet context parameters to <ui:include>, <ui:decorate> and <ui:define>. Mojarra had the bug that it also behaves like <c:set> without a scope. This is not the intented usage.
Just use <c:set> without a scope if it's absolutely necessary to "alias" a (long) EL expression.
<c:set var="id" value="#{user.id}" />
Put it outside the <h:commandLink> though. Also in this construct, it's kind of weird. It doesn't make the code better. I'd just leave out it.
<f:setPropertyActionListener ... value="#{user.id}" />
See also:
Setting ui:param conditionally
what is the scope of <ui:param> in JSF?
Defining and reusing an EL variable in JSF page
Unrelated to the concrete problem, if you're using EL 2.2 (as you're using JSF 2.2, you undoubtedly are as it requires a minimum of Servlet 3.0, which goes hand in hand with EL 2.2), then just pass it as bean action method argument without <f:setPropertyActionListener> mess. See also a.o. Invoke direct methods or methods with arguments / variables / parameters in EL and How can I pass selected row to commandLink inside dataTable?
<h:commandButton ... action="#{userService.toUserInfo(user.id)}">
On again another unrelated note, such a "View user" or "Edit user" request is usually idempotent. You'd better use <h:link> (yes, with <f:param>) for this. See also a.o. Creating master-detail pages for entities, how to link them and which bean scope to choose and How to navigate in JSF? How to make URL reflect current page (and not previous one).
Oh, that <h:panelGrid> around the <ui:repeat><li> doesn't make sense in HTML perspective. Get rid of it and use <ul> instead. See also HTMLDog HTML Beginner tutorial.
Is there a way to do pass an input value as a action's parameter without using managed properties?
i.e.
<h:form>
<h:inputText id="input" />
<h:commandButton action="#{someBean.doSome(input)}" />
</h:form>
Yes, it's during the form submit already there in the JSF component state. Just bind the input component to the view by binding attribute, which will reference an UIInput instance, which in turn has a getValue() method for the very purpose of retrieving the input value (so that you can pass it as action method argument):
<h:form>
<h:inputText ... binding="#{input}" />
<h:commandButton ... action="#{someBean.doSome(input.value)}" />
</h:form>
The properness of this approach is however highly questionable and depends on concrete functional requirements. This approach is namely basically tight-coupling the view with the model and therefore considered a bad practice.
See also:
How to send form input values and invoke a method in JSF bean
How does the 'binding' attribute work in JSF? When and how should it be used?
I am a JSF beginner. I have a question about managed bean.
Step 0:
There is a managed bean BeanA, scope is request. And BeanA instance1.propertyA = "0";
Step 1:
using ajax to change country, then in BeanA.countryChanged method, change managed bean BeanA.propertyA = "A".
<t:selectOneMenu id="Country" required="true" valueChangeListener="#{BeanA.countryChanged}">
<a4j:support event="onchange" limitToList="true" ajaxSingle="true" />
<f:selectItems value="#{BeanA.countries}" />
</t:selectOneMenu>
Step2:
submit form to do validate a text input
<h:inputText id="street" required="#{BeanA.propertyA == "A"}"
I expect that in step2 the value propertyA of BeanA instance2 should be "A" in JSF validate phase, but actually it is "0". I don't know how does JSF load BeanA instance property values to create new BeanA instance. And what should I do, the value will changed to "A"? Thanks,
The symptoms indicate that your bean is request scoped. This means that it's reconstructed on every single HTTP request. You probably didn't realize that every single ajax request also counts as a separate HTTP request. In effects, you're not reusing the same bean instance across ajax postbacks on the same view. Every time a brand new instance is been created, with all its properties set to default.
JSF 2.0, which is designed with ajax in mind, has solved it with the new view scope in the standard API.
In JSF 1.x, you need to fall back to 3rd party component libraries. In your particular case, given that you're using both Tomahawk and Ajax4jsf, you've 2 options:
Use <t:saveState>.
<t:saveState value="#{BeanA}" />
Or, use <a4j:keepAlive>.
<a4j:keepAlive beanName="BeanA" />
I have an xhtml page as follows
<p:inputText id="inputFilterKey" name="inputFilterKey" value="#{key}" />
<p:commandButton id="filterByKey" action="searchByKey" value="Search" ajax="false">
<f:param name="filterKey" value=? />
</p:commandButton>
The parameter 'filterKey' should have the value which is provided by user in the inputText. Value '#{key}' is the flow scope variable which is defined in spring webflow. That is, it is not taken from a back bean. How should I get the value of the inputText? Here is the flow definition in case it is need.
<transition on="searchByKey" to="editTexts" >
<set name="flowScope.key" value="requestParameters.filterKey"/>
<evaluate expression="textManager.searchByKey(key)" result="viewScope.textsByKey" result-type="dataModel"/>
</transition>
Thanks
That isn't possible. The <f:param value> is evaluated when the form is rendered/displayed, not when the form is submitted/processed.
I'm not familiar with Spring Webflow, but this is IMO a really strange design. You might want to confirm with the SWF guys if you're doing things the right way. Perhaps you should rather inject the SWF variable as a managed bean property during its construction/initialization or something?
Anyway, there are ways to get the submitted value without binding the input component's value to a managed bean property. One of them is just getting it straight from the request parameter map by #ManagedProperty:
#ManagedProperty("#{param['formId:inputFilterKey']}")
private String key; // +setter
or when the managed bean has a broader scope than the request scope:
String key = externalContext.getRequestParameterMap().get("formId:inputFilterKey");
The formId:inputFilterKey is just the name of the generated HTML <input> element representation of the <p:inputText> component.