Re: NSCollectionConroller ?
Re: NSCollectionConroller ?
- Subject: Re: NSCollectionConroller ?
- From: Shaun Wexler <email@hidden>
- Date: Sat, 28 Feb 2004 00:02:32 -0800
On Feb 27, 2004, at 11:31 PM, Allan Odgaard wrote:
On 28. Feb 2004, at 1:20, T Reaves wrote:
Collection semantics. :)
[...]
Perhaps if/when NSCollection and its subclasses are introduced, so
will NSCollectionController.
Do you mean that you would like to see consistent naming in the
various existing collection classes, or that you want to introduce a
common (abstract?) super class for these? or perhaps something third?
Controlling other classes is what the OP to want. While prototyping
controllers/bindings on the first WWDC preview of Panther, I thought
that I needed something similar. I was wrong. The user interface
should always be maintained in well-known order, and unordered
collections such as dictionaries or sets must be sorted into an array
for display purposes anyway.
When needed, a filter object can stand between the controller and any
object in the model, and provide filtered content for controllers,
using the optimized key value coding array function. At least, that's
how I've implemented my own SKWCollectionFilter class (cluster). Maybe
"NSCollectionFilter" will become the next member of the
controller/bindings architecture, similar to a NSValueTransformer?
Prior to WWDC this year, I may submit my code to Apple for inclusion in
DTS sample code, and/or adoption in the next Cocoa version.
As an aside, I've found some bugs in Cocoa controllers/bindings which
cause retain cycles in objects with complex relationships. For a
workaround, I simply create arrays of lightweight sub-controller
objects which wrap the model and view/controller interfaces as
necessary (basically, accessor methods), so no Cocoa controllers are
even indirectly bound to actual model objects, in the circumstances
where this becomes necessary. My frameworks have an automatic
non-retained observing mechanism, which provides a thread-safe
interface on top of which a custom bindings layer could be built. My
observable objects can communicate with each other very efficiently,
and will automatically update any interested (directly registered)
observers, without their explicit registration of individual change
notifications.
--
Shaun Wexler
MacFOH
http://www.macfoh.com
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.