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