Its not that there isn't a solution available as much as the solutions that ARE available are too specific and specialized, i.e. geared towards using a database to display breadcrumbs or output a website's hierarchy in a nested unordered list.
c
On 10/10/06, dandean <
[EMAIL PROTECTED]> wrote:
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.
