Craig, I am using a explicity defined converter and everything is converting fine through the Process Validations phase. Its during Update Model phase that things go funky. Converters don't matter at this point do they?
I think there might be a bug in MyFaces (http://issues.apache.org/jira/browse/MYFACES-623). When I examined the ValueBindingImpl using my debugger it showed that it was specifically trying to coerce the value to class associated with java.lang.String. It looks like PropertyResolverImpl in MyFaces is checking if StatusImpl is an instanceof Map when it should be checking the result of StatusImpl.getData(). If it were checking the right object then we'd be ok (because the class that it tries to coerce to is the object's class.) sean On 9/26/05, Craig McClanahan <[EMAIL PROTECTED]> wrote: > > > > On 9/26/05, Sean Schofield <[EMAIL PROTECTED]> wrote: > > I am using a converter for an <h:inputText> in my dialog. The value > > is supposed to be a custom object but it seems like it is being > > "coerced" into a String. > > > > Here is the relevant JSP ... > > > > ... > > value="#{dialog.data['reviewer']}"> > > > > The value inside this map is SystemUser (an application specific class > > of mine.) During the Update Model phase of JSF it seems like the > > value is being coerced into String. Is there anything specific to > > Shale that is causing this? Any insight into why this is happening > > would be helpful. > > > > I suspect that since the "dialog" bean is *not* defined in > > faces-config.xml this might have something to do with it. > > It actually *is* defined in such a file ... the one inside the META-INF > directory of shale-core.jar. > > > Perhaps > > String is the default class to coerce to ... > > More precisely, String is the expected data type when: > > * There is no explicit converter registered > (which sounds like it is true in this case) > > * JSF cannot evaluate the data type that will be accessed > (which will be true in the data object returned by the "data" > accessor is not going to have explicit properties -- it is itself > a java.lang.Object). > > If you declare a Converter, or if JSF can introspect the target data type, > it will "just work" -- but the way that Shale implements the "data" object > makes it not possible for JSF to do this on the fly. It might be possible > to support such introspection, but that would require you to be explicit > about the names and types of all the things you might want to store in the > "data" object -- and that seems like at least as much work (if not more) as > just assigning converters when *you* know they are necessary. > > Try using an explicitly specified converter on the <h:inputText> component > that is bound to a non-String property. > > Craig > > > > sean > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
