I guess we had a slight misunderstanding heresmithh032772 wrote:PLEASE take NO offense as I will share my HONEST opinion. I think using a converter with selectOneMenu is 'unnecessary' (nicer term) and 'dumb' (not-so-nice term). Look at the word, 'converter', which suggests there is a 'need' to 'convert' some 'enduser-selected-value' to a 'usable-value' in the backend.
selectOneMenu has a 'display' value and a 'data' value. 'data' value is hidden from enduser and definitely 'usable' in the backend.
This is great. Why should user see 'NULLSTRING' on the page or 'data' value which is 'used' by/on/in the backend. 'display' values are 'user-friendly', 'data' values are application/backend-friendly. Why should the user see NULL (or empty) value in a selectOneMenu? Is that user-friendly to show an invisible NULL (ascii character) value in selectOneMenu? no way, not at all. If you love JSF and want to use JSF, then accept the limitations/implementation and change your approach, and code/implement a workaround. I'm glad your last response showed that you went with another approach....
By no means I want to display "NULLSTRING" or "null" to the user. The difference between the visible displayed text and the selectable value in the background is quite clear to me and is a very sensible thing to have.What I'd like to get would be a selectOneMenu that has nothing selected (empty display) when it first appears. Then, when the user opens the dropdown, there should be all the nice pretty "display" names, but the initial empty option should not be visible or selectable. So if the user selects something, s/he can't ever go back to select nothing. In my app it makes no sense to leave the selectOneMenu empty (it is required).
By now I'm pretty sure what I just described isn't possible. I thought that the "hideNoSelectionOption" attribute would do what I was looking for, but it doesn't work (at least not in the way I thought it would).
Now, how to workaround that ? Well, if I just use the list of all selecteable items without an empty/null/NULLSTRING option, then the first item will be preselected in the selectOneMenu. I specifically do not want this, because I want to force the user to make a selection (so that s/he has to consciously verify that the selection is what s/he wants). So I need the empty/null/NULLSTRING option for the inital empty selection in the selectOneMenu. Now that makes that option also selectable after something else was selected. Since selecting the empty/null/NULLSTRING option does not[(i] cause the associated bean property to be updated to null (in the case I use f:selectItem to insert it) it breaks my code that depends on the current selection in the selectOneMenu (to determine if the submit button should be enabled or disabled). That's why I had to wrap my stuff into SelectItem classes and manually add a null entry. It's not pretty (from a software designers view), but it works: I have tight correlation of what the user sees and selects in the SelectOneMenu and the associated value in my bean.
Of course there are validators and stuff that should be able to take care about this (in probably some different JSF-cycles ?), but I didn't yet get to the bottom of the validators thing. But I'll try to rip out my custom shall-button-be-enabled logic and base it on the validators result (which should make it coherent and print pretty messages as well). I'm not entirely sure this will work, but lets see
One word on converters: since I select entity classes (they're dynamically creatable by users), I need to have a mechanism that lets me select those classes. Since HTML elements are strictly string based, a converter is necessary to convert between my classes and the strings used for selectOneMenu's 'data' value (referring to your terms of 'display' and 'data' in selectOneMenu). That conversion may be implicit (there are built in converters for Long and Int afaik in jsf2 or seam3), but it has to take place. And the converters, where I used them, worked - they just never got the NULLSTRING value - the same problem as with null not appearing in my associated bean property.
(Two beautiful links: Converters aren't run if value expression returns null and JIRA: Run converters even if value to convert is null. Note that the JIRA issue exists since v1.2 and was postponed multiple times - it now says "Fix version: 2.2")
smithh032772 wrote:
There still is no possibility to hide the empty choice from the user in the drop down box.
Disagreed, and not true. If 'selected' value of your selectOneMenu != 'NULLSTRING', then render different selectOneMenu that does NOT include the 'NULLSTRING' option; otherwise, render the selectOneMenu that contains the 'NULLSTRING' option. In my code sample below (from a page that I recently developed and still-under-development), the selected value of the 1st selectOneMenu determines if 2nd or 3rd selectOneMenu is displayed to enduser. Where there is a 'will' (and 'knowledge' of JSF), then there is definitely a JSF 'way' (or solution).
[...]
My opinion, per my understanding and experience (so far), there is no need to rely on (or code a converter) for selectOneMenu. selectOneMenu already has a built-in 'converter', which is 'display' vlaue and 'data' value. Still to this day, I have had no need to write a converter, NetBeans did that for me for all my entity objects that are somehow presented/referenced in web app via @FacesConverter (generated JSF code by NetBeans...thank you NetBeans).
I don't really understood what you tried to say here with different selectOneMenu's or selection-dependent rendering. That's not what I tried to do.
I'm pretty sure that your second and third selectOneMenu's drop-down box will both include the "Select One" option (which has the same intention as my empty/null/NULLSTRING option). So the user will not only see the "Select One" text before s/he selects something, but s/he will also be able to select that option from the drop-down list. Briefly that is what I fight against
Regards,
koma