Derick Rethans wrote: > Hello! > > During our conference the development team discussed the requirements of > the HierarchObject and decided that we'd like to have something like > this. We also discussed the name, and we think that Tree is more > welcome. With our discussions in mind, I took the liberty of creating a > new requirements document out of the original one by Thomas. You can > read it below. Comments are appreciated: > > > > eZ Component: Tree, Requirements > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > :Author: Derick Rethans (Based on draft by Thomas Koch) > :Revision: $Revision: 5688 $ > :Date: $Date: 2007-07-04 16:28:50 +0200 (Wed, 04 Jul 2007) $ > > Introduction > ============ > > Description > ----------- > > The Tree component handles the creating, manipulating and querying of tree > structures. The component supports different storage algorithms for optimal > application specific performance. > > Use Cases > --------- > > * ACL as PHPGACL: http://phpgacl.sourceforge.net > * Holding a file directory > * Content structure for CMS
CMS content structure seems like the best application for Tree. But does it need to handle content versioning then? Or would that be another component? > Requirements > ============ > > The component should handle the representation of tree structures in > database tables. There are different algorithms for representing tree > structures in a relational model and they can all be the fastest for a > specific application. Therefore we need to implement a backend mechanism > with multiple backends for each specific optimized algorithm. > > Besides the database backends there could be other places on where to > store tree structures - for example simply on the file system or in an > XML file. The backend mechanism should support this as well. Might as well mention PHP arrays here, for small trees? > > Design goals > ============ > > It's desirable to have an OO API to handle the nodes like the DOM > extension, e.g. Node->appendChild(). On the other hand it's an advantage > not be obliged to extend an abstract node class when working with the > content of the leaves. Do you mean that the content is a node in the tree? Or that the node contains the content as a property? > Format > ====== > > The following algorithms should be supported: > Would it be possible to convert between different algorithms back-and-forth? Some algorithms might be more appropiate (speed-wise) for some tasks while others would be not, so the conversion could be useful in this case to port the data to other algorithms. -- Alexandru Stanoi eZ Components System Developer eZ Systems | http://ez.no -- Components mailing list [email protected] http://lists.ez.no/mailman/listinfo/components
