[Zope] ObjectManager example needed

[J Cameron Cooper]

I'm also adding the list.

Andre Meyer wrote:

>Hi JCC
>
>Thanks again for your help. I will certainly look into BTrees and
>ZCatalog. The Folder/SimpleItem solution works well so far, but is not
>scalable.
>  
>
Performance in an engineering concern. If you already have something 
that works, I say use it until it breaks. Mock up a database of the size 
you expect and see if it sucks. If so, use a more efficient method, like 
ZCatalog. If not, hey, great!

>The other thing that I was not explaining clearly is this (I try again):
>when I have an object with a reference to another object (of different
>classes, typically) that reference is the id of the other referenced
>object. In Java, for example, such a reference is a direct pointer to
>the other object. That is possible in Python but is not the case in
>Zope. With only the id of the referenced object that object needs to be
>looked up in the folder structure. Example: I have an object of class
>PieceOfMusic that references an object of class Composer. In the ZPT
>page where I list the pieces of music I want to include the names of
>composers. These need to be looked up in the referenced Composer
>objects. However, in ZPT I cannot use the following:
>
>...
><span tal:repeat="piece here/listPieces">
>  <tr>
>    <td><input type="checkbox" name="PieceIDs:list" value="id"
>tal:attributes="value piece/id"/></td>
>    <td><a href="." tal:attributes="href piece/id"
>tal:content="piece/title">Title</a></td>
>    <td><a href="." tal:attributes="href piece/composer"
>tal:content="piece/composer/title">Composer</a></td>
>  </tr>
></span>
>
>The problem is that piece/composer is an id and piece/composer/title
>does not refer to the Composer object's title! How else can I reach the
>composer's attributes?
>  
>
Your statement is correct. The 'composer' attribute is a string, and the 
second statement is asking that string for the title of the object it's 
supposed to refer to. Obviously this doesn't work. You need to use the 
value of the 'composer' attribute to look up the proper object and then 
ask that for its 'title' attribute. You may be able to do this in TAL like::

  # provided that Composers are stored in a folder 'composers' in the 
acquisition path...
  here/composers/$composerid/title

I think this works, but you'd have to bind 'pieces/composer' to 
'composerid'. But you could try::

  here/composers/${pieces/composer}/title

on the possibility that it works. I know exactly how in Python, though::

  context.composers[pieces.composer].title
  #(or any number of other lookup methods, like getattr.)

You could also use a reference product to do this for you.

You can get programmatic references to objects in Zope, but the problem 
is that the web form only gives you the string. You may do something like::

  self.composer = self.composers[REQUEST.composers]
  #self.composer.title is now valid

The same lookup procedure is required in Java, though the methods are 
different.

             --jcc

>thanks a lot and best wishes
>Andre
>
>
>On Tue, 2003-11-25 at 21:57, J Cameron Cooper wrote:
>  
>
>>Andre Meyer wrote:
>>    
>>
>>>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)