Re: Triggering change notifications when modifying custom object ivars in core data app
Re: Triggering change notifications when modifying custom object ivars in core data app
- Subject: Re: Triggering change notifications when modifying custom object ivars in core data app
- From: Rick Hoge <email@hidden>
- Date: Thu, 28 May 2009 14:59:58 -0400
Ben, Quincey, Sean, thanks for the comments. Maybe there are some
lower level design issues to rethink.
This pattern is usually a flawed model design. If the properties
are to be this independently mutable, then there should be a
relationship, and/or the complex attribute should be decomposed into
several attributes. This is, after all, a gross violation of
encapsulation.
Issuing calls to will/didChange manually won't help since the
property didn't change. will/didChange calls need to bracket the
actual change. In theory, you could add a transient "generation
count", and have every client who hacks on the mutable dictionary
out from underneath your managed object increment it.
Hard to see what that buys you over, say, writing proper setters and
getters for the sub-properties stored in the dictionary, and stop
clients mutating the dictionary directly. Restore clean
encapsulation.
The core data app I'm working on manages a database of images, and is
also supposed to allow construction of a sequence of image processing
operations. A processing operation is implemented as an instance of
an 'operation' class (loaded as plugins which must be shared with non-
core-data apps), which has a dictionary of input parameters and output
values (similar to an Image Unit). In general, the core data app does
not know what kind of input parameters will be supported by the
'operation' objects it has to represent, although these are always
contained in a mutable dictionary. This means that the core data app
can't really provide getters and setters because the actual parameter
names (dictionary keys) are not known until run time.
In the core data app, I am creating an entity to represent an
operation, with the actual operation object as a custom attribute (as
per the docs). The user can change the input parameters in the
object's dictionary of inputs, and this should be reflected in the
persistent store of corresponding to the custom attribute on disk. I
realize this is ugly, but I can't think of any other way to do it
given that the available operation classes are loaded as plugins at
run time.
It is almost working, but I need a way to tell the persistent store
coordinator to re-archive the custom attribute even though only the
contents and not the actual object have changed.
One thing I could do, I suppose, is to add a set of parameter entities
as a to-many relationship of the operation entity. This could be
populated when the operation object is 'loaded' (added to the
sequence), and the user would edit the parameter entities. Just
before the operation object is to be run, I could update its 'inputs'
dictionary based on the core data entities. This creates other
difficulties however (for example the operation objects can manage a
user interface view used to visualize the configuration settings).
It would be nice if undo/redo worked, although for this small
component of the application it would not be the end of the world if
it didn't.
Again, if anyone has ideas on how to approach this design I'd be very
grateful.
Rick
_______________________________________________
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