Okay, I – hopefully – understand you now:
You have a view with some (model) objects displayed.
There is another view (potentially or really?) that can display these
objects, too
The additional attributes are specific for each displayed object and
each view?
Correct? (There is a german phrase: "The hope dies last")
So you have an n-to-m relationship between between objects and views.
And you have additional attributes for each of these relationship
"instances". ( … for every concrete relationship.)
Yes, IMHO it is a good idea to "personalize" (bad translation, I do
not know a better one) this relationship and represent it with
instances of a special class.
I did something similiar (if I understood you correct) inside the
model layer (this does not really matter here) in a lawfirm
application. I had the problem, that I had an n-to-m relationship
between files and clients. On each "instance" of the relationship I
needed some additional attributes. (Something like the state of the
client related to this file.) I broke the n-to-m relationship and
modelled a new entity FileClient that holds the additional attributes.
Of course this was easier to me, because it happens solely inside the
model layer. I did not have to register and handle observations. But I
think, that it is the same approach in the core.
Maybe this helps …
Cheers,
Amin
Am Do,28.08.2008 um 11:06 schrieb Oleg Krupnov:
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]
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]
