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

[Leonardo Uribe]

Hi

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.

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.

In the next days I'll check this patch and document it better.

About mojarra issue 1684 (thanks for the hint), doing the patch it was clear
what the intention of the current design:

1) What is the purpose of extendClient() and why just having pushClient()
was
not enough?

2) Why does CompositionHandler call extendClient(), while DecorateHandler
calls
pushClient()?

On DefaultFaceletContext, there is a List<TemplateManager> that holds the
current templates (clients) that are used to resolve a "spot" identified by
a name.

The basic idea is when FaceletContext.includeDefinition(UIComponent parent,
String name) is called, the algorithm try to resolve the "spot" from top to
bottom.

<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:

- ui:decorate spots defined by ui:define and user tag handlers created from
xhtml (again defined by ui:define).
- ui:composition spots defined by ui:define.
- ui:insert spots.

3) Why does InsertHandler call extendClient()() and why does it implement
TemplateClient?

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.

best regards,

Leonardo Uribe

2010/5/21 Andy Schwartz <andy.schwartz at oracle.com>

> 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
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20100522/bf308422/attachment-0002.html