Re: core data approach to multi-column data?
Re: core data approach to multi-column data?
- Subject: Re: core data approach to multi-column data?
- From: Matt Neuburg <email@hidden>
- Date: Tue, 22 Aug 2006 12:33:45 -0700
- Thread-topic: core data approach to multi-column data?
On Tue, 22 Aug 2006 14:46:21 -0400, "Paul L. Gribble" <email@hidden>
said:
>I am writing an app that does various statistical analyses on columns
>of data (e.g. mean, correlation, t-tests, etc). A given document will
>contain a "dataset". The dataset is essentially a 2-dimensional
>array. The number of rows and columns can dynamically change.
>
>I am trying to think about how (a) to design the core data entities,
>and (b) how to link them easily to a view (e.g. NSTableView). One
>idea is to have an entity called "row" which has a many-to-one
>relationship to an entity called "column". Then each row of data can
>have multiple columns. The question then is how to get an NSTableView
>to be bound to display each "column" of data in its own column in the
>NSTableView. Core data seems set up for more traditional database-
>style apps where a row in an NSTableView is a single entity, and the
>different columns are different attributes of that entity.
You might be confusing two very different things here. Core Data has nothing
to do with display of data. It is simply a generalisation of the
object-oriented way of *maintaining* data (model objects, to be precise).
You don't need to use it; you can maintain data however you like. So let's
forget about Core Data for a moment, and consider the NSTableView.
There is ultimately only one way to display values in an NSTableView, and
that's to give the NSTableView a data source. The NSTableView asks the data
source, "what value should I show in this cell?", and the data source tells
it. Now, it is also true that there is a shortcut that saves you from having
to write the data source code yourself, and that's to use bindings. If you
do, they are column-oriented (each column in the table has its own binding),
so Bob's your uncle. But you don't need to use bindings either.
The place where you may be getting confused is that *if* you use Core Data
and *if* you want to supply values to an NSTableView using bindings, there
is a further shortcut because you can bind right into Core Data. But you
don't have to.
So, really, what I'm suggesting is that to clarify your thought you might
like to start by using neither Core Data nor bindings. Maintain your data
however you like, and use a good old-fashioned data source to mediate
between the data and the user interface. Once you have that solved, you can
modify it to use bindings and/or Core Data there is something that these
will make easier or better for you.
m.
--
matt neuburg, phd = email@hidden, <http://www.tidbits.com/matt/>
A fool + a tool + an autorelease pool = cool!
AppleScript: the Definitive Guide - Second Edition!
<http://www.amazon.com/gp/product/0596102119>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden