Re: [Modeling-users] CustomObject.globalID() problem

[Sebastien B. <sbi...@us...>]

        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 ?-/).