I am experiencing the same problem with 1.5.3.

To be more precise, I'm building my select item list like this:

ArrayList<SelectItem> selectItemList = new ArrayList<SelectItem>();
selectItemList.add(new SelectItem("", "-- Select --"));

Now, this generates HTML that looks like this:
<select>
<option value="">-- Select --</option>
</select>

When the user does not select an item from the list (leaves it as "-- Select -"), the com.icesoft.faces.component.ext.HtmlSelectOneMenu.validate(FacesContext facesContext) method calls the UIInput.getSubmittedValue() method, which, rather than returning an empty string (""), returns "- Select -"!!! This is the heart of the problem. Perhaps it is the ICEfaces partial-submit system passing "- Select --" as a request parameter value. I don't know.

The reason why the "Validation Error: Value is not valid" message is happening, is because the HtmlSelectOneMenu.validate() sees "-- Select -" instead of an empty string for the submitted value, and then lets the UISelectOne superclass handle it. The superclass does not see "- Select --" as a valid value in the selectitems, and so adds a javax.faces.component.UISelectOne.INVALID message to the validation error list, the English version of which is "Validation Error: Value is not valid"

– Neil

We verified Neil's finding that the value sent by the browser is "-- Select --" instead of "". Mircea is working on it.

Fix <select> element's serialization when the value is the empty string.

Mircea's check-in fixes this bug. I have re-tested above issues and it works fine now.

The required attribute is not working when contained in a UIData component. Please see https://www.icesoft.ca:4443/supportilla/show_bug.cgi?id=4030 for more details.

ignore last comment

This is an enhanced version of the sample portlet released with Liferay 4.3.0-RC1, which has been modified to reproduce this problem.

I still think that this one is broken.

I just attached an enhanced version of the sample portlet released with Liferay 4.3.0-RC1, which has been modified to reproduce this problem.

To reproduce:

• Download Liferay 4.3.0-RC1 from here and install:
  http://www.liferay.com/web/guest/downloads/liferay_enterprise_portal/4_3_0rc1

• Copy the attached portlet .WAR into $HOME/liferay/deploy (hot deploy folder):

• Start the portal

• Start Browser and visit http://localhost:8080 and login as test@liferay.com with password test

• Add a new portal page named "ICEfaces"

• Add the Sample ICEfaces (Sun RI) Portlet from the "Add Content" option

• Hit the Submit button

Notice that all the required fields except the <ice:selectOneMenu/> are validated properly. In other words, it should have a "Value is Required" error message next to it like all the others.

--Neil

Forgot to mention that I don't think this is a portlet issue. I think it would be reproducable in a webapp environment as well. The only example I have is a portlet example though (attached).

--Neil

Can you retest to ensure that selectOneMenu required is working as expected in 1.6 trunk.

I tested with the wells-fargo demo app and using "" as the value of the first item will fire the required validator. Not entering "" and leaving the item value as null will produce "null" as the first item in the UI.

However, after interacting with the other input components you are able to get through (without another "required" message showing up) without changing the selection to a valid value.

I just tried this again with the latest trunk and the required validator is not firing.

In my managed bean, I populate the list like this:

ArrayList listItems = new ArrayList();
listItems.add(new SelectItem("", "-- Select --");

The rendered HTML looks like this:

<option value="">-- Select --</option>

The required validator is not firing when I tab out of the field, and is not firing when I submit the form.

Please advise – Thanks!

Neil

Hi Brad and Neil,

I have checked-in a fix for the above issue, can you guys please verify if it has been fixed. revision 14237

Thanks,

I have tested this agains the wells-fargo demo and it appears to be working.

As Brad verified it. I am resolving this case.