[
http://issues.apache.org/jira/browse/TOMAHAWK-596?page=comments#action_12428562
]
Ryan Wynn commented on TOMAHAWK-596:
------------------------------------
Sorry for my sloppiness, Mike. I tested this patch on a different machine
which was setup with Portal Server on it. Then I created the patch by hand on
a different machine and missed the typecast. I realize this is not a good
practice at all.
The children are being rendered in encodeEnd through the call to renderFacet...
protected void renderFacet(FacesContext facesContext, HtmlDataScroller
scroller,
UIComponent facetComp, String facetName) throws
IOException
{
UIComponent link = getLink(facesContext, scroller, facetName);
link.encodeBegin(facesContext);
facetComp.encodeBegin(facesContext);
if (facetComp.getRendersChildren())
facetComp.encodeChildren(facesContext);
facetComp.encodeEnd(facesContext);
link.encodeEnd(facesContext);
}
I will only submit from my development machine from now on. By the way to
replicate this problem use the datascroller inside a portlet. Then click on a
link inside another portlet on the same page or any link on the same page which
is not part of the datascroller portlet.
> Duplicate id exception for HtmlDataScrollerRenderer
> ---------------------------------------------------
>
> Key: TOMAHAWK-596
> URL: http://issues.apache.org/jira/browse/TOMAHAWK-596
> Project: MyFaces Tomahawk
> Issue Type: Bug
> Components: Data Scroller
> Affects Versions: 1.1.3
> Environment: Linux, Windows
> Reporter: Ryan Wynn
> Attachments: HtmlDataScrollerRenderer.patch
>
>
> In a portlet environment a non-faces request produces an exception when the
> faces tree is rendered if the faces tree contains a DataScroller component.
> The HtmlDataScroller renderer actually renders its children twice in this
> case, once in the encodeChildren method and once in the encodeEnd method.
> Since rendering of the children is taken care of in encodeEnd I made the
> encodeChildren method a no-op. Also, although the CommandLinks which are
> rendered as children are marked as transient, they see to stick around. I
> put a check in the getLink methods to make sure that the links are not added
> twice. This seems to fix the duplicate id exception, but it might be
> necessary to further investigate why they are sticking around in the first
> place.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
