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] > >
