On Jan 20, 2010, at 19:51, Chase Meadors wrote: > I have a couple of questions about the practices I'm using for bindings in my > app. > > 1. Doing work in the setter: > > Something I do alot when making models & custom views. For example, I might > have a layer subclass that exposes a binding called "concentration." I > @synthesize the property, but I override the setter to do all the work > involving calculations, modifying sublayers, colors, etc. Is this a common > practice, or is there some other way I should be doing it?
Your terminology seems incorrect. A binding is not the same thing as a property. Do you mean "property" when you say "binding"? There's nothing wrong with overriding (just) the setter to do stuff, that's what it's for. However, it's not clear whether your "layers" are user interface objects or data model objects. If this is some sort of drawing application, it would make sense for (conceptual) layers, colors, etc to be in your data model. > 2. "Work in progress" objects: > > I have a model object that exposes only an array as it's only binding. The > model manages text files and reads/modifies them in accordance to it's array > binding. Since adding an object to an array could be potentially large > process, I want to let the user "construct" an object before ever adding it > to the array. I've solved this by simply letting my controller have > possession of a "thingToAdd" object that the user can change and modify. Then > the add button will cause the controller to actually set the new array on the > model. Again, is this a common practice? You mean "property" again, instead of "binding"? It's usually helpful to think of a property like this as an *indexed* property rather than an *array* property, because the actual array is an implementation detail that you do *not* want to reveal to clients of your data model. (If you do, they can just munge the array at will, which would probably upset your data model greatly.) In a case like this, you can provide an array proxy (such as [modelObject mutableArrayValueForKey:@"indexPropertyKey"]) as the indexed property value, and implement the standard indexed KVC accessors to control what clients can actually do with it. Having the controller be guardian of the "thingToAdd" object doesn't seem like a terrible idea, though it might be plausible to have the data model be the guardian instead, especially if you might like to *save* the partially constructed object with the rest of the data -- so the user doesn't have to reconfigure it construction is interrupted by some other activity -- or if the guardianship requires some knowledge of the internals of the object that the controller really shouldn't have. The other issue that needs care in regard to both your questions is undo. When setters do a lot of work, you need to be careful about what happens at undo or redo time. Plus, if you want the "thingToAdd" construction steps to be undoable, that again might be a reason to put the special object in the data model with the rest of the undoable things, rather than in the controller. (Or not -- it's hard to say in general.) FWIW _______________________________________________ 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
