Hi Delio,
no...@ti... wrote:
> Hello all,
>=20
> looking at the code for globalID() in CustomObject I see that a new EC is=
created on the fly and a globalID for self is looked up in it, question is=
(and I'm probably too asleep) how does an newly created EC know about
> a globalID of an object fetched in another EC? I would have thought some =
sort of call back in the parentObjectStore but I can't see it in the code. =
Enlight me please :)
>=20
> ciao
You were probably too asleep ;)
CustomObject.globalID() does NOT create any EC, but
1. asks self for its EC,
2. asks that ec for the object's gid
And since you're curious, here are some more: the EC stored in the
CustomObject is in fact a weakref to the real EC --that's why it is
initialized as a void lambda func BTW. That weak reference is initialized =
by
the EC when the object is registered (either newly inserted or fetched from
the db), look at EC.recordObject() if you want to see the code!
-- S=E9bastien.
PS: oh, BTW, you'll probably also note the double underscore in
'CustomObject.__editingContext'... and the ugly line:
anObject._CustomObject__editingContext=3Dweakref.ref(self)
=20=20=20=20
within EC.recordObject()
=20=20=20=20
This comes from a time when I thought some fields should not be exposed
(at least --since this is python:)-- not easily changed from the outsid=
e),
so I choose to use the private name mangling for some variables.
There are some examples of this in the framework alas, I think I'll cha=
nge
them at some point: I now tend to think that this is not very pythonic,
and that a single underscore and good documentation should be sufficient
(or, at least, use a private method _setEC() instead of that explicit n=
ame
mangling stuff in another class, isn't that supposed to be private after
all ?-/).
|
