> On 11/7/05, Gary VanMatre wrote:
> >
> > > On 11/7/05, Gary VanMatre wrote:
> > > >
> > > > >So, are you thinking that "#{shale:managed-bean-name.save}" would be
> > > > >something that would evalutated entirely within a custom shale jsf
> > > > >VariableResolver or would the symbol replacement be done in the clay
> > > > chain (
> > > > >i.e. replaceMnemonic) and then passed to the standard
> > VariableResolvers?
> > > >
> > > > A custom VariableResolver is what I was thinking. The variable
> > resolver
> > > > would use the symbol table cached in thread scope to resolve the
> > symbols.
> > > >
> > > > I'm hoping that Craig will be able to help out on this one:-)
> > >
> > >
> > > Ryan's idea is definitely a good one. And it raises a quick question ...
> > is
> > > the ClayContext already stored as a request attribute under name
> > > "clayContext"? If so, we might not need much help at all.
> > >
> >
> > Nope, it's not but wouldn't hard to push it there. Something I'm not
> > certain about is when a variable resolver would be invoked. Is it when the
> > binding object is created or when the binding is invoked? If it's when the
> > binding is created, I think that request scope would work out. Otherwise, I
> > believe there will be a scoping issue.
>
>
> It's invoked when you evaluate the expression, not when the binding is
> created, so things should work fine.
>
Sorry, I didn't do a very good job of explaining. I was trying to describe the
recursiveness of the XML where symbols defined in a outer scope are passed on
to nested components but nested components can override.
<component jsfid="street" extends="inputText">
<attributes>
<set name="styleClass" value="#{shale.attributes.class}"/>
<set name="value" value="#{shale.managed-bean-name.street1}"/>
</attributes>
<symbols>
<set name="class" value="defaut"/>
</symbols>
</component>
<component jsfid="addressPanel" extends="panelGrid">
<attributes>
<set name="columns" value="1"/>
</attributes>
<element renderId="0" jsfid="baseInput" id="street1"/>
<element renderId="1" jsfid="baseInput" id="street2">
<symbols>
<set name="class" value="override"/>
</symbols>
</element>
</component>
In this example, street1 should have a 'styleClass=default' and
street2 will have a 'styleClass=override'.
Unless the "class" symbol was saved multiple times in the request with a unique
name, the last value would take precedence.
> When the AssignChildrenCommand is invoked, it builds the current symbol
> > table. This is "scoped" for the creation of the child. The component symbol
> > metadata (ComponentBean.getSymbols()) overrides anything in an outer
> > scope. If the child is a nested clay component, the managed bean name will
> > also override the current value in the symbol table. Since the symbol
> > replacement happens before the binding expression is established, the
> > resulting value is kept by the component.
>
>
> Sounds good.
>
> > Craig
> > >
> >
> > Gary
> >
>
> Craig
>
Gary
