This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Original status: 3-Accepted; Suggested Status: NEW Original Target Release: mako_dev; Suggested Target Milestone : Dev Description: SYSTEM INFORMATION : System Info: Product Version = IDE Versioning = Operating System = Java; VM; Vendor = Java Home = System Locale; Encod. = Home Dir; Current Dir = IDE Install; User Dir = CLASSPATH = Boot & ext classpath = Dynamic classpath = A DESCRIPTION OF THE PROBLEM : When entering fixed options for radio buttons such as below: <h:selectOneRadio binding="#{changeresponse.radioButtonList5}" id="radioButtonList5"> <f:selectItem itemLabel="YES" itemValue="YES"/> <f:selectItem itemLabel="NO" itemValue="NO"/> </h:selectOneRadio> The designtime does not show any representation of radio button lists. EXPECTED VERSUS ACTUAL BEHAVIOR : EXPECTED - Render radio button correctly in design time. Expectation of rendering the fixed-valued labels. REPRODUCIBILITY : This bug can be reproduced always. xxx@xxxx 2005-06-08 05:47:51 GMT Evaluation: Incident report shows: <h:selectOneRadio binding="#{changeresponse.radioButtonList5}" id="radioButtonList5"> <f:selectItem itemLabel="YES" itemValue="YES"/> <f:selectItem itemLabel="NO" itemValue="NO"/> </h:selectOneRadio> The preferred approach in Creator is to select default items in outline and then edit list of items. This gives JSP source like: <h:selectOneRadio binding="#{Page1.radioButtonList1}" id="radioButtonList1" style="left: 24px; top: 144px; position: absolute"> <f:selectItems binding="#{Page1.radioButtonList1SelectItems}" id="radioButtonList1SelectItems" value="#{Page1.radioButtonList1DefaultItems}"/> </h:selectOneRadio> And java source with: radioButtonGroup1DefaultOptions.setOptions(new com.sun.web.ui.model.Option[] {new com.sun.web.ui.model.Option("Yes", "Yes"), new com.sun.web.ui.model.Option("No", "No")}); radioButtonList1DefaultItems.setItems(new String[] {"Yes", "No"}); Evaluation (Entry 2): - I believe that we do not model this type of list, and therefore is works as designed - would need to talk to xxxx about this otherwise, and log as an RFE Evaluation (Entry 3): This should be fixed in Mako assuming xxxx agrees to support the kind of construct the bug reports.
Probably fixed in 6.0.
We do not support this in 6.0 as well. This is an enhancement