Re: How to implement an object whose properties are really dictionary entries.
Re: How to implement an object whose properties are really dictionary entries.
- Subject: Re: How to implement an object whose properties are really dictionary entries.
- From: Motti Shneor <email@hidden>
- Date: Thu, 12 Jul 2012 10:14:33 +0300
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 (email@hidden)
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:
This email sent to email@hidden