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
>

Reply via email to