• 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
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

pre-select the drop-down list in JSF

 
Ranch Hand
Posts: 294
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Has anyone have success doing that?

currently I use



It does not pre-select the current property

Is there a tag attribute in <h:selectOneMenu> that I didn't know to include or is there another tag in RichFaces 3.1.5 that I can use to achieve my purpose?

Thanks for all your help.
 
Ranch Hand
Posts: 37
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
I dont think there is any problem with your understanding.

Just check in debug mode if the getter of 'property' is called. If any of the POJO's(somePOJO & anotherPOJO) in the 'SomeBackingBean' are null, the default item is selected (the default is the first item in the list).

The alternative (better) practice would be to have setter/getter for 'property' in the 'SomeBackingBean' and the setter will write to 'somePOJO.anotherPOJO.property' and getter will read from 'somePOJO.anotherPOJO.property'

I hope this helps

Pradeep
 
Saloon Keeper
Posts: 28492
210
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
When a selectOneMenu is rendered, the current value of the control is queried by evaluating the EL expression. Which in your case, would amount to calling SomeBackingBean.getSomePOJO().getAnotherPOJO.property(). Which highlights why I don't recommend giving beans names that start with uppercase letters - it looks like a class reference when it's actually a member reference.

IF the returned value is one on the values in the options list, THEN the value is pre-selected when the list is displayed. Otherwise the first option in the list is displayed.

Note that there's no need to construct elaborate invocations of internal JSF methods, complicated tags, or whatever. People complicate JSF too much. All that's necessary is to preset the bean property value before the view is displayed.

If you don't want the bean property to be modified on initial display, use a temporary property in a backing bean and have the committing action processor set the target property from the temporary property's value.
 
Davie Lin
Ranch Hand
Posts: 294
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Tim, thanks for your reply

However, can you elaborate a little more on what's "Temporary property", I don't understand what it means.

Thanks again.
 
Davie Lin
Ranch Hand
Posts: 294
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Pradeep,
I don't quite know how to translate what you said below to code


The alternative (better) practice would be to have setter/getter for 'property' in the 'SomeBackingBean' and the setter will write to 'somePOJO.anotherPOJO.property' and getter will read from 'somePOJO.anotherPOJO.property'



Would you write me some simple code example?

Thanks
 
Tim Holloway
Saloon Keeper
Posts: 28492
210
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
"temporary" in this particular case just means that instead of setting a value in your "permanent" or object model data, you use an intermediate holding area, which is just a property presented on a backing bean. That way the permanent object's value only gets changed if you commit the value by copying it from the intermediate (or temporary) property in the backing bean to the permanent object. Which would be done as part of the action processor.
 
Davie Lin
Ranch Hand
Posts: 294
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Tim Holloway wrote:"temporary" in this particular case just means that instead of setting a value in your "permanent" or object model data, you use an intermediate holding area, which is just a property presented on a backing bean. That way the permanent object's value only gets changed if you commit the value by copying it from the intermediate (or temporary) property in the backing bean to the permanent object. Which would be done as part of the action processor.



so I am getting what you say here as use a private member variable in the backing bean to store the value until you commit and than update (in this case either somePOJO or anotherPOJO)

 
Tim Holloway
Saloon Keeper
Posts: 28492
210
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
In essence. Although there's a nitpicky little difference between a "property" and a variable. JSF EL references properties, which is why I used that term.
 
Pradeep Katipamula
Ranch Hand
Posts: 37
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Davie Lin wrote:
Would you write me some simple code example?


Here it comes
UI

Bean (according to your assumption - 'SomeBackingBean.somePOJO.anotherPOJO.property')

Although I have used your variable names, please keep in mind what Tim said.. Conventions are important
Hope you got wat i am trying to say.

Pradeep
 
Tim Holloway
Saloon Keeper
Posts: 28492
210
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
Actually, I didn't mean just "use a property to hide the indirection". That just puts you back to the original situation where you're modifying the target even if you don't commit the change. What I meant was


I tend to prefer using the get/set methods even internally, as it's easier to track usage, but that's a personal preference except where shop standards mandate one way or the other.
 
Pradeep Katipamula
Ranch Hand
Posts: 37
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
@Tim:

I was just trying to explain my first reply.

The two points I was trying to say
1. Avoid indirections (personal preference )
2. Avoid null pojos in a bean since it may cause probs like the one now( which is not in above the sample code, use the constructor to create & assign objects)

My sample code had nothing to do with your explanation
 
Davie Lin
Ranch Hand
Posts: 294
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hey guys, thanks for all your input on solving my issue.

I have just solved the issue and although your suggestion didn't directly resolve it, it did help.
My issue was that my drop-down's selectItem implemented as



property is a String

the value I should of use in my h:selectOneMenu should be



NOT



now my value is getting pre-selected

Thanks for all your suggestions>
 
reply
    Bookmark Topic Watch Topic
  • New Topic