Yes, you are correct. I am looking not to break MVC and also get the correct implementation of binding in a custom view
> Just an example: I had a graphic application that drawed some inserted > shapes. The shape itself is a part of the model, the color of the shape, > too. But when the user selects a shape (symbol), the color should change. So > the drawing of the shape depends on a view property. I think, this is the > core of your problem. Selection may not be a good example, because it is a "global" property of the view, among all objects in the view, whereas I am talking about states *per each" object in the view. Such state properties become particularly indispensable for drawing, because drawRect message is called "asynchronously", i.e. in the next event loop, not in direct response to the binding's KVO message. The other case is when I need, for performance reasons, to associate some view-specific cached data with an object in the view, to avoid recreating it each time I need the data to respond to the binding's KVO message. In other words, I need a way to associate additional custom-view-specific properties with model object, without adding them as transitive properties to the model. What is the best way to do this? Or maybe your point is that this is a bad idea at all and such problem should not arise, and I need to include everything in the model? What is the standard workaround suggested in Cocoa? > I solved it by returning only bezier paths and colors from the model. So the > shape itself (model) is still a part of the model, but the drawing > (depending on the view) is done inside the view. (Simply by stroking the > paths.) It is not completely clear how this would help me to resolve the above problem. It is not a problem for me to store the bezier paths and colors in the model. But what about some volatile custom-view-specific states that have nothing to do with the model? The other completely different design I am also considering is to create and bind a "subview" object for each model object. By "subview" I mean just a subclass of NSObject that is bound to its model counterpart. It could work like this: The custom NSView observes its NSTreeController and when a new child model object is created, the custom NSView creates the corresponding subview object (All subview objects are owned by the custom NSView) and binds it to the model object programmatically. When the model object is changed or removed, its subview counterpart responds correspondingly. In this manner I could hold all the view-specific states and cache data in the subview object. What do you think? On Thu, Aug 28, 2008 at 11:35 AM, Negm-Awad Amin <[EMAIL PROTECTED]> wrote: > > Am Do,28.08.2008 um 10:15 schrieb Oleg Krupnov: > >>> Parts of your first question remind me of a situation that I had. Erik >>> Buck gave me some great advice and part of it was the following: >> >>> If you are worried about adding drawing code to a "Model" object, add the >>> drawing code in a category of <the model object>* and maintain the category >>> implementation in the "View" subsystem. >> >>> *I changed the words he used here because he used the name of my specific >>> class and I wanted to make it more readable in the general case. >> >>> This will let you put a category into every view that you want to so that >>> your model objects get handled correctly for each view. >> >> This may be indeed a good idea to use categories for this purpose. Is >> it what everybody is using? >> >> I have only one problem with this approach: As I mentioned before, I >> need to add custom-view specific instance variables (states) to the >> model object's category. The Objective-C categories do not allow >> adding instance variables, only methods >> >> I am considering to create a dictionary owned by the custom view, >> containing state objects keyed by model object unique ID. This is a >> kind of surrogate of subclassing the model objects inside the custom >> view. I am not sure this is a good idea though. Are there other >> approaches? > > If I understood you correct, you think, that you fear a voilation of the MVC > pattern. Correct? > > Think about some points: > - sometimes the shape or something like this is a true part of the model. > Think about predefined shapes and so on. So there is nothing wrong in > storing that informtion in the model. > - Can you isolate the "shape-part" (model) from the drawing part (obviously > depending on view states)? > > Just an example: I had a graphic application that drawed some inserted > shapes. The shape itself is a part of the model, the color of the shape, > too. But when the user selects a shape (symbol), the color should change. So > the drawing of the shape depends on a view property. I think, this is the > core of your problem. > > I solved it by returning only bezier paths and colors from the model. So the > shape itself (model) is still a part of the model, but the drawing > (depending on the view) is done inside the view. (Simply by stroking the > paths.) > > Cheers, > Amin > >> >> _______________________________________________ >> >> 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/negm-awad%40cocoading.de >> >> This email sent to [EMAIL PROTECTED] > > Amin Negm-Awad > [EMAIL PROTECTED] > > > > > _______________________________________________ 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 [EMAIL PROTECTED]
