Just wanted to chime in on this, and say that I would LOVE to have this as part of the framework. I was just about to start on my own implementation of this, which I'm sure would not compare to the one that would be standardized into the framework.
Colin Ross wrote: > > I personally would like to say I would help with the component. > The horde one is way too specific and specialized (for mainly html/ui > output) > Also, i think that some of the other components (already) with zf would > benefit from having one unified API for dealing with Nested Sets (or Trees > if you will) within the framework. > > Looking at the Sep 24th email from andreas, < > http://framework.zend.com/wiki/display/ZFMLGEN/mail/5137 > > I think his idea fits well into the purpose of the frameowrk. To create > reusable components, not drop in functionality. > > A managable way to create, manipulate, and save a nested set is very > reusable, especially if it is done in such a way that the inputs and > outpus > (persistance) is abstracted out (ie. a db, xml file, etc). With this kind > of > utility, you could even go so far as saying it would be possible to mix > persistancy models. Like a tree built from a database query, with has an > xml > structure injected into it. Better yet, as long as your implimentation > deal > with the provided API, all such pluggable persistancies would be available > for use. > > If we could just create a component that dealt with the managment of the > nested set and also allowed plug-in -style persistance that would make > alot > of the component we are currently working on much easier, IMHO. > > If we had a unified class for dealing with NestedSets, i think it would > only > ease the development burden of other related components like the ACL > package, I8N, (perhaps a VFS [virual file system] etc, etc) > > Whether or not the actual implimentation of such a component would mearly > be > a wrapper around php's own built in DOM functionality (which also, if you > think about it, is a nested set [the dom]) or built from scratch (or a > wrapper around SPL's recursiveIterator, [although in this case i would say > a > nestedset is NOT inheriently Iteratable]) > > I think this component deserves at least a 'laboratory' status to see how > things might pan out. > > > As a sidepoint, since when was 'originality' a requirement for a Zend > Component? Half the packages in the Library have been done before. To > quote > the Framework's roadmap: "Zend Framework aims to provide an architecture > for > developing entire applications with no other library dependencies. " > > $0.02 > > Colin Ross > >> Hi Eugene, >> >> There was a proposal for Zend_Tree that was rejected. You can read about >> it here... >> >> http://www.zend.com/lists/fw-general/200604/msg00096.html >> >> ...and the reason for its rejection... >> >> -------------------------------------------- >> >> Reviewed by Zend team on Thursday, 20 Apr 2006. >> Decision: Rejected >> >> At this time, we see this as a general-purpose class >> that would be useful but doesn't fit into our core. >> >> There is a PEAR package, Tree, with very similar goals. >> However, it hasn't been updated since 2003. See: >> http://pear.php.net/package/Tree >> >> There is also an actively supported tree class as part of >> the Horde framework, see: >> http://dev.horde.org/api/framework/Horde_Tree/Horde_Tree.html >> >> We'd suggest contacting these developers to see if you can >> contribute your ideas to further their efforts. >> >> ------------------------------------------- >> >> Nick >> > > -- View this message in context: http://www.nabble.com/Need-for-dealing-with-nested-sets-%28Re%3A-Nested-Sets-algo%29-tf2414365s16154.html#a6744984 Sent from the Zend Framework mailing list archive at Nabble.com.
