[ 
http://issues.apache.org/jira/browse/TOMAHAWK-596?page=comments#action_12428702 
] 
            
Ryan Wynn commented on TOMAHAWK-596:
------------------------------------

I hear what you are saying about the facet and non-fact children.  But that is 
not the behavior I am experiencing.  What happens if I do not comment out the 
lines in the encodeChildren method is that I get 2 rows of paging links instead 
of 1.  Like this...

12345678910
1 2 3 4 5 6 7 8 9 10

underneath my table.  And for some reason the first row is rendered as one 
anchor with 123456 (all the pages)... inside it.  While the second row behaves 
properly with each page having it own anchor.

It's really weird but the patch seems to fix it.  It only happens when you 
force a nonFacesRequest in a portlet environment by clicking anywhere outside 
of your 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

        

Reply via email to