> 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.
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.
> Craig
>
Gary
