Hi, I looked through the design doc and the current experimental code and I have the following questions/comments:
- I'm not convinced that it is a good idea to have datastores and fetching of real data from the nodes etc. at all. Isn't it better to let this be application specific. You can then implement datastores that are specific to your trees which means that you get rid of the "mixed" return value from the data property. - how exactly do you return a subtree, depth first, breadth first, etc..? - it would be nice to be able to join data with nodes (for db backends) in queries so you can filter/sort on data information as well as node information. I know this breaks the encapsulation between nodes and data, but it might be useful. I guess this must be implemented as special implementations of the tree/backends, so you could say that it is supported already. What would be cool though if is the standard implementations allows for easy re-implementations of methods to allow this. - optionally it would be nice to be able to have the node data and the real data together to save queries. - ezcTree::fetchById now fetches the node data, this should be delayed until actually used. - what about implementing hooks when saving/updating/deleting so you could set metadata on the nodes (that come from the data objects) which can be used for filtering later. - what data will the nodes provide by default? (e.g stored date etc.) - db-schemas for the db-implementations would be nice in the design doc. - should we provide a tree storage class (singleton) for easy fetching of a tree? - I'm missing a bit more detail in the design doc that displays the main functionality of each of the classes - I'm also missing a few examples of typical usage in the design doc. Rename suggestion for clarity: ezcTree::fetchById --> ezcTree::fetchNodeById This line is probably a bug :) in ezcTree if ( 'ezcMail' !== $propertyValue && !$handlerClass->isSubclassOf( $parentClass ) ) On Thursday 19 July 2007 16:48, Derick Rethans wrote: > Do you think those convenience methods are useful? Yeah, don't see any reason not to have them. Cheers, Frederik -- Components mailing list [email protected] http://lists.ez.no/mailman/listinfo/components
