Is Backing bean Required

[Sim Kim]

Hi All,

I am having a Zipcode field and a City field. I want the city field to be popluated on the basis on value changed in zip code field. For this I have written a value change listener in the ZipCode field and made its immediate = "true" along with onchange = "this.form.submit()" .


Now my issue is if the City field has a value attribute then the updated value of City is not reflected in the page but if the City field is using a binding attribute and is having a backing bean then only the field value is populated ? Is Backing bean required here ?

This works :

  
<h:inputText id="zipcode" value=#{bean.zipcode}" valueChangeListener="#{bean.findCity}" immediate="true" />
<h:inputText id="city" binding=#{bean.city_inputtext}" immediate="true" />
  

This does not :

  
<h:inputText id="zipcode" value=#{bean.zipcode}" valueChangeListener="#{bean.findCity}" immediate="true" />
<h:inputText id="city" value=#{bean.city}" immediate="true" />
  

Also why is immediate = "true" required for City field as well ? If I remove it City field is not updated .

[Bauke Scholtz]

Sim Kim wrote:I am having a Zipcode field and a City field. I want the city field to be popluated on the basis on value changed in zip code field. For this I have written a value change listener in the ZipCode field and made its immediate = "true" along with onchange = "this.form.submit()" .

I would rather use an ajaxical component library to handle this, such as Ajax4jsf. Or if this is somehow not an option, then I would rather do it using plain vanilla Javascript. Populate a Javascript array with cities and make use of it during the onchange.

Now my issue is if the City field has a value attribute then the updated value of City is not reflected in the page but if the City field is using a binding attribute and is having a backing bean then only the field value is populated ? Is Backing bean required here ?

This works :

  
<h:inputText id="zipcode" value=#{bean.zipcode}" valueChangeListener="#{bean.findCity}" immediate="true" />
<h:inputText id="city" binding=#{bean.city_inputtext}" immediate="true" />
  

This does not :

  
<h:inputText id="zipcode" value=#{bean.zipcode}" valueChangeListener="#{bean.findCity}" immediate="true" />
<h:inputText id="city" value=#{bean.city}" immediate="true" />
  

Also why is immediate = "true" required for City field as well ? If I remove it City field is not updated .

Here you're misusing the valueChangeListener to set the value of another component instead of handling the actual change of the value (you're not interested in the old value). Here you're also misusing the immediate attribute to bypass validation (and model update!) of the other components.

That the second does not work is because the valueChangeListener runs in the 3rd phase (process validations) of the JSF lifecycle which is right before the 4th phase (update model values). So whenever you change the property behind #{bean.city} in any phase before the 4th phase, then it will simply be overridden during the 4th phase.

After all, your knowledge about the JSF lifecycle is fairly poor. I highly recommend you to go through a decent JSF tutorial or book before continuing with JSF. As a book I can recommend you the "JSF: The Complete Reference". Also the JSF API specification at its own is worth reading.

Regarding to the question as stated in the topic title: "Is backing bean required?". This whole question at its own makes absolutely no sense. Of course it is required. But on the other hand I don't see any relation between that question and your actual problem as described here. Please carefully invent smart questions and topic titles.

[Sim Kim]

This example is from JSF: The Complete Reference . I am currently reading the book and have been stuck here.

Read page 156 of the book , under heading "Using a Value Change Event to Auto-Fill Fields"
You will see the same example here.

As far as explanation for #{city.name} not getting updated is given, I think you are right but I missed one point. The valueChangeListener written for Zipcode calls responseComplete() , so there is not question of going to 4th phase. Can you guide me now how do I use managed bean here ?

As far as this is concerned :

Here you're misusing the valueChangeListener to set the value of another component instead of handling the actual change of the value (you're not interested in the old value). Here you're also misusing the immediate attribute to bypass validation (and model update!) of the other components.

I think you are wrong ? I can use the old value and new value of the zip code to do some comparison , after all every city can have many zip codes not one. So I can determine whether or not to change the value of the city field based on zip code.


Also if this book has almost the same code which I have written, so is this book wrong or I need to use some other book.

[Bauke Scholtz]

Sim Kim wrote:Read page 156 of the book , under heading "Using a Value Change Event to Auto-Fill Fields"
You will see the same example here.

I share that under a "trick", not really a "best practice". When validations comes into picture, it's fairly a mess to get it all right after all (using immediate attribute and component binding).

As far as explanation for #{city.name} not getting updated is given, I think you are right but I missed one point. The valueChangeListener written for Zipcode calls responseComplete() , so there is not question of going to 4th phase. Can you guide me now how do I use managed bean here ?

Then I don't see any other cause in the as far given information and code.

I think you are wrong ? I can use the old value and new value of the zip code to do some comparison , after all every city can have many zip codes not one. So I can determine whether or not to change the value of the city field based on zip code.

A valueChangeListener will only be invoked if the value is actually changed.

[Sim Kim]

A valueChangeListener will only be invoked if the value is actually changed.

I guess thats what I have written. If the value of Zipcode entered by the user changes then ValueChangeListener will be invoked and it can see whether or not to change the City name based on the zip code.

[Tim Holloway]

Ajax4JSF:

                        <h:outputText value="Choose your State" />
                        <h:selectOneMenu id="selectState"
                            styleClass="localeMenu" value="#{setLocation.state}"
                        >
                            <f:selectItem itemValue="null"
                                itemLabel="-- Select --" />
                            <f:selectItems value="#{setLocation.stateList}" />
                            <a4j:support event="onchange"
                                immediate="yes"
                                reRender="selectCity" ajaxSingle="true" />
                        </h:selectOneMenu>
                        <h:outputText value="Choose your City" />
                        <h:selectOneMenu id="selectCity"
                            styleClass="localeMenu" value="#{setLocation.city}"
                        >
                            <f:selectItem itemValue="null"
                                itemLabel="-- Select --" />
                            <f:selectItems value="#{setLocation.cityList}" />
                            <a4j:support event="onchange" />
                        </h:selectOneMenu>

You can do something similar with a suggestion input AJAX control (RichFaces supplies one) to get a city selected based on ZIP code. This example presents a dropdown list of cities based on the selection from a dropdown list of states.

The backing bean requirements are quite straightforward - stock String properties to manage the city and state IDs and a pair of SelectItem arrays to present the choices in the dropdown lists. The setState() method invokes the backend to load and create a new SelectItem list with the cities for the newly-selected state that will be stored where the getCityList() method can find it.

Note the a4j support event for onchange in the city. Because the AJAX operation does a small amount of out-out-band data manipulation, you need this to cause the city selection property value to be updated properly before the submit action processor is fired. Otherwise the change to the selection doesn't show up in time.