[jsr-314-open] #{compositeComponent.attrs....}

[Andy Schwartz]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20090415/ffa3cedb/attachment.html