On Tuesday 24 July 2007 08:34, Derick Rethans wrote: > 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? Yeah, I get that. The question is really: do we want to provide the framework for the datastores that we have now? When having a second look I don't really see any way the current design limits its use so we can probably just keep it.
> > - 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. Ah, a nice use for the state pattern. > > - 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. Yeah, I would have done it the same way. See my original comment about hooks. > > - 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. ok. > > - 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? - last accessed - last updated - creator/owner - etc. Hmm.. this leads back to the meta-data question as you don't always want the above. > > - 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. Yeah, that was what I was thinking of. Cheers, Frederik -- Components mailing list [email protected] http://lists.ez.no/mailman/listinfo/components
