[dev] Re: [cvs] commit: horde/lib Tree.php

Marko Djukic marko at oblo.com
Mon Feb 24 02:18:25 PST 2003


Quoting Chuck Hagenbuch <chuck at horde.org>:

> I'm not tied to the format, but I *do* want a consistent API here. It makes
> no sense to have both CategoryTree and Tree.
i do agree...

> I'd prefer that the new Tree class extend CategoryTree - CategoryTree_dom
The only thing that is slightly confusing is that Tree as it is, is not tied
strictly to Category.php, to imply it is related by naming it CategoryTree. It
can take any array and dump a tree out of it.
I see it is more logical having a generic Tree base and then extending it with
horde_categories specific Tree class.

> it should either use CATEGORY_FORMAT_3D, or you should add a new categories
> export format that it can work with.
i don't particularly like CATEGORY_FORMAT_3D, it requires building many more
arrays to add extra information, i haven't figured out an easy way to add on
nodes once it has been generated, and it involves an extra step converting to
this 3D format, when just the regular CATEGORY_FORMAT_FLAT does quite well as
the basis for a tree.

as for adding another format i don't think it's necessary, again
CATEGORY_FORMAT_FLAT does well, and all that could be added is a function within
Tree to auto-parse by default a CATEGORY_FORMAT_FLAT type array, rather than
relying on addNode being called. This could be used if for example a "default"
type tree is being generated without the need for individual node customisation.

m.


More information about the dev mailing list