On Jun 1, 2010, at 2:37 AM, Joanna Carter wrote:
Richard, this really points to an "abuse" of the MVC design
pattern :-)
...
This ensures separation between the View and the Model it is meant
to be representing. Using a delegate to obtain the data required for
drawing a View means that the view has no need to know anything
about the Model, the MOC or anything else, apart from the fact that
something, somewhere, will supply the necessary information in
response to a request via the delegate methods.
...
Of course, this is a very simplistic (and not very well written)
example, but you should get the idea that any code that talks to the
MOC can be located in the Controller and accessed from the View via
a delegate.
My custom view is very complex. It has a number of helper objects
which could be considered delegates. One helper object is for visual
positioning control. This is where the actual problem resides.
This helper object needs to persist one of the visual positioning
properties to the data model and if the data model changes the
property also needs to be updated. The helper object does use an off
the shelf object controller to interface with the data model. The
object controller is in the nib and is wired up as you have suggested.
The visual property has a custom binding and the binding is wired up
in the custom view which has an outlet to the object controller. The
moc is required to disable and re-enable undo manager registration
when the binding pushes view changes to the model through the object
controller.
NSDocumentController *controller = [NSDocumentController
sharedDocumentController];
NSPersistentDocument *document = [controller currentDocument];
NSManagedObjectContext *managedObjectContext = [document
managedObjectContext];
[managedObjectContext processPendingChanges];
[[managedObjectContext undoManager] disableUndoRegistration];
// push change to model through the object controller
[managedObjectContext processPendingChanges];
[[managedObjectContext undoManager] enableUndoRegistration];
I suppose this custom binding code could be put into a custom object
controller but I have yet to observe that pattern. Many of Apple's
views have a multitude of bindings and I think the actual code that
implements the binding must be in each view's implementation file or
somewhere there about. I would be surprised to learn that this code
resides in any of the controller classes or in Interface Builder. The
view advertises it's bindings to Interface Builder using the
'exposeBinding:' method of the NSKeyValueBindingCreation Protocol.
Custom views however need not concern themselves with exposing their
bindings unless you are also making a custom IB Palette.
--Richard
_______________________________________________
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
