Closed javaserverfaces closed 17 years ago
Reported by youngm
@rlubke said: Discussed this issue briefly with Mike. We're think we can get the 'value' ValueExpression and obtain the property type and use that for the conversion class type instead of the selected value. If no VE is found, or the type is null, then default back to using the value type.
This should allow Mike's case to work.
However, it's late in the game for 1.2_03, and Mike has a workaround. We'll revisit for 1.2_04.
@rlubke said: Attempt to re-evaluate for 1.2_03.
@rlubke said: Created an attachment (id=394) Possible fix for SelectOne
@rlubke said: Created an attachment (id=395) Reproduction
@rlubke said: Reproduction URL: http://localhost:8080/WebStuff/faces/SelectOneTest.jsp
@rlubke said: Created an attachment (id=396) Build including the possible fix
@rlubke said: Mike,
I've attached a possible fix for UISelectOne, including the impl with the changes.
When you find time, please review and test.
youngm said: The fix you provided appears to work for me in the case I spelled out in the issue so r=youngm. The case below works with this patch where in rc3 it would throw an exception.
One interesting future note for the spec team though might be the situation a converter isn't used. If I don't use a converter then setValue(Object value) recieves a value of type "String" when I submit the Long item instead a Long.
I think a spec issue for more explicit consideration of mixed type selectItems would be a good spec issue.
Case: public Object getAsObject(FacesContext context, UIComponent component, String value) { if(NumberUtils.isNumber(value))
{ return new Long(value); }
return value; }
public String getAsString(FacesContext context, UIComponent component, Object value)
{ return value.toString(); }
public List
{ List
public Object getValue()
{ return new Long(1000); }
public void setValue(Object value)
{ System.out.println(value.getClass()); }
youngm said: It's also unfortunate that we have to handle this mixed case with an exception being thrown....but I see the need to help ensure backwards compatibility. Perhaps in the next version of the el an coerse type check can be added to the api so an exception won't need to be caught for such situations.
@rlubke said: Created an attachment (id=398) Proposed Fix (version 2)
@rlubke said: Over-anaylyzed this one. I've attached a new change bundle that corrects the issue for selectone and selectmany.
Review pending.
jdlee said: Confusing typo in comments fixed by Ryan. No need for another CB for that.
r=jdlee
@rlubke said: Discussed the mixed options (without a common type) issue further with Mike. Doing so would require using a converter for each item which the spec currently doesn't allow for in the default UISelectMany case. Additionally, if using a List for the model type to collect the items, the type is considered String so converters aren't used.
Given this limitation, we'll look into creating a sandbox component that will override MenuRenderer/UISelectMany as necessary to support this.
@rlubke said: Fix checked in.
@manfredriem said: Closing issue out
File: changebundle.txt Attached By: @rlubke
File: changebundle.txt Attached By: @rlubke
File: jsf.zip Attached By: @rlubke
File: WebStuff.war Attached By: @rlubke
Was assigned to rlubke
This issue was imported from java.net JIRA JAVASERVERFACES-442
Marked as fixed on Monday, November 20th 2006, 2:11:06 am
I have a class Entity with 2 subclasses (SubEntity1, SubEntity2).
I have a managed bean with a property of type Entity and a default value of an object of type SubEntity1.
I have a SelectOneMenu with with a number of SelectItems of mixed type SubEntity1 and SubEntity2.
When the renderer renders the options it attempts to match the available options with the selected options so it knows which one to mark as selected. When doing so MenuRenderer.renderOption() attempts to convert the candidate options to the type of the currently selected item. Where I have candidate options of both type SubEntity1 and SubEntity2 I get an EL Unable to Coerse Type exception when it attempts to coerse the candidate option of type SubEntity2 to the type of the selected item SubEntity1.
If the coercion is needed it would seem better to coerce it to the type of the managed bean's property instead of the type of the currently selected item. If the coercion is not necissary then we simply remove the coercion. Any opinions between those 2 options?
Mike
Environment
Operating System: All Platform: All
Affected Versions
[1.2_02]