NSCollectionConroller ?

  • Has anyone implemented one of these, so that you are not limited to an
    array?

    [demime 0.98b removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
  • On Feb 25, 2004, at 7:52 PM, T Reaves wrote:

    > Has anyone implemented one of these, so that you are not limited to an
    > array?
    >
    You're not limited to an array; "all" you have to do is implement the
    indexed accessors -- the representation of the data source is
    irrelevant.  See "Cunning stuff" at
    <http://homepage.mac.com/mmalc/CocoaExamples/controllers.html>
    (the relevant example is restored).

    mmalc
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
  • well, you're not really limited to an array using an NSArrayController
    as long as the content object implements the indexed accessor methods.

    also, you can use value transformers and "handles content as compound
    value" to translate data to and from arrays

    On Feb 25, 2004, at 10:52 PM, T Reaves wrote:

    > Has anyone implemented one of these, so that you are not limited to an
    > array?
    >

    what specifically were you looking for collection wise?
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
  • On Feb 26, 2004, at 1:49 AM, Scott Anguish wrote:

    > well, you're not really limited to an array using an NSArrayController
    > as long as the content object implements the indexed accessor methods.
    >
    > also, you can use value transformers and "handles content as compound
    > value" to translate data to and from arrays
    >
    > On Feb 25, 2004, at 10:52 PM, T Reaves wrote:
    >
    >> Has anyone implemented one of these, so that you are not limited to an
    >> array?
    >>
    >
    > what specifically were you looking for collection wise?
    >
    >

    Collection semantics.  :)

    The indexed access will work for what I had in mind when I asked the
    question, but Cocoa still suffers from not supporting Collections (yes,
    I've filed a bug on this, and Apple has expressed interest).

    Perhaps if/when NSCollection and its subclasses are introduced, so
    will NSCollectionController.

    Thanks for the response.

    [demime 0.98b removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
  • 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?
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
  • 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 | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
  • On Feb 28, 2004, at 2:31 AM, 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?
    >
    >
    All of the above.  My following explanation is MY take on things; I'm
    not insinuating it is the 'correct' way.

    When I see array, I thing of a collection of like items.  So you might
    have an array of NSString objects, but not an array containing NSString
    and NSNumber objects.  Array connotes a typed collection.

    Then you have a list; an arbitrary, untyped collection of objects that
    allow duplicates.  Notice I said nothing about ordering.  Now we have
    set.  This to me has a mathematical definition, as a group of untyped
    objects were duplication is not allowed.

    Lastly, you have the concept of ordered versus unordered.  There will
    be times when either is appropriate, and times when a very specific one
    is required.

    All of these have things in common; the ability to iterate over them,
    to create sub-collections from them, to combine them with other
    collects, to get the contents, to determine membership, etc.  This
    functionality aught to be described in an NSCollection superclass.

    A few places I think NSArray & NSSet fail are: a) ordered sets.
    Putting a filter on a set would suffice (and allow for arbitrary
    sorting order), but interposing a filter and creating an array is just
    too manual. b) no list.  Whereas NSArray is used as a list, there is no
    way to differentiate which is truly desired. c) no superclass.  Where
    can a generic 'collection' be used, versus an actual set.

    So a class hierarchy might look like the following:

    NSCollection
    NSOrderedCollection
      NSList
      NSArray
      NSOrderedSet
      NSString (couldn't help myself with this one!)
    NSUnorderedCollection
      NSBag
      NSSet
    NSOrdering
    or some such.  NSOrderedCollection could have a setOrdering:
    (NSOrdering*) ordering to allow for arbitrary ordering, with the
    default being index to the order of addition.

    Notice NSArray is a subclass of NSList.  Here, the add*: methods are
    over ridden to allow adding only one type of object (perhaps defined by
    the first object added).  There are times when I want a collection, and
    I want it clear it is only to hold one type of object.

    This aught to all be fairly familiar to any Smalltalk'er.

    [demime 0.98b removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
  • On Saturday, Feb 28, 2004, at 19:36 Europe/Prague, T Reaves wrote:

    > All of these have things in common; the ability to iterate over them,
    > to create sub-collections from them, to combine them with other
    > collects, to get the contents, to determine membership, etc.  This
    > functionality aught to be described in an NSCollection superclass.

    What for? Luckily, unlike Java or C++, we happen to have a polymorphism
    in ObjC: the following code works excellently for any array or set in
    container, no superclass needed:

    if ([container containsObject:object]) printf("It's there");
    else {
    printf("It's not there, but these are:");
    NSEnumerator en=[container objectEnumerator];
    id o;
    while ((o=[en nextObject])) printf([[o description] cString]); //
    okay, cString obsoleted, I know
    }

    Make the container mutable anything, addObject: would work just as well.

    I am not sure how to reasonable define operations like sub-collections
    or combinations regardless the type of the target, which IMnsHO is why
    there are no such services currently; nevertheless, if you know how it
    should look like, a few categories would add the services easily and
    again keeping the full polymorphism.
    ---
    Ondra Hada
    OCSoftware:    <ocs...>              http://www.ocs.cz
    private        <ondra...>            http://www.ocs.cz/oc
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
previous month february 2004 next month
MTWTFSS
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
Go to today