[Rubycocoa-talk] Totally stuck with Core Data on Leopard

[<jac...@gm...>]

Summary of post: I can't get ruby subclasses of NSMangedObject to work =20=

if they have their own attribute implementations with RubyCocoa on =20
Leopard. I desperately need this to work, have anybody solved this =20
problem?
---

I'm having major problems with porting my application to Leopard. The =20=

problem is that my application relies on ruby subclasses of =20
NSManagedObject which contains methods implementing the core data =20
attributes. The default attribute implementation provided by Core Data =20=

is not enough since changes in an attribute can trigger changes in =20
other attributes etc. Since I have a UI that uses bindings, a lot of =20
the access to my entities is happening from Obj-C and I need these =20
calls to go through the ruby methods of my entities.

I got this working quite well with RC 0.12.0 on Tiger. By overriding =20
setValue:forKey: and having it check for a ruby set-method before =20
passing the call on to the setValue:forKey: method in NSManagedObject =20=

I could get all access from Obj-C to the attributes to pass trough the =20=

ruby methods which was what I wanted. I also used KVO-observing to get =20=

notified of changes in certain attributes.

My problem is that this no longer works on Leopard. It seems that a =20
lot of changes have been made to Core Data in Leopard. The change that =20=

is causing the most trouble for me is (from the release notes):

"On Mac OS X v10.5, Core Data will dynamically generate public and =20
primitive get and set attribute accessor methods and relationship =20
accessor methods for managed object classes."

That means that Core Data no longer uses setValue:forKey: to set an =20
attribute but instead directly checks if there exists an Obj-C =20
implementation. If not, the default Core Data attribute implementation =20=

is used. This means that all changes through the GUI which uses =20
bindings will not go through my ruby classes.

I have tried a lot of ways to solve this problems:

* Providing primitiveXx/xx methods in the ruby class. They are not =20
seen by core data (as the corresponding methods in Obj-C would).
* Using KVO-observing to observe changes in the relevant attributes. =20
This works with the exception that the application becomes unstable. I =20=

have spent a lot of time trying to track down the source of the =20
instability but failed. Both 0.12.0 and the trunk have this problem on =20=

Leopard (but the same code works on Tiger). While googling for help, I =20=

have found advice from Cocoa gurus that 1) it's really difficult to =20
get KVO to work correctly with Core Data and 2) KVO should only be =20
used to keep your UI up to date, not to handle dependencies within =20
your application.
* Providing setXx/xx methods in a Obj-C superclass to my entity that =20
forwards the call to ruby methods (rbXx=3D/rbXx) in a ruby subclass. =20
This doesn't work, simply adding an empty ruby subclass to an Obj-C =20
subclass of NSMangedObject causes the enitty to fail creation of new =20
objects.
* ... I've also tried a lot of other weird hacks that I barely can =20
remember know....

I would really appreciate any advice on how to move forward on this =20
issue. Unless I find a solution really soon, I will have to rewrite =20
all my NSManagedObject subclasses in Objective-C.

Best regards,
Jacob Wallstr=F6m