Hey Ken -
Ken Paulsen wrote On 4/13/2009 12:22 PM ET:
Page
author won't have to
worry about the EZComp author masking their values.
Unless I am missing something here, the same is true if we go with a
"var" approach.
I think you mean "without" the var approach? The difference is the
page author can expect what the reserved word will be vs. every
component being different.
I am still confused about how the choice of the var name within a
composite component implementation impacts page authors. I was
thinking that the page author would not be exposed to this in any way.
I would expect that the page author wouldn't necessarily be able to
distinguish between a composite component an a plain old Java
component. So, yeah, I think I am missing something here.
To me the "var" approach seems much simpler than, say, requiring the
composite component author to manually move the attributes map to a
request-scoped variable. Also, a solution where we shove the
attributes map into some other scope (eg. request scope) has the
downside of raising the name collision problem again, since now we need
to compete with managed beans names that occupy that scope.
The above was not a suggested syntax, it's just one that works today.
If I had to pick a syntax on the fly, perhaps:
<f:alias var="foo" target="#{some.el}" />
Ah, okay - makes sense. Another naming option might be:
<f:var name="foo" target="#{some.el}">
BTW, would this tag wrap other tags/components so that the variable was
only active while descendents are being processed (like f:ajax)?
I
guess
the bottom line is that I can live with picking a standard
name, but the "var" approach seems more elegant to me, and not
especially confusing/complex, since this approach should already be
familiar to JSTL/JSF users. I can also live with not doing anything of
course, though it would be nice to provide a more concise syntax so
that composite component authors can tighten up their implementations.
I'm for it if its generalized (i.e. <f:alias /> type of
solution)), I don't see the rationale for making a special case here.
Sure, I am okay with a generalized solution as well. FWIW, I do see
benefit in providing a convenience API as well for the composite
component attributes map case, since this is going to be an amazingly
common case. If we did provide both solutions (where the
composite:implementation attribute was just shorthand for
f:alias/f:var), personally I would just use the attribute every time.
:-)
Andy