• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

problem with <h:selectOneMenu > element and the submittion of its value

 
Ranch Hand
Posts: 36
3
Eclipse IDE Redhat Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello

I have one page, where I have several <h:selectOneMenu > elements, some of those selectOneMenu are father elements and others are children , The options that I have in the father elements are always the same, but the options that are displayed in the children elements depend in the father's value.

All the elements are inside the same form. Every time the user chooses one option in one of the selectOneMenu the form is submitted and the value selected is stored in the bean, then the data is processed and the children elements are populated according to the father value.

In each selectOneMenu I have the attributes onchange and valueChangeListener, the onchange attribute submits the form, meanwhile the valueChangeListener saves the new value that was selected for that selectOneMenu element.

Now, this is the problematic situation, when I select a new value in a father element, the father's onchange and valueChangeListener are triggered and the children element is populated with the values that correspond to the selection in the father element, but If i decided to change again the value of the father element, the father's onchange and valueChangeListener are triggered , the children is populated with new values , and as the children now has DIFFERENT values, the children's valueChangeListener is triggered and its value is submitted together with the father element to the bean.
So first question. How can I avoid that the children's valueChangeListener is triggered every time that I want to populate again its value?

The second problem is very similar or is linked with the last problem. In order to populate the children element, I read what the father's value is( <f:selectItems value="#{parameter.paramOptions}" /> ) then I execute a query to get the values for the children, and I populate the children element. Now , the problem comes when I want to select a children value, because when I do it, the form is submitted, and the children is populated again (this time with different values). It looks like the application is not reading what the father's selected value was, instead is reading one of the different possibles father's value, so every time the a new children value is selected, a different father value is loaded and and the children element is repopulated.
Does anyone know why this is happening and how i can avoided?

Thanks in advance
 
Saloon Keeper
Posts: 27762
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'll answer your first question and maybe it will help with the second one. One thing that will help you if you need to use Google for cases like this though is that in English programmer-speak, the standard term is "parent" rather than "father". We're more gender-ambiguous.

A valuechangelistener is only fired if the value actually changes. So that cuts down on the overhead. However, it might get fired more than once and you rightfully don't want a lot of work being done every time it fires.

What I do is make the parent's valuechangelistener simply set the child's SelectItemList object to null and the selected child value to a default (since without a selection list, no child value can be valid).

On the child side, I then augment the usual "get" method for the child's SelectItemList to make it look like this:



That will reduce the overhead to a single reload operation that is only done when needed. A side benefit is that you can use this same feature to pre-set the child selectItem list at the beginning of an edit operation after you've fetched the data to be edited.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic