Re: [jsr-314-open] #{compositeComponent.attrs....}
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
Attachments:
- attachment.html (text/html — 3.5 KB)