Furthermore, I want to point out that the java.util.List interface itself supports lazy loading when needed. There is nothing holding you back creating a consistent implementation of the List interface that only initializes those elements that are requested. You could, e.g., extend <a href="http://java.sun.com/j2se/1.4.2/docs/api/java/util/AbstractList.html">java.util.AbstractList</a>? But, below, I think I show that lazy Lists are not what we need.
Lastly, it became pretty clear to us that, even with medium sized trees, you certainly get a bandwidth problem with client-side trees (see the wiki entry). So, if lazy loading makes sense (it's only worth the effort with medium sized or large trees), you are certainly using a server-side tree. In any case, the laziness can only mean that a TreeNode will not be asked for it's children when it is collapsed. When it is asked for it's children, we need all the children in any case. So there is no sense in supplying a lazy list?
Now, thinking about this, I do see some sense in a separate isLeaf() method, that has to uphold the invariant (getChildren().size() == 0) <==> isLeaf(), where we promise that tree2 will call getChildren() only when we actually need the children to render them (or process them in the next request/response cycle, in earlier phases, if they were rendered -- their parent was expanded -- in the previous request/response cycle). But I don't see the need for a separate getChildrenCount() method.
Enlighten me.
On 26 Aug 2005, at 19:55, CONNER, BRENDAN (SBCSI) wrote:
There actually are subtle differences among isLeaf(), getChildren.size(), and getChildCount() that are useful:<x-tad-smaller>Met vriendelijke groeten,
1. When doing "on-demand" population of the tree, isLeaf() can be false even though there are no children loaded yet (i.e., getChildCount() == 0).
2. I believe that getChildCount() is available for performance reasons in situations where actually getting the children just to determine the list size can be expensive.
- Brendan
-----Original Message-----
From: ir. ing. Jan Dockx [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 25, 2005 6:26 PM
To: Dennis Byrne (JIRA); MyFaces Discussion; sean schofield (JIRA)
Subject: Re: [jira] Commented: (MYFACES-447) tree2 TreeNode interface has too many methods
Now we are on the list, and we can discuss this ;-).
The first suggested patch doesn't influence anybody, actually, since the methods that are removed from the interface are not used by any tree2 code. And TreeNodeBase keeps behaving as it did before (actually, for it should better be changed too, but it should stay in now at least for backward compatibility reasons).
The second suggested patch takes cleaning up the interface further. But since the differences between isLeaf(), getChildren().isEmpty() and getChildCount() == 0 on the one hand, and getChildren().size() and getChildCount() on the other hand, are rather obscure (and, as far as I can see, not applied consistently in the existing tree2 code either), I bet that there are not that many users out there that depend on the differences. If so, please let me know here: it might increase my understanding of the differences.
And if your current implementation of a TreeNode is consistent (getChildCount() == getChildren().size() and isLeaf() <==> getChildren().isEmpty() <==> getChildCount() == 0), this change will not affect your code either, since that is how the code is changed in tree2 implementation.
On 26 Aug 2005, at 1:10, sean schofield (JIRA) wrote:
[ http://issues.apache.org/jira/browse/MYFACES-447?page=comments#action_12320067 ]Met vriendelijke groeten,
sean schofield commented on MYFACES-447:
----------------------------------------
No you did not miss a discussion. Don't worry this patch will not be applied in the short term for a few reasons. The first reason is that it is too close to release time to change an interface. The second reason is that we will need to do extensive review and consultation with users before a major change such as this.
I'm definitely interested in improving tree2 so I will take a close look at this patch when I get a chance. We can discuss the changes now even if we don't make them for a while.
@Jan
JIRA is a good place to discuss matters like this (especially when patches are provided to help illustrate the requestor's point.) In the future can you also email the user list if you have a *major* change of this nature? Let them know the JIRA link. That way nobody gets left out of a crucial discussion. Bug fixes or minor feature additions (that's don't impact existing features, interfaces) can go directly to JIRA though. This is kind of a special case b/c its a major change.
@Dennis
You may want to add yourself as a watcher to issues when you do spot them on the dev list. Now that you know you're interested, why take the chance on missing out on an important discussion?
tree2 TreeNode interface has too many methods
---------------------------------------------
Key: MYFACES-447
URL: http://issues.apache.org/jira/browse/MYFACES-447
Project: MyFaces
Type: Improvement
Components: Tomahawk
Versions: Nightly Build
Reporter: Jan Dockx
Attachments: tree2_TreeNode_extensive_patch.txt, tree2_TreeNode_extensive_patch_examples.txt, tree2_TreeNode_patch.txt
The TreeNode interface is the hook for the backing bean developer, the user, into the tree2 framework. As such, the interface should pose minimal requirements for the user. It should only require from the user to implement those methods that are strictly needed for the framework to work, and leave as much freedom for the user as possible.
The patch included removes unnecessary methods. Apart from a minor change in TreeNodeBase, the change doesn't affect the existing tree2 code, nor the example, at all.
The patch also contains some documentation for the interface, and some suggestions for further changes.
--
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
Jan Dockx
PeopleWare NV - Head Office
Cdt.Weynsstraat 85
B-2660 Hoboken
Tel: +32 3 448.33.38
Fax: +32 3 448.32.66
PeopleWare NV - Branch Office Geel
Kleinhoefstraat 5
B-2440 Geel
Tel: +32 14 57.00.90
Fax: +32 14 58.13.25
http://www.peopleware.be/
http://www.mobileware.be/
Jan Dockx
</x-tad-smaller><x-tad-smaller>
PeopleWare NV - Head Office</x-tad-smaller><x-tad-smaller>
Cdt.Weynsstraat 85
B-2660 Hoboken
Tel: +32 3 448.33.38
Fax: +32 3 448.32.66 </x-tad-smaller><x-tad-bigger>
</x-tad-bigger><x-tad-smaller>
PeopleWare NV - Branch Office Geel</x-tad-smaller><x-tad-smaller>
Kleinhoefstraat 5
B-2440 Geel
Tel: +32 14 57.00.90
Fax: +32 14 58.13.25</x-tad-smaller><x-tad-bigger>
</x-tad-bigger><x-tad-smaller>
http://www.peopleware.be/
</x-tad-smaller><x-tad-smaller>http://www.mobileware.be/</x-tad-smaller>
smime.p7s
Description: S/MIME cryptographic signature
