Re: RFC Nested Set manipulation class

oha.... interesting stuff here :-) i think Daniels class has some really nice features which would be needed in Tree. But since i think that Tree should be moved into Structure::Tree or something (which was already mentioned a couple times) it might be the time to rewrite things a bit. The major problem here that i can see, is that obviously noone has enough time to do that :-) me neither. I could imagine Daniel's class in DB_NestedSet, since it only focused on DB (am i right Daniel?). And the focus is also a tiny bit different, since it works on DB-data, while I am actually planning for the Tree (or Structure::Tree) to make the data interchangeable (which partly works already). I mean to say, that you can read a tree from an XML-file and save it in a DB, or vice versa and etc. Even though I could imagine (for the good of PEAR) that classes that work on Trees or NestedSets, which is a way of saving a tree should have alike API's so people dont have to learn different stuff when switching. And Daniel's class could be the class you want to go with when people know that they *only* want to work on a DB, as opposed to using Tree when you want the above described features .... whatever ... :-) regards Wolfram PS: thanks to everybody Daniel Khan wrote:

Lorenzo Alberton wrote:

I think that your class would give a great contribution to Wolfram's Tree class. I had a look at it some weeks ago, and I think that the two classes could be merged.

[..]

If you (Daniel and Wolfram) agree on this, and find some time to review it, I could help as well in the new design. Some small improvements could be done in the drivers too. Since Wolfram is an extremely pleasant person to talk with, I think an agreement could be reached without much effort, if you are willing (and have the time) to work on it.

I am also thinking that both packages could benefit from eachother. As I meantioned in another thread I unfortunately haven't the time to do a full merge and to maintain it. Especially as the existing NestedSet is used in some complex applications. So even if a merge is done I couldn't use it for my applications cause I would have to break much of the existing code of projects using it. Tree has an existing interface which is used by other classes too so I would never be able to make it return things in a way my apps expect it. I am only able to maintain and work on the package if I am able to use it for my company. It isn't the case that I don't want to contribute more - I really simply don't have the time (I'm behind with some projects) so I take the way of trying to contribute things that I have allready in use :) If someone takes the code, merges it into Tree and maintains it it's really no problem. But I think that's not the point as I am sure that Wolfram _knows_ how to implement the missing features without having to look at my code :))

Otherwise, if no one has the time to work on the merge, a simple interface could be enough, even if my personal preference goes to the "one-class" solution :-)

That wouldn't be a problem. Yes. Even if I get 100 tinmes +1 I really want to hear what Wolfram thinks. (He's not arround tonight I think) I also think that there should be found a way to integrate/interface with Tree.

-- Wolfram ... opensource @ vision:produktion ... http://opensource.visionp.de ... translating template engine .... http://sf.net/projects/simpletpl ... authentication system .... http://sf.net/projects/auth