my dog learned polymorphism
The moose likes JSF and the fly likes Problem with selectOneMenu and valueChangedListener Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » JSF
Bookmark "Problem with selectOneMenu and valueChangedListener" Watch "Problem with selectOneMenu and valueChangedListener" New topic

Problem with selectOneMenu and valueChangedListener

Maurits van Beusekom

Joined: Jun 03, 2010
Posts: 2
Hi All,

I am currently trying to build a simple web based application as a school exercise using JSF. The application allows the user to login and manage notes. The user can add multiple notes (I call documents) and per note have multiple versions (each time the user makes a change to a note a new version is created).

The application consists out of the following elements:

- Title textfield;
- Note textarea;
- Version selectOneMenu;
- Save button;
- Data table showing all existing notes.

The data table contains an commandlink behind each note which, when clicked by the user, populates the Title, Note and Version elements with the appropriate data. So far everything works fine.

Now when the user selects a different version from the Version selectOneMenu the 'Note' textarea should be updated with the content of that specific version. This is where my problem pops up. When I change the version nothing happens. The "versionChanged" method in my managed bean is not triggered when I select a different version. Here is my code so far:

Welcome.jsp (this is opened after the user logged on successfully):

In my managed bean (EindOpdrachtContr class) I have the following method:

The managed bean is configured in the faces-config.xml file like this:

I posted the code parts which (in my opinion) are most relevant, if you are missing something please let me know. Any help would be greatly appreciated.

Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 17421

Welcome to the JavaRanch Maurits!

Unfortunately, you gave me a little too much detail. The only way I can tell you with total assurance is to kill a tree (print it out) and cross-check the details. However, based on experience with similar questions, I can make some observations that may help.

First of all, however, a backing bean is NOT a controller except in very limited ways. It's primarily a Model in the MVC paradigm. To be more precise, it's the Display Model, as opposed to say, a Domain Model, or Business Model. Meaning that its primary purposed is to support the MVC portion of the app. JSF's controllers are mostly in the JSF tags and the JSF servlet.

However, that's just being picky about terminology because I've been seeing people get in trouble for failing to make the distinction.

My suspicion is that you're expecting an immediate response when you change the menu selection. That's not how it normally works.

JSF is based on HTML and HTML doesn't work that way either. HTML only updates the server when a Submit is done for the form. Changing a selection won't cause a Submit.

To force a Submit when changing a SELECT control (SelectOneMenu), you'd need some JavaScript. To be precise, you'd need something like an AJAX request. Core JSF doesn't do AJAX. For that, you either need to write your own JavaScript or to use one of the extension tagsets that support AJAX, such as RichFaces or IceFaces. In RichFaces, you can define an ActionListener that fires off under AJAX control when a selection is changed, and uses the "reRender" RichFaces attribute to update only the affected part of the view. In your case, that would be the Notes area, if I read your question correctly.

An IDE is no substitute for an Intelligent Developer.
Maurits van Beusekom

Joined: Jun 03, 2010
Posts: 2
Hi Tim,

Thanks for the welcome and the reply I appreciate it (and sorry for the bulk of information, I figured better to much then to little).

My controller impression came from this tutorial and makes sense to me, however this would not be the place to discuss this.

I am a bit confused regarding your remark, I am familiar with HTML and how it functions (a lot of .NET experience). I am not really looking for a AJAX solution, I was in the impression that it would be possible to do a postback to the server by using the onchange="this.form.submit()" javascript, and be able to call the 'valueChanged' method (as described in this article, where a similar solution is done). And basically that is the same I do with the 'open' note link which does a postback and fires the "editDoc" method in the EindOpdrachtContr class.

So what I basically want is for the selectOneMenu to make a roundtrip to the server when the users changes its value and the response should contain the updated Note textarea.

Thanks Maurits
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 17421

OK. I missed the trees for the forest there. About what I'd expected.

Yes, you can do that. The main difference is that AJAX would just refresh part of the page, whereas a full "submit()" will re-render the entire page.

Should be simplicity itself except for one small detail. Unlike conventional HTML, where the "submit" button is optional, in JSF you have to fire an action. Meaning that you must have a commandButton or commandLink directing which action is to be fired. The action method can set the backing bean's "note" property with the new value and it will automatically display when the page re-renders.

There's no need for a valueChangedListener for that, and no benefit. In fact, valueChangeListeners are perilous places to put business logic and property-changing code, as it can cause interference with normal lifecycle actions up to and including having standard JSF lifecycle events undo what you did there.

You do however, have to have some sort of designated action, as the action processor phase is a critical part of any JSF lifecycle that passes validation and conversion. Not to mention the truncated "immediate" cycle as well.
I agree. Here's the link:
subject: Problem with selectOneMenu and valueChangedListener
It's not a secret anymore!