>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:-) Gary
--- Begin Message ---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? On 11/7/05, Gary VanMatre <[EMAIL PROTECTED]> wrote: > > Ryan Wynn wrote: > >I like the direction this is going. My thoughts on this... > >I like the syntax familiar syntax <set-if name="styleClass" > value="#{shale:attribute.class}"/> > > > >However, how about instead of inventing a new syntax "#{shale: > attribute.class}" we use > >the existing one. For example > > > > <set name="styleClass" value="#{clayContext.symbols['class']}"/> > > > >This approach assumes that clay has defined the existing clay context as > a > >managed-bean in request scope and pushed it's value appropriately during > the > >evaluation. So styleClass is evaluted just like any other VB. > >This also takes care of the set-if case, because if the symbol is not > >defined in the symbols map then the result will be null, and you would > not > >get <span class="">..</span> but rather the correct response of > ><span>...</span> in the case that the class symbol is not set. > > > >So just to explain further.. in clays faces-config.xml > > <managed-bean> > > <managed-bean-name>clayContext</managed-bean-name> > > <managed-bean-class>org.apache.shale.clay.component.chain.ClayContext > ></managed-bean-class> > > <managed-bean-scope>request</managed-bean-scope> > ></managed-bean> > > > >That way there is not need to invent a new el evaluation and no need to > add > ><set-if> > > Ryan, you have a good point. This could be made simpler in terms of > implementation. But, it sounds as if the namespace qualifier is more inline > with the future of EL. I wouldn't be against the simpler syntax but the > "#{shale:managed-bean-name.save}" looks pretty slick. > > I don't think the managed bean name would work with this syntax > "#{symbols['managed-bean-name'].saveAction} since it's a partial > replacement. > > I guess that something like this might work, '#{managedBeanName['save']}', > where the managedBeanName is a custom map implementation and it returns > another expression, #{mybean.save}. > > > > Gary > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
--- End Message ---
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
