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
> - 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_list_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
--
Derick Rethans
eZ components Product Manager
eZ systems | http://ez.no
--
Components mailing list
[email protected]
http://lists.ez.no/mailman/listinfo/components
