[jsr-314-open-mirror] [jsr-314-open] Fwd: PostAddToViewEvent publishing conditions

[Andy Schwartz]

Gang -

Max did some investigation into the problems that Leonardo found when 
attempting to use the TemplateClient mechanism to implement composite 
component children/facet insertion.   It looks like there are some more 
fundamental problems here.  Max captured his thoughts in the following 
Mojarra issue:

https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1684

Please review - interesting stuff.

Note - we still think that using a TemplateClient-like approach should 
be possible for composite component insertion, so hopefully the 
implementations can continue to pursue this option.

Andy

> ---------- Forwarded message ----------
> From: Max Starets <max.starets at oracle.com>
> Date: Fri, May 21, 2010 at 3:58 PM
> Subject: Re: [jsr-314-open] PostAddToViewEvent publishing conditions
> To: jsr-314-open at jcp.org
> Cc: dev at myfaces.apache.org
>
>
> Hey Leonardo,
>
> You are right - the same issue reproduces with two nested
> ui:composition templates.
> I logged the following Mojarra issue for the problem:
> https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1684
>
> I do not think we have to abandon the idea of using TemplateClient
> mechanism for for the composite component implementation
> because of this issue. You are already using a separate TemplateClient
> stack for composites in your patch, so we do not
> need to wait for the fix before implementing the correct behavior for
> composites. All we need is a stack with only one TemplateClient
> being considered 'current'. includeDefinition() should be checking the
> current TemplateClient only, and we should pop the current
> TemplateClient before calling TemplateClient.apply(), then restore
> (push) it when the apply() is done.
>
> Max
>
>
> Leonardo Uribe wrote:
>   
>> Hi
>>
>> I tried the proposal of use some variation of TemplateClient API (I attach it as reference on MYFACES-2638-6.patch ). The solution works for simple cases, but it does not when nested composite components are used.
>>
>> Look this example (I removed the non relevant code):
>>
>> testCompositeInsertChildren.xhtml (the page when it is used)
>>
>> <testComposite:compositeInsertChildren>
>>    <h:outputText value="GAMMA " />
>> </testComposite:compositeInsertChildren>
>>
>> testComposite:compositeInsertChildren
>>
>> <composite:implementation>
>>    <testComposite:compositeInsertChildrenInner>
>>        <h:outputText value="BETA " />
>>        <composite:insertChildren />
>>    </testComposite:compositeInsertChildrenInner>
>> </composite:implementation>
>>
>> testComposite:compositeInsertChildrenInner
>>
>> <composite:implementation>
>>    <h:outputText value="ALFA " />
>>    <composite:insertChildren/>
>>    <h:outputText value="OMEGA " />
>> </composite:implementation>
>>
>> The example should render this:
>>
>> ALFA BETA GAMMA OMEGA
>>
>> But it is rendered this:
>>
>> ALFA GAMMA OMEGA
>>
>> The current algorithm do it correctly because the tree is completely built before relocate, so the listener relocates BETA too. Facelets executed the inner FaceletHandler instance first and then the outer ones. On composite components, it executes first the composite component facelet, then the FaceletHandler children.
>>
>> Suggestions are welcome.
>>
>> regards,
>>
>> Leonardo Uribe
>>