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

[Ken Paulsen]

Andy Schwartz wrote:
> 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"?
Perhaps it's best to explain visually:

Page author defines:
* Page A
    * compComp
       * facet "myfacet" : component X  <-- not a child of panelGrid

Component author defines:
* panelGrid
    * facet "caption" : *reference* facet "myfacet"  <-- non-child facet

So instead of re-parenting "component X" from "compComp" to "panelGrid", 
panelGrid maintains it's relationship that the page author defines.  
Today's behavior does the re-parenting as soon as you add it to the 
facet Map.  A proxy-component might be possible that acts like a 
"symbolic link" to the page author's component so that the page author's 
original component doesn't get moved.
>>> 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?
Yes, but afaik, only for the "rendering" of the component.  For example, 
if you ask for the "children" of the component put in as a place holder 
for rendering, I don't think you'll get the children defined by the page 
author... you'll get an empty list of children b/c there are no children 
of the placeholder itself.
>>> 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.
Yes, good point.
>> 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?
Yes, that's my current thinking.  I see Facelets (and JSFTemplating) 
primarily as a way to construct UIComponent trees.  So ui:insert is part 
of the templating language that pulls together component tree fragments 
in interesting ways.

I do not believe that UIComponent tree changes should happen outside of 
the component which is added to the tree.  The re-parenting that happens 
by composite:insertFacet causes the component tree that the page author 
specified to change.  This breaks encapsulation of the component model.
>>   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. ;-)
You should hear the things he says!  Ok... not really. ;-)  Not sure how 
he feels, but I appreciate your comments a lot.  :)
>>   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?
Yes, that is what I was trying to say.  I understand that may be much 
easier to *say* than implement, though, as it poses several challenges 
-- many of which I probably haven't thought through yet (such as how 
id's are resolved if it is inserted 2x or more).
>
> 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.
I agree, I like to think through these things as well for the sake of 
understanding it better.

Thanks!

Ken
>
> Andy
>
>