On 11/7/05, Gary VanMatre <[EMAIL PROTECTED]> 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. 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
