Thanks again Keary. On 12 ביול 2012, at 02:54, Keary Suska wrote:
> On Jul 11, 2012, at 2:45 PM, Motti Shneor wrote: >> Of what I read from everyone, and after examining the suggested code from >> Jens Alfke, I think I'm inclined to something simpler, hinted by Keary >> Suska. Could you spare a few more words on the "undefinedKey" override? > > I would create a base class that implements -valueForUndefinedKey: and > -setValue:forUndefinedKey: (per the doc links that another poster provided). > These methods would simply get/set from the dictionary. The only thing that > requires a little consideration is how you may choose to validate the key (if > at all)--i.e. determine whether you want to throw an exception for unknown > keys. You can throw by simply calling super's implementation. To validate you > could keep an array of valid key names (somewhat fragile, as you need to keep > it updated), or use runtime inspection functions (see: > https://developer.apple.com/library/ios/#documentation/Cocoa/Conceptual/ObjCRuntimeGuide/Articles/ocrtPropertyIntrospection.html#//apple_ref/doc/uid/TP40008048-CH101-SW24). > More cryptic but not fragile. > Thanks, I think this is exactly what I was looking for. In my case it is almost trivial. These classes maintain dictionaries to convert from the class' Keys (properties) to the base-model (CoreData) attribute names in the schema. I can simply look up the internal key, and throw (via super implementation of valueForUndefinedKey/setValue:forUndefinedKey) if I can't find it. If I'm going this route, do I still need to use the @dynamic for my properties? after all --- promised implementations wont be available in runtime. I rely on a KVO pre-exception mechanism. >> Obviously, I would use CoreData if I could. In fact, we use CoreData for the >> base model of our application. However, there is another "layer" higher than >> the CoreData model, that consists of intermediate data objects that serve as >> mediators between server messages and our "real" model objects in CoreData. >> The "Keys" or property-names are dictated by server definitions, and do not >> fully match those we have in our CoreData model. >> >> We don't want these objects to be stored, and we don't want them to be >> dependent on some managedObjectContext (for threading reasons). Just simple, >> old-style, model objects. > > I actually have a large project that uses pars of Core Data without an > NSManagedObjectContext, as I have to use a specific RDBMS back-end. In fact, > the context isn't needed unless you want storage and/or synchronization > (relationship management, etc). I use a Managed Object Model to represent the > data schema so I can have introspection, and subclass NSManagedObject. I also > use the undefined-key technique for them, using the associated > NSEntityDescription for key validation. I also have a system that allows > properties to be added dynamically from SQL query results. Works like a charm. Can I come work with you? :) I like it. Sounds like a healthy little system... Do you use the graphic tool for defining the Managed Object Model, or do you do this programmatically? If I choose this way, I'd like still to be able to auto-generate the classes from the schema. Our "cross-platform guys" would not rest until they see a concrete source file declaring a C++ style class with their own eyes. Also, when you have a "partial-use" of CoreData (a NSManagedObject subclass that lives without a context) How do you instantiate it? via alloc init? CoreData API demands a context... + (id)insertNewObjectForEntityForName:(NSString *)entityName inManagedObjectContext:(NSManagedObjectContext *)context; >> I'd like to avoid dynamic auto-generation of methods at runtime. I can't see >> why this is needed --- ALL my getters and setters will look exactly the same. > > As was mentioned, you at least have to specify @dynamic, which really only > promises the compiler that valid getter/setters will be available at runtime. This is alright with me. @dynamic we'll write :) > >> The reason we insist on dot-notation for accessing these objects, is that >> the code which does this, is written in C++ or C style, using structs and >> dot notation. That code could compile with no change against C++ data >> objects (in Windows) or against my Propery-based data objects for Mac. > > This is all fine--just means that you have to create the classes and declare > the properties to make the compiler happy. We do it anyway today.... There will be no change to the header files. I only wish to delete current implementation, in favor of compact, generic code in a super class. > > HTH, This HELPS indeed. Thanks. Motti Shneor --------------------------------------------------------- Ceterum censeo Microsoftinem delendam esse _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
