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:
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(a)oracle.com>
Date: Fri, May 21, 2010 at 3:58 PM
Subject: Re: [jsr-314-open] PostAddToViewEvent publishing conditions
To: jsr-314-open(a)jcp.org
Cc: dev(a)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
>