[jsr-314-open] composite:insertFacet target facet name

[Ken Paulsen]

I remember discussing this issue on one of our phone calls (when it was 
still considered an "attached object").  It was one of my issues I was 
concerned with (for all "attached objects") and thought we had arrived 
at a consensus that we could *default* to the same name, but have a way 
to explicitly provide a name to solve the problem Andy has correctly 
pointed out.  I might have to go back and listen to our old audio 
recordings....

IMHO, this should be solved quickly.

Ken

Andy Schwartz wrote:
> Gang -
>
> As currently specified, composite:insertFacet's "name" attribute 
> serves two purposes:
>
> 1. It identifies the name of the facet on the containing composite 
> component to insert.
> 2. It identifies the name of the facet on the target component into 
> which the facet is being inserted.
>
> As a result, the name of the facet exposed by the composite component 
> must match the name of the facet on the implementation component into 
> which the facet is being inserted.  So, for example, if I have a 
> composite component as follows:
>
> <composite:interface>
>  <composite:facet name="caption"/>
> </composite:interface>
>
> <composite:implementation>
>  <h:panelGrid>
>      <composite:insertFacet name="caption"/>
>  </h:panelGrid>
> </composite:implementation>
>
>
> Everything is happy, since both the composite component and the 
> h:panelGrid expose a "caption" facet.
>
> However, if I want to define a composite components with two 
> h:panelGrid components and two captions:
>
> <composite:interface>
>  <composite:facet name="caption"/>
>  <composite:facet name="backupCaption"/>
> </composite:interface>
>
> <composite:implementation>
>  <h:panelGrid>
>     <composite:insertFacet name="caption"/>
>  </h:panelGrid>
>
>  <h:panelGrid>
>    <!-- Uh oh. -->
>    <composite:insertFacet name="backupCaption"/>
>  </h:panelGrid>
> </composite:implementation>
>
>
> I am out of luck, since I now have a mismatch between the composite 
> component facet name and the h:panelGrid facet name.  Or, at least, I 
> think I am out of luck...  Am I missing some way to handle this use case?
>
> If the spec does not yet provide a solution for this, I think that we 
> could/should solve this in one of two ways:
>
> 1. Add an attribute to composite:insertFacet that allows a target 
> facet name to be specified:
>
>  <h:panelGrid>
>    <composite:insertFacet name="backupCaption" targetName="caption"/>
>  </h:panelGrid>
>
> 2. Specify that the target facet name can be picked up from a wrapping 
> <f:facet> tag:
>
>  <h:panelGrid>
>    <f:facet name="caption">
>      <composite:insertFacet name="backupCaption"/>
>    </f:facet>
>  </h:panelGrid>
>
> I prefer #2 since is consistent with typical facet usage.
>
> Thoughts?
>
> BTW, this seems like a fairly severe limitation to me.  Is there any 
> chance that we can correct this by spec'ing the behavior from #2 in 
> the next MR?  Of course, I am not sure what the rules are for MRs...  
> In this case we aren't so much adding new APIs (no new 
> attributes/tags) so much as specifying behavior for a particular use 
> of existing APIs (<composite:insertFacet> inside of <f:facet>) that 
> was previously unspecified.
>
> Andy
>