selectOneMenu valueChangeListener with onchange=

Can anyone provide some insight into what I'm getting when using both valueChangeListener with onchange="submit()"? Both are needed in my app to cause a form change when a selectOneMenu item is selected.

After the page is initially loaded and making a menu selection, the selected menu item does not show and no action occurs. Watching the backing bean code, the listen method is not even called. Everything works as expected the second time a menu selection is made.

When the onchange="submit() statement is removed, the first menu selection will show in the menu, but, of course, the action upon value change does not occur.

Now I understand that JSF performs lazy instantiation and wonder if this is involved. But the menu choices are available for selection after the page loads, it's the listen method that doesn't get called the first time.

This is my selectOneMenu code:

<h:selectOneMenu id="locationSelection"

valueChangeListener="#{SelectBean.onLocationChange}"

onchange="submit()" >

<f:selectItems id="locationSelects" value="#{SelectBean.locationSelects}" >

</h:selectOneMenu>

[1297 byte] By [paul@sdna] at [2007-11-27 9:41:23]
# 1

Likely you misunderstood the valueChangeListener and you was expecting some client-side magic. Wrong. JSF is fully server-side and the valueChangeListener definies a server-side method which should be invoked if the form is being submitted. If you want to submit the form automatically on change of the selection, then you indeed need to add onchange="submit();" attribute, which just adds a piece of Javascript (client-side scripting language) defining a Javascript method to submit the form when the selection has changed.

BalusCa at 2007-7-12 23:20:14 > top of Java-index,Enterprise & Remote Computing,Web Tier APIs...
# 2
Sounds like we both have the same understanding. What I don't understand is why this won't work immediately after the page is loaded, but will work after a second time selecting a menu item. It also works fine after a browser refresh.
paul@sdna at 2007-7-12 23:20:14 > top of Java-index,Enterprise & Remote Computing,Web Tier APIs...
# 3
It appears that the condition I am seeing is specific to JSF 1.1. Upon upgrading to JSF 1.2/Tomcat 6 this issue no longer appears. There does seem to be some suggestion of a fix to this issue in the JSF 1.2 notes.
paul@sdna at 2007-7-12 23:20:14 > top of Java-index,Enterprise & Remote Computing,Web Tier APIs...