I just copied the emails of the problem that not all children of composite components will be rendered out of the dev-list in here.
that was my first attempt too. But as I mentioned earlier, we have also own TagHandlers (no UserTagHandlers, they extends TagHandler) - that ones will be still ignored... Maybe there can be a special marker interface? So that the 'list' is more dynamically? (But I am not very glad with this solution if anyone having own tag handlers must do a special thing to get them work with composite components ...)
I have checked the code and I think we can consider all UserTagHandler
instances as containers of components (just like DecorateHandler and
IncludeHandler). That means if <cc:insertChildren> is used, all
instances of UserTagHandler should be executed in the place when
<cc:insertChildren> is called. So we just need to increase the list
After looking carefully this issue, it seems we need to include <c:if>
and <c:choose> too.
Could you please create an issue for this one in
so I can fix it?
2012/3/27 Dennis Hörsch <email@example.com>:
> I was expecting that composite components behave like any other.
> I am currently updating a big project from JSF1 to 2. We have many usages of
> JSTL as 'child'-components. And our 'old-fashioned' facelets components now
> are UserTagHandlers in the end. This ones will also be ignored...
> I had a look an at CompositeComponentResourceTagHandler and changed it in
> the way that 'newly' added childs are stored and will later be added to the
> right component. My simple test scenario works, but I have no clue about
> Partial State Saving and if there are any other cases that may be affected.
> I attached it, can you have a look?
> Thank you,
> dennis hoersch
> Am 26.03.2012 22:42, schrieb Leonardo Uribe:
> Difficult question. You should avoid that trick, or at least use c:if
> inside you custom tag to make it work properly. Really there are some
> details that will not work as expected.
> First of all, <c:if> code has changed since the original code inside
> facelets, to ensure proper operation with JSF 2.0 Partial State
> Saving. It is very complex to explain, but in resume, no component
> like c:if can be created without rely in some implementation details.
> The second part is composite component algorithm cannot recognize the
> tag as a tag containing component instances, so if the composite
> component uses cc:insertChildren, the part related to the tag will not
> be applied correctly. The solution in this case is use a composite
> component or a normal component instead a facelets user tag. Anyway,
> maybe we can do something better in this part (
> and try to detect better cases like the one described here.
> Leonardo Uribe
> 2012/3/26 Dennis Hörsch <firstname.lastname@example.org>:
> I have a problem with composite components. The scenario is as follows:
> <his:someCompositeComponent id="outer">
> <h:inputText id="first" ... />
> <his:someTagHandlerTag condition="bla">
> <h:inputText is="second" ... />
> The problem is, only the first input field is rendered. The second is not.
> After building the component tree, the first is a child of the 'composite
> component'-facet of the surrounding UINamingContainer (outer), the second
> ends as child of the UINamingContainer. The 'HtmlCompositeComponentRenderer'
> renders only the children of the facet.
> The 'someTagHandlerTag' is handled by a subclass of TagHandler. If the
> condition is true, it calls the nextHandler (second-input field) which adds
> the input as child to the composite component.
> It is the same with the JSTL-Tags: If I have a 'c:if' inside a composite
> component, it will not be rendered in any case.
> Is this how it should be? Or should this tags also be rendered (handled) as
> childs using composite components?
> I hope that I could clarify the problem
> Thank you,
> dennis hoersch