Re: Clay isEL and replaceMnemoic

[Ryan Wynn <bi...@gmail.com>]

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 <gv...@comcast.net> wrote:
>
> Ryan Wynn Wrote:
>
> >Currently, this is supported but only if value = #{@valueExpr} 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 <bi...@gmail.com>
> To: Struts User <us...@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 <bi...@gmail.com> 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 =
> #{@valueExpr}<%23%7B@valueExpr%7D>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: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>

Re: Clay isEL and replaceMnemoic

[Ryan Wynn <bi...@gmail.com>]

Actually, the more I think about this, I think it may be easier to use the
attribute set to accomplish this instead of changing the dtd. Maybe there
could be a new bindingType value (Symbol) to identify this type of
attribute. Or maybe an existing bindingType could be used somehow? Either
way these values would be added to the symbol map, and evaluated like
bindingType="Early"
 So my example would be something like
  <component jsfid="foo" extends="baz" allowBody="false"/>
 <attributes>
 <set name="mySymbol" value="bar" bindingType="Symbol"/>
 </attributes>
 <element renderId="1" jsfid="myComp">
 <attributes> <set name="anotherSymbol" value="myBean"
bindingType="Symbol"/>
 </attributes
 </element>
 <element renderId="2" jsfid="myComp">
 <attributes> <set name="anotherSymbol"
 value="anotherBean" bindingType="Symbol"/>
 </attributes
 </element>
</component>

 On 10/31/05, Ryan Wynn <bi...@gmail.com> wrote:
>
>  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 <gv...@comcast.net> wrote:
>
> > Ryan Wynn Wrote:
> >
> > >Currently, this is supported but only if value = #{@valueExpr} 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 <bi...@gmail.com>
> > 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 <bigwynnr@gmail.com > 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 =
> > #{@valueExpr}<%23%7B@valueExpr%7D>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: user-unsubscribe@struts.apache.org
> > For additional commands, e-mail: user-help@struts.apache.org
> >
> >
>