[Zope-dev] Folderish or SimpleItem object types for structural content

[Martijn Jacobs]

Hello Dieter.

>This must be a funny classification scheme...
>  
>
Well, I wanted to have the discussion to be general about this thing 
because I can imagine that this issue has been some point of discussion 
before, among others, but I will be more specific to explain :
- The structure will have categories within categories. (hierarchical 
categories)
- Each category can have custom properties which can be 'inherited' by 
the aqcuisition feature of zope.
- Within the categories you have "object's".
- Each "object" can derive his properties through acquisition, or have 
their own properties (or override the acquisiton properties)
- Each "object" will have "item groups",  with their own properties / 
files / comments / etc.
- Each "item group" will contain  "items", each item will have 
properties, but also can have properties derived through acquisition 
from categories and objects :  so these "items" will all have different 
properties, depending in which category they exist.

With this rules I was thinking about the next structure :

Category (Object Manager, within other Categories) -> Object (Object 
Manager) -> Item Group (Object Manager) -> Item (Simple Item)

>But anyway: I have a completely different strategy for you:
>lets see whether you will like it.
>
>You do not materialize the classification scheme at all but you
>have only your leaves (let's call them "object"s).
>
>Each object has its classification as an attribute, say "category".
>A "category" thus has the form "topic/subtopic/subsubtopc/...".
>
>You index the "category" with a PathIndex (I would recommend
>my "Managable PathIndex") and use canned searches (so called "topic"s)
>the recreate the classification structure via searches (if needed).
>
>
>If you do the last step (use "topic"s for the complete recreation of the
>classification structure), then the number of objects will
>not decrease (what formerly was a classification folder is now
>a "topic"). But the new structure is much more flexible.
>You can now assign different categories (say along different
>dimensions) to your objects and will get different hierarchical (topical)
>views on your object set.
>  
>
I have been thinking about this kind of structure to use for this 
specific project. But there is a problem that occures (too) often (in my 
experience) with this approach. By doing this you really are depending 
on the ZCatalog : If some conflict errors occure or for some reason the 
objects are not indexed (correctly) or not updated, some important 
information is not available for the user. I have experienced alot of 
problems with unindexed objects, or not reindexed objects due to 
'random' conflict errors'.  By making a complete hierarchical structure 
using 'Object Managers', you can always assure that data is accessible, 
and if the ZCatalog is not up to date, only the search results will not 
represent the actual structure.

>30.000 is not yet very impressing.
>  
>
That's good to know. It's hard to say offcourse, but what is in some way 
a 'limit' of the number of objects, for instance, if they all have to be 
indexed? Indexing objects uses ALOT of CPU time for example... In which 
amount of objects should you reconsider your design? (Speaking of a 
'general' guideline)

>You should take care to use the correct folder implementation, however.
>As soon as a folder is likely to have more than a few dozen of objects,
>you should use a "BTreeFolder2" rather than a normal folder.
>  
>
I've used the BTreeFolder2 before for a single folder containing large 
number of objects, and indeed, it's really boosting the perfomance a lot...

Well thanks again for your thoughts, it helps in breaking patterns I'm 
used too,  let's reconsider it using some external input :)


Kind regards,

Martijn.


-- 
Martijn Jacobs
Four Digits, internet solutions
e-mail: martijn at fourdigits.nl | web: http://www.fourdigits.nl
tel: +31 (0)26 44 22 700 | fax: +31 (0)84 22 06 117