Re: ChangeNotification framework and Custom EO layout

On Apr 14, 2005, at 1:04 PM, YL wrote:

> Forgive me asking questions that may not so fit to this mailing list.
>
> I found no help for quite long, of the challenges encountered.
>
> David Neumann's ChangeNotification framework worked very well for most 
> of apps untill i changed
> my EO layout (indention shows the super-sub class relationship) below:
>
> EOGenericRecord (from EOF)
>      EObject                              // Shared 
> logic/mechanism/utility/service for all my EO's)
>            ModeledCustomRecord  // EOModeler generated class, for 
> entity Person, the class is _Person.
>                 MyCustomRecord     // For entity Person, the class is 
> Person (subclass of _Person)
>
>> From development view point, EObject reduces lots duplicate efforts 
>> and make the code much easier to
> manage. I still use WO4.5.1 ObjC so that without java reflection, 
> EObject knows the type of my
> MyCustomRecords class and instances and do the right things as I 
> expected. I'm using EObject to make
> the class evolution mechanism working.
>     The seperation between ModeledCustomRecord  and MyCustomRecord 
> makes model updates more
> easier from developers' view point.
>
> But ChangeNotification framework not work with the EO layout above. 
> Could someone please give me
> some hints so that I can get things fixed? Thanks for your time read 
> this email.

   I don't remember the details of how the ChangeNotification framework 
works, but if you invalidate using an EOGlobalID, your object hierarchy 
shouldn't matter.

  What we do instead of the ChangeNotification framework is we use 
something called "spread" to allow broadcasting global IDs using 
NSArchiving between our many (30?) application instances. A thread 
listens to the spread broadcasts and stores them in a queue, which each 
app instance sucks dry about once every 5 minutes and invalidates.

  (This is all in WO 4.5).

  BTW, ObjC has a certain amount of reflection. It just that the methods 
haven't be collected into an API, but they're there. In EOF where you 
can also query the model about the entities as well which goes beyond 
Java.

  Pierce