On Jan 18, 2014, at 20:39 , Roland King <r...@rols.org> wrote: > Really does look like the binding code only fires for at the end of > ..didFinishEditing: and not for any programatic set of any property on the > object, at least not one I've been able to find.
That actually makes a lot of sense. It’s quite possible to change the text field *while typing is happening*, and that doesn’t end editing — and shouldn't. > The only bad bit about this is I had to make the model object a property of > the view so the browse button could set the URL property on it, with bindings > alone everything was in IB and the view object implementation had no > knowledge of the model object at all, it just set a string path onto itself > and the model was supposed to pick it up, except it didn't. I’d say it’s not bad in the way you mean. There’s nothing “bad” in views knowing about model properties. In MVC, it’s explicitly envisaged that the controller would tell the view where to find the data model. In practice, I never do it that way any more. I always create a derived property on the view or window controller that’s based on the data model property. So, from the views’ point of view, the view/window controller *is* the data model, but it’s insulated from the real data model. (Specifically, doesn’t have to #import the data model header files, which has housekeeping benefits.) The cost is writing a trivial getter and setter, and a ‘keyPathsForValuesAffecting…’ method in the controller. _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
