[Grok-dev] Re: zope.app.keyreference.interfaces.NotYet(object)
Philipp von Weitershausen
philipp at weitershausen.de
Mon Jul 16 17:00:25 EDT 2007
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
class ProtonContainer(grok.Container, protonobject.ProtonObject):
def __init__(self, creator_id, object_type, title, body,
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):
>>> 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
More information about the Grok-dev