On Mon, 23 Jul 2007, Frederik Holljen wrote: > 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.
Well, the idea is that the data stores are all application specific. We're just providing a few examples for this. Or did I misunderstood you here now? > - how exactly do you return a subtree, depth first, breadth first, etc..? In the current design you don't. I suggest to add a parameter to the fetchSubtree() methods for this. > - 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. I've been thinking of reducing queries by either a join with the data table (your first point) or having it in the same table (second point). I think we can make this work, but only for when pre-fetching of data is used. I see currently that we can do this by having data stores implement an interface that tells the backend that it supports a method that should be run on the query statement before it is executed. It would be up to the data store to actually fill in the correct joins then. I'll see if this works nicely. > - ezcTree::fetchById now fetches the node data, this should be delayed until > actually used. Yeah, it's a prototype ;-) It should only delay it though if pre-fetch is not enabled. > - 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.) For now only the id (and data that is required to maintain the structure). store-date is a good idea as well, but I can't think of other generic things to store with the nodes. Can you? > - db-schemas for the db-implementations would be nice in the design doc. Yes, I will add those for the few example backends/data stores that we have. > - should we provide a tree storage class (singleton) for easy fetching of a > tree? I think we should, in the same way that database does it with multiple "instances" though. > - I'm missing a bit more detail in the design doc that displays the main > functionality of each of the classes Okay, I'll try to add that. > - I'm also missing a few examples of typical usage in the design doc. Okay, I'll add that. > > Rename suggestion for clarity: > ezcTree::fetchById --> ezcTree::fetchNodeById Yes, good point - I will fix that. > This line is probably a bug :) in ezcTree > if ( 'ezcMail' !== $propertyValue && !$handlerClass->isSubclassOf( > $parentClass ) ) Fixed :-) regards, Derick -- Components mailing list [email protected] http://lists.ez.no/mailman/listinfo/components
