Gary,
overriding the behavior of the getId and setId in the ValidatorBean,
ValueChangeListenerBean and ConverterBean is not enough.
Since these can potentially inherit from a plain ComponentBean, the will
inherit the attributes of that ComponentBean.
For example, commons validator is defined
<component jsfid="commonsValidator" id="commonsValidator" componentType="
org.apache.shale.CommonsValidator" allowBody="false">.../<component>
so when I say <validator jsfid="commonsValidator">...<validator>
my validator is going to inherit the id from it's parent in
ComponentConfigBean.realizingInheritance and later cause an exception trying
to set property id.
To fix, we need to also in ValidatorBean, ValueChangeListenerBean and
ConverterBean override addAttribute and setAttributes to not store the id
attribute.
On 11/4/05, Gary VanMatre <[EMAIL PROTECTED]> wrote:
>
> >What do you mean by letting 1 component morph into another with respect
> to
> >Validator, ValueChangeListener, and Converter?
>
> You could do something like this:
> <component jsfid="maxTransferAmt" componentType="javax.faces.LongRange">
> <attributes>
> <set name="maximum" value="100"/>
> <set name="minumum" value="10"/>
> </attributes>
> </component>
>
> <component jsfid="maxTransferExAmt" extends="maxTransferAmt"
> componentType="javax.faces.DoubleRange"/>
>
>
> <component jsfid="transferAmt" extends="inputText">
> <attributes>
> <set name="value" value="managed-bean-name.transferAmt"/>
> </attributes>
> <validator jsfid="maxTransferExAmt"/>
> </component>
>
>
> In this example the attributes of the double validator inherit from the
> long. It could be that one validator extending/morphing another could define
> attributes that don't apply to the subclass. This would throw an exception
> for Converters, Validators and Listeners.
>
>
> >I think overriding the behavior of those types is probably the right
> thing
> >to do. Does this disallow the morphing feature?
>
> No it shouldn't effect morphing, overriding the behavior is the the right
> thing to do.
>
> Gary
>
>
>
>
>
>
>
> ---------- Forwarded message ----------
> From: Ryan Wynn <[EMAIL PROTECTED]>
> To: Struts Developers List <dev@struts.apache.org>
> Date: Fri, 4 Nov 2005 21:08:17 +0000
> Subject: Re: [shale] clay storing id state in attributes
> 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]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
