Gary, one more thing that would be nice would be if the parser allowed
symbols and there values to be specified on the component and element xml
elements.
 Would this be a difficult fix?
 For example,
<component jsfid="foo" extends="baz" mySymbol="bar" allowBody="false"/>
 <element renderId="1" jsfid="myComp" anotherSymbol="myBean"/>
 <element renderId="1" jsfid="myComp" anotherSymbol="anotherBean"/>
</component>
 I noticed that the Builder adds symbols to target ComponentBeans based on
whether or not the token is a known attribute.
 Could the component/element parser do the same; if not jsfid, extends, id,
allowBody, facetName, etc then add token as symbol?
 Right now the dtd stops you. But I think it might be nice to be able to
push the symbol definitions back to the component/element level in some
instances.
 For example, the above definition overrides the symbol anotherSymbol inside
myComp with 2 different values. I couldn't do this at the html level because
I would have to commit to 1 value for anotherSymbol. E.g. <span jsfid="foo"
mySymbol="bar" anotherSymbol="myBean"/>.
 I promise to chill out on the symbols after this!
 Thanks, Ryan


 On 10/31/05, Gary VanMatre <[EMAIL PROTECTED]> wrote:
>
> Ryan Wynn Wrote:
>
> >Currently, this is supported but only if value = [EMAIL PROTECTED] and
> valueExpr="myBean.property", because
> >the mnemonic replacement is done after the determination of whether or
> not the value isEL and isVB.
> >
> >So to allow for mnemonics to be replaced by #{foo.bar},
> PropertyValueCommand would need to change to do
> >the mnemonic replacement before determining isEL and isVB and isEarly.
> >
> >Any thoughts? I think this may be a better solution than the prior
> discussed solution for overriding horizontally.
> >
>
> That's a good idea and a simple fix. I'll add the symbol replacement on
> the string before checking for el. Also make the symbol replacement
> available to the early binding.
>
> I agree. This seems to be a very slick way to customize a subtree without
> creating a new hierarchy. Great ideas Ryan!
>
> Gary
>
>
>
>
>
>
>
>
> ---------- Forwarded message ----------
> From: Ryan Wynn <[EMAIL PROTECTED]>
> To: Struts User <user@struts.apache.org>
> Date: Mon, 31 Oct 2005 15:00:39 +0000
> Subject: Re: <Shale> Clay isEL and replaceMnemoic
> Sorry, had a mistake in my post. In the example the 2nd component would
> look
> like this.
> <component jsfid="bar" extends="parent">
> <attributes>
> <set name="valueExpr" bindingType="None" value="#{myBean.property}"/>
> </attributes>
> </component>
> or another approach would be
> <span jsfid="parent" valueExpr="#{myBean.property}"/>
>
> On 10/31/05, Ryan Wynn <[EMAIL PROTECTED]> wrote:
> >
> > It seems beneficial to allow a mnemonic to be replaced by an EL
> > expression. This could be another approach to the 'horizontal override'
> of
> > component subtree and reduce the need to replicate the structure of the
> > subtree in children.
> > For example,
> > <component jsfid="parent" extends="foo">
> > <element renderId="1" jsfid="child">
> > <attributes>
> > <set name="value" value="@valueExpr"/>
> > </attributes>
> > </element>
> > </component>
> > would allow a component to extend from parent an override the nested
> > value of child without duplicating the structure of parent just to
> override
> > a single attribute.
> > <component jsfid="bar" extends="parent" valueExpr="#{myBean.property}">
> > Currently, this is supported but only if value =
> [EMAIL PROTECTED]<[EMAIL PROTECTED]>and valueExpr="
> > myBean.property", because the mnemonic replacement is done after the
> > determination of whether or not the value isEL and isVB.
> > So to allow for mnemonics to be replaced by #{foo.bar},
> > PropertyValueCommand would need to change to do the mnemonic replacement
> > before determining isEL and isVB and isEarly.
> > Any thoughts? I think this may be a better solution than the prior
> > discussed solution for overriding horizontally.
> > Ryan
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Reply via email to