Sorry for not being able to answer earlier. Am Freitag, 20. Juli 2007 09:38 schrieb Derick Rethans: > On Thu, 19 Jul 2007, Thomas Nunninger wrote: > > > I just added a draft [1] and prototype [2] of the Tree component > > > to SVN. Please have a look at it. > > > > I had a short look at your design document and the prototype. Here > > are some notes/ideas: > > > > - Wouldn't it be nice to provide some credentials to the tree? > > Perhaps it's even possible to implement different credential > > drivers (ACL, eZ publish like, ...). Some backends (e.g. LDAP or a > > specialized tree implementation, like eZ publish's content_tree) > > could benefit of faster results as they do not need to fetch all > > data from the backend and the application checks the user's rights > > via PHP. > > > > Perhaps you don't need to provide any credential implementation > > with the component - just enable developers to integrate credential > > checking easily. > > Well, the idea is that a credential system could be *made* with this > tree component. From the requirements I quote: > > Use Cases > --------- > > * ACL as PHPGACL: http://phpgacl.sourceforge.net
My comments are somehow related to other posts in this thread. My idea was somehow like the content tree in eZ Publish where section information or some other meta data is stored. When fetching a subtree (of the content tree), the credentials can filter on the metadata to return only the nodes the user can access. I see no way, how this could be done for ACL based credentials via SQL. Probably you can't avoid the extra checking via PHP. But for easier systems like the actual in eZ Publish it could provide performance. This could probably be done with the hooks/interfaces: extending the query (SQL/LDAP/whatever) when fetching the nodes and callbacks for checking each single node after fetching from the storage (e.g. ACL). Have a nice day Thomas > > > - If I understood right, the persistent object component is very > > efficient related to memory and reusing objects when fetching > > several objects. (I didn't used it till now in practice.) If I have > > a look ezcTreeDbParentChild::fetchSubtree() this is not efficient > > at all as it loads all objects into memory. Isn't it possible to > > create some kind of iterator, fetching the subtree's nodes more > > efficiently? > > Actually, I did think of this. At the moment it *does* load all the > tree nodes into memory, but it does not fetch the data immediately > (there is no fetchByID call on the store). The > ezcTreeNodeListIterator does exactly what you say, it iterates over > the nodes, and fetches the data from the store on demand, see > http://svn.ez.no/svn/ezcomponents/experimental/Tree/src/tree_node_lis >t_iterator.php > > However, I do plan on implementing a fetchDataByNodeIDList (or a > better name as well) as in that case you'd only need one SQL query to > fetch all record or Persistent Objects, increasing memory load, but > decreasing database load. > > > - As some of the operations can be very expensive: what's about > > caching of results and perhaps some intelligent cache purging if > > the the tree gets updated. (I'm not sure if this is a good idea at > > all - just wanted to mention it.) > > It's going to be hard to implement, and it's also the reason we have > three different tree algorithms so that you can pick the one that > works best for your application. If you want to implement an > algorithm with caching, you could always inherit one of the backends > that we provide. > > > - I think, the data store should primarily provide a function like > > fetchDataForNode( $node ) instead of fetchDataById( $id ). And > > developers should be aware that - depending on the data store - > > fetchDataById() has to do > > > > $node = $tree->getNodeById( $id ); > > return $this->fetchDataForNode( $node ); > > > > Imagine a situation where the data store needs additional > > information, e.g. the database table where the node data is stored > > depends on the "content class" of the node data. Information about > > the content class and the id in the content class could be saved in > > the tree. The data store could uses such information to choose the > > appropriate database table. > > This might mean that you'd want to override the ezcTreeNode class as > well, which is something I didn't think off - it sounds like a good > idea so I think I'll change to it like this. > > > I think, those methods are nice. And I can't see any reason not to > > provide them. > > Thanks for your comments! > > Derick -- Components mailing list [email protected] http://lists.ez.no/mailman/listinfo/components
