What do you mean by letting 1 component morph into another with respect to
Validator, ValueChangeListener, and Converter?
I think overriding the behavior of those types is probably the right thing
to do. Does this disallow the morphing feature?
On 11/4/05, Gary VanMatre <[EMAIL PROTECTED]> wrote:
>
> >I think the change to save id state in the attributes collection broke
> use
> >of commons validator.
> > It's throwing runtime exception in PropertyValueCommand:
> > try {
> >PropUtils.setProperty(child, attributeBean.getName(), expr);
> >} catch (Exception e) {
> >if (child instanceof UIComponentBase)
> >((UIComponentBase) child).getAttributes().put(attributeBean.getName(),
> >expr);
> >else
> >throw e;
> >}
> > Now that id is in attributes collection, PropertValueCommand tries to
> setId
> >on CommonsValidator which does not have this property.
> >And since it's not instanceof UIComponentBase, you get throw e.
> > Maybe the code above should check if child is instanceof
> >javax.faces.validator.Validator and not throw exception in that case. I
> >don't believe that validators necessarily need ids?
>
> We could override the behavior of the getId and setId in the
> ValidatorBean, ValueChangeListenerBean and ConverterBean.
>
> Or, I just log it as an error and continue on. I like the idea of one
> component being able to morph into another but I know that others would
> rather raise an exception. It's kind of a gray area when it comes to
> components because attributes don't have to be defined as bean properties.
>
> Any thoughts?
>
> Gary
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
