> > >
> > > This will become even more important in a JSF 1.2 world, because the EL
> > > expression evaluation machinery has been pulled out into its own spec
> > (and
> > > its own package namespace) that can be used completely independently of
> > the
> > > web tier. Off the top of my head, maybe something like:
> > >
> > > #{shale:attribute.managed-bean-name}
> > >
> > > or
> > >
> > > #{shale:attribute.class}
> > >
> > > ?
> >
> > I like the looks of that but how would we handle the managed bean name?
> > #{#{shale:attribute.managed-bean-name}.address1}
>
>
> Note that my original example should probably have been
>
> #{shale:managed-bean-name}
>
> because we're not actually talking about an attribute here.
>
> The issue you raise, of course, is that you're actually trying to replace
> part of the expression itself (rather than the whole thing). But, maybe that
> isn't really necessary? Maybe the evaluaton of the "shale:managed-bean" part
> of the following expression could return the real managed bean *instance*,
> instead of just it's name? Then you'd just use:
>
> set name="action" value="#{shale:managed-bean.saveAction}"/>
>
> on a button component, without needing any textual substitution of the
> expression itself.
>
Ok, I see what you mean now. That looks good, has some style.
> For the class substitution case that conditionally sets styleClass only if
> class is actually specified, either the element would need to be smart
> about knowing whether there was really a value there, or we could do a "set
> if" operation that only performed the set if the expression evaluated to
> something other than null or empty string:
>
> <set-if name="styleClass" value="#{shale:attribute.class}"/>
>
> where the expression would evaluate the value of the "class" attribute, if
> it exists, and perform the set only if a non-null non-empty-string value was
> returned by evaluating the expression.
>
That's a interesting idea. Or, we might be able to use a new "bindingType" in
the "set" node. But, a "set-if" might be more descriptive.
> Doing this kind of thing would require some interesting logic in the custom
> variable resolver and property resolver implementations, to allow evaluation
> of things like "shale:managed-bean" and "shale:attribute" to do the right
> things. But, storing context information in a thread-local variable would
> likely be up to the task.
>
The symbol info and the current attributte is already being pushed to the
Command context, ClayContext.
We could change the ClayContext to use thread scope.
> Hmm ... I wonder if we could eliminate the need to explain what
> "useValueLateBinding" is all about, using similar thinking?
>
I removed that silliness a few weeks ago and made it more like how the JSF
component attributes are described.
I replaced it with a bindingType attribute:
<!--
The BindingType enumeration defines how Expression Language (EL) binding is
handled.
VB - Use Value Binding
MB - Use Method Binding
None - No use of EL. The value passes through
Early - EL evaluated before setting the component property/attribute.
-->
<!ENTITY % BindingType "(VB|MB|None|Early)">
> Craig
>
Gary
