Hi,

> Hello,
>
> 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.

- 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?

- 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.)

- 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.

> I've also a question already. In the design I mention in the
> "ezcTreeNode" section:
>
>   Operations can be done on tree nodes as well, such as checking
> whether it has children, fetching a sub tree. Those methods will call
> corresponding methods on the tree object to actually perform the
> check/action.
>
> In the tests you see this as well, here the example by calling it on
> the node:
>
>   $node = $tree->fetchById( 1 )
>   $node->getChildCount();
>
>   the node's getChildCount() looks like:
>   return $this->tree->getChildCount( $this->id );
>
> vs calling it on the tree (with the node ID being the parameter):
>
>   $tree->getChildCount( 1 );
>
> Do you think those convenience methods are useful?

I think, those methods are nice. And I can't see any reason not to 
provide them.

Have a nice day

Thomas

>
> [1] http://article.gmane.org/gmane.comp.web.ezcomponents.cvs/5139
> [2] http://article.gmane.org/gmane.comp.web.ezcomponents.cvs/5140
>
> regards,
> Derick
>
>
> --
> Derick Rethans
> eZ components Product Manager
> eZ systems | http://ez.no
-- 
Components mailing list
[email protected]
http://lists.ez.no/mailman/listinfo/components

Reply via email to