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

[Andy Schwartz]

Hey Ken -

Ken Paulsen wrote:
>
>
> Andy Schwartz wrote:
>>
>> This raises a number of questions.  Why do we re-parent the facet 
>> component when we want the component to be used by the parent 
>> component as a facet,
> There is no way to add a facet without it being re-parented.  Perhaps 
> we should have changed the behavior to allow non-child components to 
> be facets of a component.

This stuff is so complicated.  I am lost already. :-)  Can you explain 
what you mean by "allow non-child components to be facets of a component"?
>
>> but not when we want the component to be used by the parent as a 
>> direct child?
> As you pointed out, there is no way to add a component from the page 
> to a component in the EZComp as a child (only as a facet).  If it were 
> possible, under the current JSF code, it too would be re-parented.

Right.  I was thinking that ideally composite:insertFacet would cover 
both the insert as a child case as well as the insert as a facet case 
(like ui:insert).

>>   Is there a reason why we need to treat the direct child case 
>> differently (not re-parent) than the facet case (re-parent)?  Is 
>> there some benefit to having subtly different behavior between these 
>> two cases?
> Yes, the not-reparent case is not a child.  It is an omission and were 
> it to be added,it too would re-parent (unless we changed the rules).
>
> The reason the 2 tags are treated differently is this:  1 modifies the 
> component tree; the other occurs during rendering.  Two very different 
> phases in JSF.

Sure.  That explains how these two tags are different, which I 
understand.  What I am still confused about is why these two cases 
needed to be handled differently.

>
> If we were to explore not re-parenting, we'd probably need to create a 
> ProxyComponent which could be added to the child and delegate 
> everything to the real component which would remain on the parent.  
> That might work nicely.

This sounds fairly close to what composite:renderFacet is doing, right?


>> While the first case inserts the component as a facet and the second 
>> as a direct child, both have the same semantics - ie. in both cases 
>> the component that is being inserted ends up as a child of the parent 
>> component that the child is being inserted into.
> Which is wrong.  The parent ideally should be the *composite 
> component*.  Keep in mind the template is a black box that the page 
> author should not know anything about.  So if I do:
>
>    <my:ezComponent id="foo">
>       <f:facet name="myfacet">
>             <h:outputText id="usercomp" value="here" />
>       </f:facet>
>    </my:ezComponent>
>
> So looking at this page excerpt, you'd say the parent of "usercomp" is 
> "foo".  And if foo is a naming container, the clientId would be 
> something like: "...:foo:usercomp".
>
> However, if the implementation of the ezcomp component (that the page 
> author has no control over and no know knowledge of) is implemented 
> like this:
>
>    ...
>    <some:namingcontainer id="hiddenContainer">
>       <ui:insert facet="myfacet" />
>    </some:namingcontainer>
>    ...
>
> Then we have problems:
>
> 1)  The parent is *not* "foo" as the page author expected (and as 
> would be the case with ALL Java-based components).
>
> 2) The clienId is not what we expected: 
> "...:foo:...:hiddenContainer:myfacet"
>
> 3) Changes that a component author makes to the component will break 
> any code the page author writes that depends on the location or 
> clientId of the facet component.
>

Right.  These are very similar to the issues that I was concerned about 
with #{cc} resolution.

Of course, we are already exposed to these issues with 
composite:insertFacet, eg:

<composite:implementation>
  <f:subview>
    <h:panelGrid>
      <composite:insertFacet name="caption"/>
    </h:panelGrid>
  </f:subview>
</composite:implementation>

I have mixed feelings about this.  When I wrote my previous mail, I 
suppose I was thinking that if we are going to be exposed to this 
behavior in both composite:insertFacet and ui:insert, then I would 
rather just be consistent and lose the composite:renderFacet behavior.  
But I understand your concerns about breaking the page author's (ie. 
composite component user's) abstraction.

Let me think this over some more.

FWIW, another issue that we haven't talked about is the potential for id 
collisions between components that the page author adds to the composite 
component vs. components that the composite component defines itself in 
its implementation.


> Now... was facelets wrong w/ ui:insert?  Absolutely not...  In 
> facelets they were not making components, they were making pages.  The 
> page author had visibility and full control of the UIComponent tree 
> structure that was being created.  VERY different than the component 
> scenario.

Okay, but just to be clear....  It sounds like your take is that the 
re-parenting behavior of <ui:insert> is (at least somewhat) acceptable, 
but this behavior in <composite:insertFacet> is wrong.   Is that right?


>   Which is likely why facelets was never able to create real components.
>
>> Actually, Facelets provides an API that is specifically designed to 
>> handle this type of insertion: TemplateClient.  The TemplateClient 
>> API allows for clean/efficient insertion of included content into 
>> templates.  I believe that ui:define/ui:insert use this to insert 
>> included content directly into the target location, avoiding the need 
>> to re-locate the included components from one parent to another.  
>> This has benefits when re-applying tags over a restored component 
>> tree, since there is no need to repeatedly re-create (or re-locate) 
>> these components.
> Not sure I follow you.  But I "think" you're describing meta-data that 
> represents the "files" which define the UIComponent tree (aka, VAST).  
> Which is something I have been advocating for and can greatly help.  
> However, once components are instantiated as UIComponents, they do 
> either have to be relocated, copied, or proxied (never seen this done 
> in practice)... so I think there's more to it than what you suggest.

There is definitely more to it.  My comment was pretty vague. :-)

I need to take a closer look at how tag handler re-execution is handled 
now that we've got partial state saving in place.  In the old days we 
used to re-execute tags (both JSP and Facelets) against the restored 
component tree on postbacks.  If components were moved around since the 
tags were originally executed, this could lead to complications when 
attempting to re-apply tags to an existing component tree - eg. subtrees 
that were moved from one parent to another might be re-populated, 
leading to unnecessary component creation.  The TemplateClient solution 
avoids this, since inserted component subtrees are only ever populated 
to one parent (the target of the insertion).

It is possible that this is no longer an issue.  I'll poke around and see.


>>
>> If we had the ability to revisit the design now, my preferred 
>> solution would be to:
>>
>> 1. Deprecate/remove composite:renderFacet.
>> 2. Re-spec composite:insertFacet to match the behavior of ui:insert.
> I think we could do this if we can also ensure that components are NOT 
> re-parented.  Then we could provide the correct behavior AND provide a 
> nice syntax for component authors.  However, I don't envy the person 
> (Ryan) that has to implement this. :)

I am amazed that Ryan doesn't hate me by now.  Well, I  hope not anyway. ;-)

>   There are a lot of tags and code that would have to have 
> special-case stuff to make this happen.

Yep.  So just to make sure I understand where you stand... Are you 
saying that you agree that we could handle these two cases:

<!-- Insert "foo" facet into the component tree as a facet -->
<composite:implementation>
 <h:panelGrid>
   <f:facet name="caption">
     <composite:insertFacet name="foo"/>
   </f:facet>
 </h:panelGrid>
</composite:implementation>


<!-- Insert "foo" facet into the component tree as a (non-facet) child -->
<composite:implementation>
 <h:panelGroup>
   <composite:insertFacet name="foo"/>
 </h:panelGroup>
</composite:implementation>


With a single tag?  But that you prefer that the tag does not actually 
perform re-parenting, ie. that the parent for the inserted component is 
the composite component itself in both cases?

FWIW, even if we do not have the ability to make changes along these 
lines now, I am still interested in understanding/working through these 
problems so that we have a firm grasp of any limitations/complications 
present in our current APIs.

Andy