Triggered NSObjectController
Triggered NSObjectController
- Subject: Triggered NSObjectController
- From: Vincent Coetzee <email@hidden>
- Date: Tue, 31 Jan 2006 21:43:55 +0200
Dear List,
I have been using Bindings and CoreData for a while now, and the
similarity between Bindings and something that Visualworks Smalltalk
had called AspectAdaptors is striking. The one place though, where I
find something missing from bindings is when one is attempting to
edit a pre-existing object in CoreData, and then before any editing
is committed to the store, one has a requirement to update some other
object also in CoreData. In this case it becomes difficult to
separate out the changes made by the editing from some other changes
that were perhaps made against the current ManagedObjectContext.
VisualWorks had a lovely solution to this problem, called a
TriggeredAspectAdaptor, where in effect the changes made via
bindings, were held isolated from the currently active context until
a boolean value went true, at which point, the changes held by the
triggered binding were propagated to the current context. This
allowed the current context to be committed or rolled back without
affecting the editing. I also find it complicated to have to add a
ManagedObject to the store just so that I can edit and then if the
user clicks "Cancel" have to explicitly delete it, rather than just
throwing the reference away. Yes this is simple in the case where a
one dimensional object is being edited, but when the new object
contains a multitude of other objects, it becomes messy.
Does anyone have an idea of how one could possibly implement
something like this, or does such functionality already exist. I have
tried to implement a subclass of NSObjectController that handles
triggering, but unfortunately it gets complicated when one used
keypaths in the bindings, since the ObjectController does not get
asked for the complete keypath, but only a portion of it, which means
one has to wrap each successive layer in something to manage the
triggering.
Comments would be interesting ?
Vincent
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden