Hi Piotrek !

Well, as a first shot i went for the "easiest" solution : not having external tables. But as you could notice, the method getTree( .. ), used throughout the whole datatype's code, could be altered and use a handler-based backend loading, potentially using INI settings, to use any of the available backends / tree types in ezc Tree. Having an external table would imply reproducing, in the storage table, the versioning and translation capabilities, which are, on the other hand, brought by default when using the ezcontentobject_attribute table.

I am currently working on a related datatype, which could be called something like eZTaxonomy, giving the possibility to edit, in a central place in the back office ( Setup > Taxonomy ) a tag tree, and let the possibility, through a datatype, to pick up, when editing an object, any of the centrally defined tags. This datatype uses the persistent storage feature ( ezc Database, not PersistentObject ). I'll contribute this asap on projects.ez.no.

What would you like this feature for ?

Thanks for your feedback,

Regards,
Nicolas