Hi<br><br>After some attempts I was able to make it work ( see MYFACES-2638-6_5.patch ). I think I'll delay a little bit myfaces core 2.0.1 release, because this solution has enought importance to be included. Definitively, the way to go is use TemplateClient stuff here.<br>
<br>In the long term, it is necessary to think how to create a good api for TemplateClient stuff. Right now, DefaultFaceletContext / DefaultFacelet classes do too many things (generate facelets ids to isolate id generation between templates, template client api stuff, handle facelet inclusion ......). On myfaces, the position about change those classes is do not modify the code there too much, so in the future if a new API is published (jsf 2.1?) we could change the code without much effort.<br>
<br>In the next days I'll check this patch and document it better.<br><br>About mojarra issue 1684 (thanks for the hint), doing the patch it was clear what the intention of the current design: <br><br>1) What is the purpose of extendClient() and why just having pushClient() was<br>
not enough?<br><br>2) Why does CompositionHandler call extendClient(), while
DecorateHandler calls<br>
pushClient()?<br>
<br>On DefaultFaceletContext, there is a List<TemplateManager> that holds the current templates (clients) that are used to resolve a "spot" identified by a name.<br><br>The basic idea is when FaceletContext.includeDefinition(UIComponent parent, String name) is called, the algorithm try to resolve the "spot" from top to bottom. <br>
<br><ui:composition> and <ui:insert> are added at last, using extendClient(), but <ui:decorate> or user tag handlers create from xhtml use pushClient(). The idea is resolve in this order:<br><br>- ui:decorate spots defined by ui:define and user tag handlers created
from xhtml (again defined by ui:define).<br>- ui:composition spots defined by ui:define.<br>- ui:insert spots.<br><br>3) Why does InsertHandler call extendClient()() and why does it
implement<br>
TemplateClient?<br>
<br>Because ui:insert could expose a spot too, and it is resolved to there if no ui:define (exposed by ui:composition) with the name is exposed too.<br><br>best regards,<br><br>Leonardo Uribe<br><br><div class="gmail_quote">
2010/5/21 Andy Schwartz <span dir="ltr"><<a href="mailto:andy.schwartz@oracle.com">andy.schwartz@oracle.com</a>></span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Gang -<br>
<br>
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:<div class="im">
<br>
<br>
<a href="https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1684" target="_blank">https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1684</a><br>
<br></div>
Please review - interesting stuff.<br>
<br>
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.<br><font color="#888888">
<br>
Andy</font><div><div></div><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
---------- Forwarded message ----------<br>
From: Max Starets <<a href="mailto:max.starets@oracle.com" target="_blank">max.starets@oracle.com</a>><br>
Date: Fri, May 21, 2010 at 3:58 PM<br>
Subject: Re: [jsr-314-open] PostAddToViewEvent publishing conditions<br>
To: <a href="mailto:jsr-314-open@jcp.org" target="_blank">jsr-314-open@jcp.org</a><br>
Cc: <a href="mailto:dev@myfaces.apache.org" target="_blank">dev@myfaces.apache.org</a><br>
<br>
<br>
Hey Leonardo,<br>
<br>
You are right - the same issue reproduces with two nested<br>
ui:composition templates.<br>
I logged the following Mojarra issue for the problem:<br>
<a href="https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1684" target="_blank">https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1684</a><br>
<br>
I do not think we have to abandon the idea of using TemplateClient<br>
mechanism for for the composite component implementation<br>
because of this issue. You are already using a separate TemplateClient<br>
stack for composites in your patch, so we do not<br>
need to wait for the fix before implementing the correct behavior for<br>
composites. All we need is a stack with only one TemplateClient<br>
being considered 'current'. includeDefinition() should be checking the<br>
current TemplateClient only, and we should pop the current<br>
TemplateClient before calling TemplateClient.apply(), then restore<br>
(push) it when the apply() is done.<br>
<br>
Max<br>
<br>
<br>
Leonardo Uribe wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hi<br>
<br>
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.<br>
<br>
Look this example (I removed the non relevant code):<br>
<br>
testCompositeInsertChildren.xhtml (the page when it is used)<br>
<br>
<testComposite:compositeInsertChildren><br>
<h:outputText value="GAMMA " /><br>
</testComposite:compositeInsertChildren><br>
<br>
testComposite:compositeInsertChildren<br>
<br>
<composite:implementation><br>
<testComposite:compositeInsertChildrenInner><br>
<h:outputText value="BETA " /><br>
<composite:insertChildren /><br>
</testComposite:compositeInsertChildrenInner><br>
</composite:implementation><br>
<br>
testComposite:compositeInsertChildrenInner<br>
<br>
<composite:implementation><br>
<h:outputText value="ALFA " /><br>
<composite:insertChildren/><br>
<h:outputText value="OMEGA " /><br>
</composite:implementation><br>
<br>
The example should render this:<br>
<br>
ALFA BETA GAMMA OMEGA<br>
<br>
But it is rendered this:<br>
<br>
ALFA GAMMA OMEGA<br>
<br>
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.<br>
<br>
Suggestions are welcome.<br>
<br>
regards,<br>
<br>
Leonardo Uribe<br>
<br>
</blockquote></blockquote>
<br>
</div></div></blockquote></div><br>