Thanks People, This is excellent advice and very helpful.
The main purpose of the app was to load the CSV (exported from
Numbers) and turn the data into an HTML table with some hard coded CSS
hooks. This works well now, but the format required from the CSV is
not very flexible. So I thought if I could display the data, somehow,
the user could sort as they required and select values to add css.
Well, you are correct that I assumed that it was a beginner question
and that the OP was working with a fixed number of known columns (a
reasonable assumption, I suppose, since he wants to use bindings).
He could start with dictionaries, then switch to a custom class for
rows if the performance using dictionaries was inadequate.
Definitely a beginner question, I still have to squint quite hard when
it comes to the magic of bindings.
If you go the dictionary route, using the keys to identify the
"fields" in each row, you're storing *way* more than just the
individual field contents. You're storing a copy of your field
identifier keys for every field, for every row. Best-case scenario,
you're storing a pointer to some object that represents the
"column" to which the fields belong, but this defeats the ease-of-
use with bindings as you need string keys.
Not necessarily. If the keys are NSStrings, then they are copied
when added to the dictionary, but a copy of an immutable string is
optimized to just retain it, so the data isn't duplicated (assuming
all rows have the same columns in the same order, an assumption you
don't seem to be making).
As I mentioned above, with increasingly large files, this
dramatically increases your reading/writing time and uses a lot of
memory. But at least you get the ability to easily use bindings and
to sort, all for free, performance be damned.
Keep in mind that an NSArrayController created in Interface Builder
is defined by default to create an NSMutableDictionary for each item
in the dictionary. It's not unreasonable, and we don't know the
OP's performance requirements.
Performance just needs to be usable at this stage, once the concept is
proven I can look further into this.
If you go another route (an array of arrays of strings), it's far
more efficient, but adds a few programming complexities:
1 - How do you sort by a column? There's no key for sort
descriptors and sorting via selector provides no way to pass
additional information (such as column index or identifier).
2 - To what do you bind? The same limitation that causes concern in
problem #1 makes #2 difficult ... and there is little by way of
over-the-counter laxative to make #2 less difficult.
3 - If you intend to allow reordering of columns (built-in
NSTableView feature) or even adding/removing columns, how do you
handle keeping the columns mapped to the correct fields in the row
array in the absence of an associative array (dictionary)?
The easiest solution to all three of these problems (in my opinion)
is to make a "row" a custom class and a helper class (we'll call it
"ColumnMapper" - one mapper shared among all rows). The row's
internal storage can still be an array of strings for low overhead,
but the Row class has a trick up its sleeve. It overrides -
valueForUndefinedKey: so that it can still look up associative
values (like a dictionary) but without storing them. The storage
occurs once in the ColumnMapper.
This is a very nice and tidy solution, I already have the tableView
expanding to the size required to fit the data and the logic handles
odd shaped tables. Can you go into a bit more detail with regard to
the setting up the bindings? do I bind the tableView column to an
arrayController which handles the rows? what model key path?
Unfortunately, I know from experience that when the row count gets
above 8xx,000, NSTableView can no longer accurately draw rows in the
view (if they are the standard-sized text fields). But that is well
beyond that magic tipping point :-)
I imagine the largest table would be about 15x300, but I don't like
making these assumptions, Murphy's law #1)
I am a little concerned about this, how much sleep should I be losing
over this problem?
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
