NSTableView philosophy question.. (MVC Pattern) where to put the dataSource delegate?

  • I have a nice little doc app with a pretty decent MVC pattern I think..
    I have a NSDocument sub-class to handle the document level stuff, a
    NSWindowController to handle the UI interface,
    and even a DocumentSettings type class for the data model (i.e. right
    from the Vermont Recipes stuff!)

    Anyway, I just added a table view and was wondering where is the
    "appropriate" place to put the
    NSTableView dataSource delegation methods?? My first inkling is the
    appropriate NSWindowController sub-class
    but I also was thinking maybe the NSDocument sub-class??

    Just want to keep a clean paradigm here so was wondering what the "Best
    Practices" method is for this pattern..

    TIA!

    -Steve
    _______________________________________________
    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 02-06-25 12:13 PM, <sjmcdowall...> at <sjmcdowall...> wrote:

    > Anyway, I just added a table view and was wondering where is the
    > "appropriate" place to put the
    > NSTableView dataSource delegation methods?? My first inkling is the
    > appropriate NSWindowController sub-class
    > but I also was thinking maybe the NSDocument sub-class??

    Here's my take on this very good question.

    The data source delegate methods play the role of a controller, in MVC
    terms. They take data from a model object (typically an array of records)
    and display it in a view (the table). Going the other way, they take changes
    the user enters in the view and synchronize the array. In other words, they
    mediate between the view and the model. It's therefore convenient and
    sensible to put these delegate methods in the window controller.

    What about the array that holds the data? It is best placed in a model
    object, I think. That way, it's likely to fit more easily into your routines
    for saving the document's data to disk. There is nothing in the data source
    delegate methods that requires the array to be located in any particular
    place.

    In the current version of Vermont Recipes (soon to be a Peachpit Press
    book), this is how I do it. In fact, the data source delegate methods
    associated with my table view switch between two different arrays under
    control of a combo box setting. One of the arrays is located in the model
    object, whence it gets saved to disk. The other is located in the window
    controller because it contains a filtered subset of the full array. The
    subset never has to be separately saved to disk because it is strictly for
    display purposes, so it seems like it is part of the controller. The data
    source methods don't care where either of these arrays are located, as long
    as it can find them somewhere through the outlets available to it.

    I find that "data source" is a misleading term. It tends to make people
    think of the data itself, and some of the documentation refers to it that
    way. But in Interface Builder, when you connect the "datasource" outlet, you
    have to connect it to the object that holds the delegate methods, not to the
    object that holds the data (which might or might not be the same object).
    Think of the data source as a funnel, which is the source of the data in the
    sense that the data pours out of the funnel into the view.

    --

    Bill Cheeseman - <wjcheeseman...>
    Quechee Software, Quechee, Vermont, USA
    http://www.quecheesoftware.com

    The AppleScript Sourcebook - http://www.AppleScriptSourcebook.com
    Vermont Recipes - http://www.stepwise.com/Articles/VermontRecipes
    Croquet Club of Vermont - http://members.valley.net/croquetvermont
    _______________________________________________
    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.
  • At 3:42 PM -0400 6/25/02, Bill Cheeseman wrote:
    > I find that "data source" is a misleading term. It tends to make people
    > think of the data itself, and some of the documentation refers to it that
    > way. But in Interface Builder, when you connect the "datasource" outlet, you
    > have to connect it to the object that holds the delegate methods,

    I'd like to add that by "delegate methods" Bill means "datasource
    methods" (which he has also called "data source delegate methods").

    NSTableView has both a dataSource outlet and a delegate outlet, which
    serve different purposes and which you may or may not choose to make
    the same object.  "Datasource methods" are the ones declared in the
    NSTableDataSource protocol; as Bill eloquently explains, the
    datasource is a Controller object.  "*Delegate* methods" are the ones
    documented in "Methods Implemented By the Delegate" in the class
    docs; I'd say the delegate is a View class (in the MVC sense).

    Just a clarification for those who might not have picked up on the
    datasource/delegate distinction.

    --Andy
    _______________________________________________
    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.
  • A couple of attentive folks (Scott Anguish and Andy Lee) pointed out a
    couple of typos in my post to this thread. I said:

    "But in Interface Builder, when you connect the "datasource" outlet, you
    have to connect it to the object that holds the delegate methods, not to the
    object that holds the data (which might or might not be the same object)."

    I meant to say:

    "But in Interface Builder, when you connect the "datasource" outlet, you
    have to connect it to the object that holds the *datasource protocol*
    methods, not to the object that holds the data (which might or might not be
    the same object)."

    Apologies for any confusion.

    --

    Bill Cheeseman - <wjcheeseman...>
    Quechee Software, Quechee, Vermont, USA
    http://www.quecheesoftware.com

    The AppleScript Sourcebook - http://www.AppleScriptSourcebook.com
    Vermont Recipes - http://www.stepwise.com/Articles/VermontRecipes
    Croquet Club of Vermont - http://members.valley.net/croquetvermont
    _______________________________________________
    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 june 2002 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 30
Go to today