I committed the patch, provided by Kamaran. -Matthias
On Fri, Aug 22, 2008 at 5:04 PM, Andrew Robinson <[EMAIL PROTECTED]> wrote: > +1 I never liked the application functionality in the tree or table > (expand all, collapse all, select all, unselect all), these should be > child components, not hard coded into the main component, it just > takes too much flexibility away from the page developer. > > On Thu, Aug 21, 2008 at 4:45 PM, Gary VanMatre <[EMAIL PROTECTED]> wrote: >> +1 Sounds like a solid plan that could result in a significant performance >> boost >> >> Gary >> -------------- Original message ---------------------- >> From: "Kamran Kashanian" <[EMAIL PROTECTED]> >>> There is some code in the Trinidad UIXTree which is intended to prevent the >>> user from doing an unbounded "Expand All" on large trees (see >>> UIXTree.broadcast() method. Specifically >>> HierarchyUtils.__handleBroadcast()). >>> >>> The code counts the number of newly expanded nodes and if it is > 100 then >>> it counts the total number of nodes in the tree and if the total is also > >>> 100, it prevents an expand all and only expands two levels. >>> >>> There are several issues with this: >>> >>> 1) This code is executed on every expand/collapse event and can be >>> expensive. Counting 100 nodes in the RowKeySet and in the tree (see >>> TableUtils._getSizeOfTree()) can force the model to do additional data >>> fetches beyond what is currently displayed in the view port. Also the number >>> 100 is completely arbitary. >>> >>> 2) There is no way to for this code to know if the user did an "Expand All" >>> or just did something to cause 100 nodes to expand. For example "Expand All >>> Below", or just select 100 nodes and do "Expand" from a menu. In these cases >>> the user will get unexpcted results (only two levels will expand) >>> >>> 3) Preventing the user from doing an Expand All should really be part of >>> application logic and has no place in the framework. Normally the >>> application would display a warning and ask the user if they really want to >>> do an expand all in response to a user action >>> >>> >>> [Proposal] >>> >>> I would like to propose that this code be removed from UIXTree. I will >>> submit a patch if there are no strong objections. This *is* a change in the >>> Trinidad tree functionality, and I am not sure how it impacts current users. >>> >>> >>> Thanks >>> Kamran >> >> >> >> >> ---------- Forwarded message ---------- >> From: "Kamran Kashanian" <[EMAIL PROTECTED]> >> To: [email protected] >> Date: Thu, 21 Aug 2008 20:36:15 +0000 >> Subject: [Trinidad] [Proposal] Tree "Expand All" handling >> There is some code in the Trinidad UIXTree which is intended to prevent the >> user from doing an unbounded "Expand All" on large trees (see >> UIXTree.broadcast() method. Specifically HierarchyUtils.__handleBroadcast()). >> >> The code counts the number of newly expanded nodes and if it is > 100 then >> it counts the total number of nodes in the tree and if the total is also > >> 100, it prevents an expand all and only expands two levels. >> >> There are several issues with this: >> >> 1) This code is executed on every expand/collapse event and can be >> expensive. Counting 100 nodes in the RowKeySet and in the tree (see >> TableUtils._getSizeOfTree()) can force the model to do additional data >> fetches beyond what is currently displayed in the view port. Also the number >> 100 is completely arbitary. >> >> 2) There is no way to for this code to know if the user did an "Expand All" >> or just did something to cause 100 nodes to expand. For example "Expand All >> Below", or just select 100 nodes and do "Expand" from a menu. In these cases >> the user will get unexpcted results (only two levels will expand) >> >> 3) Preventing the user from doing an Expand All should really be part of >> application logic and has no place in the framework. Normally the >> application would display a warning and ask the user if they really want to >> do an expand all in response to a user action >> >> >> [Proposal] >> >> I would like to propose that this code be removed from UIXTree. I will >> submit a patch if there are no strong objections. This *is* a change in the >> Trinidad tree functionality, and I am not sure how it impacts current users. >> >> >> Thanks >> Kamran >> >> >> > -- Matthias Wessendorf Need JSF and Web 2.0? http://code.google.com/p/facesgoodies further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
