[Grok-dev] Re: zope.app.keyreference.interfaces.NotYet(object)

[Philipp von Weitershausen]

On 16 Jul 2007, at 09:27 , Sebastian Ware wrote:
> So the behaviour of grok.Application is different from that of  
> grok.Container with respect to when the catalog(?) that holds the  
> content is created.

Well, yes, but you don't seem to get the point: grok.Application is  
created *before* any catalog is ever created. Catalogs live in  
grok.Application instances. That's why the behaviour is differs  
between grok.Application objects and pretty much all objects that are  
created after it, including grok.Container objects.

> This is a bit confusing to me, even though I am sure there is a  
> technical explanation I would have preferred that they worked in  
> the same way.

I've given you the technical explanation below and now again above.  
The problem is a bootstrap one.

By the way, the problem won't occur if you actually added a "decent"  
object to the container. This is what your original failing example  
looked like::

   class ProtonContainer(grok.Container, protonobject.ProtonObject):
       def __init__(self, creator_id, object_type, title, body,  
authors):
           ...
           self['files'] = 'how are you?'

Here you're adding a string as a subobject of the container. If you  
had added an actual grok.Model instance, it would work. The reason is  
that grok.Model objects have a __parent__ pointer, therefore not  
causing a NotYet error.


> 15 jul 2007 kl. 22.59 skrev Philipp von Weitershausen:
>
>> Sebastian Ware wrote:
>>> What surprised me was that that kind of assignment worked with my  
>>> grok.Application object...
>>> class ProtonCMS(grok.Application, grok.Container):
>>>     interface.implements(interfaces.IProtonCMS)
>>>     def __init__(self):
>>>         super(ProtonCMS, self).__init__()
>>>         self.title = ''
>>>         self.description = ''
>>>         self['default'] = protonworkflow.ProtonWorkflow()
>>> ...and I was expecting the "class ProtonContainer(grok.Container,  
>>> protonobject.ProtonObject)" to work in the same way.
>>> Do you know why I can make the assignment in the grok.Application  
>>> object but not in the grok.Container object?
>>
>> Yup. Because the catalog (which keeps the indexes for your  
>> objects) is created whenever a grok.Application object is created.  
>> Actually, it's creates slightly after the application object.  
>> That's why indexing won't happen in any application's __init__  
>> method. But it will happen upon all other modified events, and  
>> container[name] = obj happens to throw a ContainerModifiedEvent or  
>> something of that sort.
>>
>> -- 
>> http://worldcookery.com -- Professional Zope documentation and  
>> training
>