What's the argument aTableView used for?

  • I'm trying to understand how NSTableView works. A NSTableView needs a
    dataSource object that implements the method
    tableView:objectValueForTableColumn:row:

    Hillegass' book states:
    - (id)tableView:(NSTableView *)aTableView
    objectValueForTableColumn:(NSTableColumn *)aTableColumn
    row:(int)rowIndex
    The dataSource will reply with the object that should be displayed in the
    row rowIndex and the column aTableColumn.

    As we can see above our method takes three arguments: aTableView,
    aTableColumn and rowIndex. Now the dataSource object clearly needs the two
    arguments aTableColumn and rowIndex. But what does it need the argument
    aTableView for?

    Thanks Frank
  • On 18/09/2007, at 5:15 PM, Frank Bettger wrote:

    > But what does it need the argument aTableView for?

    In case you use the same object for multiple NSTableView instances.

    - Chris
  • Thanks, Chris,
    I suspected that, but wouldn't it be cleaner if you had multiple dataSource
    objects, one for each NSTableView instance. (Even if there are
    interdependencies between the tables there is nothing preventing you from
    reading other table models from within your code.) Is there any advantage to
    use the same object for multiple NSTableView instances?

    On 9/18/07, Chris Suter <chris...> wrote:
    >
    >
    > In case you use the same object for multiple NSTableView instances.
    >
    >
  • on 2007-09-18 4:54 AM, Frank Bettger at <frankbettger...> wrote:

    > wouldn't it be cleaner if you had multiple dataSource
    > objects, one for each NSTableView instance. (Even if there are
    > interdependencies between the tables there is nothing preventing you from
    > reading other table models from within your code.) Is there any advantage to
    > use the same object for multiple NSTableView instances?

    Here's my take on it:

    A data source object is defined as an object that implements the required
    data source methods.

    There is typically no reason to clog up your code with multiple classes, all
    of which implement the same data source methods but with different code for
    each of them. It's easier to have a single data source object whose methods
    branch internally according to which table view is passed in. Often, in
    fact, the data source methods are simply placed in your window controller,
    so that the window controller is the data source object, in addition to
    playing all its other roles. This is especially sensible if all your data
    comes from some external repository.

    On the other hand, the runtime will parse out separate data source classes
    with roughly the same branching, so either technique will be of roughly
    equal efficiency. A fairly common model, done as you suggest, is to
    encapsulate a particular set of data, such as an array, and its data source
    methods in the same class, and in that case there is good object-oriented
    justification for creating a separate class for each group of data and data
    source methods. But there is no requirement that the data and the data
    source methods be in the same class.

    In the end, it's just a matter of which technique you find more
    understandable for a particular application.

    --

    Bill Cheeseman - <bill...>
    Quechee Software, Quechee, Vermont, USA
    www.quecheesoftware.com

    PreFab Software - www.prefabsoftware.com
  • Frank Bettger wrote:
    >> In case you use the same object for multiple NSTableView instances.
    > I suspected that, but wouldn't it be cleaner if you had multiple
    > dataSource
    > objects, one for each NSTableView instance.

    It really depends on the specific situation. Having the argument, you
    can use it or not as fits your needs. If you didn't have it, you
    wouldn't even have the choice.

    G
  • It depends on how much code is in your data source methods and how
    much is common to the different table view instances.  A switch
    statement or an if-then is simpler and more readable in many cases
    than creating a separate class.

    Even if you only have one table view, your data source method may
    want to send a message to it or pass it as an argument to some other
    method.

    Another way to think of it is that data sources are a way to add
    behavior to a table view without subclassing NSTableView.  Think of
    each data source method as being like a method on the table view.
    Instead of self (the table view) being an implicit argument to the
    method, it has to be explicit.

    Note that besides all the data source methods in Cocoa, all the
    delegate methods take the delegator as their first argument, for the
    same reasons.

    On a more general note, switch statements can be a red flag in object-
    oriented code, but it really depends.

    --Andy

    On Sep 18, 2007, at 4:54 AM, Frank Bettger wrote:

    > Thanks, Chris,
    > I suspected that, but wouldn't it be cleaner if you had multiple
    > dataSource
    > objects, one for each NSTableView instance. (Even if there are
    > interdependencies between the tables there is nothing preventing
    > you from
    > reading other table models from within your code.) Is there any
    > advantage to
    > use the same object for multiple NSTableView instances?
    >
    > On 9/18/07, Chris Suter <chris...> wrote:
    >>
    >>
    >> In case you use the same object for multiple NSTableView instances.
    >>
    >>

  • Maybe, maybe not.

    I have a pair of table views (masquerading as scrolling lists) that
    are a sort of master detail view on an NSDictionary with string keys
    and array values.  Pick a key in one table view and I show the values
    and I show the values in a second one.

    So, realistically, both tables are using the same data source (the
    NSDictionary) but showing different facets of it.  So I have one
    datasource, two table views, and the datasource does different things
    depending on which table view is asking for info.

    For this case, this is "The Simplest Thing That Could Possibly
    Work"(tm).

    On Sep 18, 2007, at 1:54 AM, Frank Bettger wrote:

    > Thanks, Chris,
    > I suspected that, but wouldn't it be cleaner if you had multiple
    > dataSource
    > objects, one for each NSTableView instance. (Even if there are
    > interdependencies between the tables there is nothing preventing
    > you from
    > reading other table models from within your code.) Is there any
    > advantage to
    > use the same object for multiple NSTableView instances?
    >
    > On 9/18/07, Chris Suter <chris...> wrote:
    >>
    >>
    >> In case you use the same object for multiple NSTableView instances.
    >>
    >>

previous month september 2007 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