[jira] [Commented] (MYFACES-3514) cc:insertChildren must relocate user tag handlers other tags that contains markup too

["Leonardo Uribe (Commented) (JIRA)" <de...@myfaces.apache.org>]

    [ https://issues.apache.org/jira/browse/MYFACES-3514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13240945#comment-13240945 ] 

Leonardo Uribe commented on MYFACES-3514:
-----------------------------------------

After thinking about it, I consider use c:if and any user tag (tag that is created adding a <source>  entry pointing to a .xhtml file into taglib.xml) should be just relocated like ui:decorate.

It is clear a new interface called  org.apache.myfaces.view.facelets.tag.ComponentContainerHandler is necessary to identify such tags and include them in a pluggable way into cc:insertChildren special logic.

                
> cc:insertChildren must relocate user tag handlers other tags that contains markup too
> -------------------------------------------------------------------------------------
>
>                 Key: MYFACES-3514
>                 URL: https://issues.apache.org/jira/browse/MYFACES-3514
>             Project: MyFaces Core
>          Issue Type: Bug
>         Environment: MyFaces 2.1.6, Tomahawk20 1.1.11
>            Reporter: dennis hoersch
>
> Hello,
> 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.
> ------
> Hi Leonardo,
> 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 (?)...)
> Greetings,
> dennis
> Hi Dennis
> 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
> to:
> - javax.faces.view.facelets.ComponentHandler.class
> - InsertChildrenHandler.class
> - InsertHandler.class
> - DecorateHandler.class
> - IncludeHandler.class
> - TextHandler.class
> - UserHagHandler.class
> 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
> https://issues.apache.org/jira/browse/MYFACES
> so I can fix it?
> regards,
> Leonardo
> 2012/3/27 Dennis Hörsch <ho...@his.de>:
> > Hi,
> >
> > 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:
> >
> > Hi
> >
> > 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 (
> > org.apache.myfaces.view.facelets.tag.composite.CompositeComponentResourceTagHandler),
> > and try to detect better cases like the one described here.
> >
> > regards,
> >
> > Leonardo Uribe
> >
> > 2012/3/26 Dennis Hörsch <ho...@his.de>:
> >
> > Hey,
> >
> > 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" ... />
> >     </his:someTagHandlerTag>
> > </his:someCompositeComponent>
> >
> > 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
> >

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira