[Zope] ObjectManager example needed

[J Cameron Cooper]

Andre Meyer wrote:

>...
>
>The approach described by Dylan seems appropriate, but it is clearly a
>problem to have double references. That leads inevitably to inconsistency.
>Therefore, I will try the approach using Folders and SimpleItems, where
>different Folders are created for different kinds of SimpleItems (classes).
>All references will be one-way only.
>
>For now, I have added SimpleItems of different classes in the same Folder
>and used the class as selection criterion for building lists. This works
>very well for small amounts of items. Will it work well with many items?
>Will I have to use BTreeFolder (still need to have a look at its API)?
>  
>
BTreeFolder should be a direct drop-in replacement for Folder. The 
get-by-meta_type function in Folder will probably degrade as your 
contents increase, but I don't know on what order, or if BTreeFolder 
would do better. If you're going to have a stupendous amount of objects, 
then ZCatalog is the way to go.

>Another issue at the moment is the referencing: I made a zpt page with a
>html selection form field where the values are the ids and the names are the
>titles of SimpleItems (composers in my case). This way, I can select any of
>the previously added composers and store its id in the PieceOfMusic object.
>The tricky part is how to retrieve the composer within a zpt page: using
>here/piece/composer/title in a tal:repeat does not work! How should this be
>handled?
>  
>
That's to broad of a problem to answer without a lot of supposition, and 
my mind-reading skills seem to be failing on this one. You'll have to be 
a little more specific on your structure and goal (and code).

          --jcc

-- 
"Code generators follow the 80/20 rule. They solve most of the problems, but not all of the problems. There are always features and edge cases that will need hand-coding. Even if code generation could build 100 percent of the application, there will still be an endless supply of boring meetings about feature design."
(http://www.devx.com/java/editorial/15511)