Re: Design Question: Bindings & Custom Views
Re: Design Question: Bindings & Custom Views
- Subject: Re: Design Question: Bindings & Custom Views
- From: "Oleg Krupnov" <email@hidden>
- Date: Thu, 28 Aug 2008 12:06:43 +0300
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@hidden> 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 (email@hidden)
>>
>> 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:
>>
>> This email sent to email@hidden
>
> Amin Negm-Awad
> email@hidden
>
>
>
>
>
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden