I totally disagree with that assessment. Selection should NOT be a property
of the object model. I tried that years ago. Bad move. Selection is part of
the ³control² layer of MVC. The Œview² part displays to the user. The array
of objects is part of the model. You should be iterating the array for
drawing and iterating the selection array to show selection. Of course,
optimized drawing can be used to test if redrawing is needed. If an
appearance change is necessary, it could be done in one iteration. It¹s just
not that hard to test if the index is in the selection indexSet. In either
case, the NSArrayController is the best way to keep track of selection. It¹s
a great tool. Use it.

The Sketch sample code is probably the most complex, but most useful,
example in the entire sample code set. I used a lot of it. However, early
on, I decided to never subclass my shape objects and only have one Shape
managedObject in my model. I also departed from the standard ³shapes know
how to draw themselves² object approach and outboarded a separate
ShapeRenderer class which handles all object drawing. The wisdom of that
approach, single Shape class and separating drawing from the model, has
proven itself many times over.


On 1/18/15 3:00 PM, "cocoa-dev-requ...@lists.apple.com"
<cocoa-dev-requ...@lists.apple.com> wrote:

> On Jan 18, 2015, at 00:10 , Rick Mann <rm...@latencyzero.com> wrote: > > I'm
> building a view that renders a bunch of objects (a drawing canvas). Some of
> these render differently if the objects are selected. As I iterate through the
> list of objects to render, I need to test if each one is selected. It would be
> easier to test if each one is in the array controller¹s ³selectedObjects².
> However, I wouldn¹t do that either. Given that the selection status of an
> object affects its appearance, I¹d say it¹s better to make it an explicit
> property of each selectable object. Otherwise, you¹re forced to drag the array
> controller¹s API into all of your drawing code. As far as I¹m concerned, an
> array controller is a piece of glue code, a necessary evil. Any reference to
> it in code is at best a disappointment, at worst a design failure.


_______________________________________________

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

Reply via email to