[Zope3-Users] Design question (object or interface for category implementation?)

[Christophe Combelles]

Hi,

I'm playing again with the notion of categories of objects.

I have two main goals:
---------------------
1) I must let the user choose the category of an object added to the zodb. For 
this, I must be able to retrieve the list of categories and present them in a 
form field managed by a vocabulary (or in a different manner).
2) I must have different behaviours for categorized objects:
objects of different categories would have different views, different 
addMenuItems (if they are containers), etc.

the first requirement would tell me to define categories as objects, while the 
second one would tell me to define them as interfaces.

The possible solutions I see:
----------------------------

1) The simplest solution is to store the categories as text strings into the 
annotations of the object. So categories actually are just tags.

2) The second solution is to do the same, but replace text strings with category 
objects, that implement ICategory. And categories can be stored separately in a 
category container, or in a registered utility that gives the list of available 
categories. This is a bit better, but this way I don't know how to easily let my 
categorized objects behave differently according to their categories.

3) The third solution is to define categories as interfaces extending ICategory. 
I can retrieve the list of categories with ICategory.dependents
But to present them in a form, I must have a pretty name for each interface. 
Should I store them in a Tagged Value?

4) The fourth solution I see, is to define an interface type, ICategoryType, 
extending IInterface just like IContentType. Then my categories would be 
interfaces whose type is ICategoryType. But with IContentType, is there a way to 
retrieve the list of all available content types?


Do you have some advice on the subject?  Am I asking the wrong questions? Is 
there an obvious solution I've not seen? Am I going too far and should I rather 
keep it simple and stupid?


regards,
Christophe