On Jul 26, 2009, at 5:53 PM, gumbo...@mac.com wrote:
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.
Then NSDictionary will probably be fine for you. Performance test
it and find out. Best test: a test file with many rows and few
columns, then another with the same rows and many columns. Stick with
nice round numbers and be consistent. The measure, measure, measure.
Ultimately in this situation, as long as it "feels" reasonably
fast, you're probably fine.
This is a very nice and tidy solution,
You're damn right it is!
Er, what I meant was, "I humbly thank you for your compliment." ;-)
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?
Generally speaking, you'd dynamically create NSTableColumn
instances as needed. For each column, you'd bind its value to the
array controller's arrangedObjects.key where "key" represents the key
for that column (the one that corresponds to the field in your row
dictionary that the column represents).
It's the same as in Interface Builder; you're just setting it up
with code. See these two:
http://developer.apple.com/documentation/Cocoa/Reference/CocoaBindingsRef/BindingsText/NSTableColumn.html#//apple_ref/doc/uid/NSTableColumn-DontLinkElementID_601
http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Protocols/NSKeyValueBindingCreation_Protocol/Reference/Reference.html#//apple_ref/doc/uid/20002048-BCICHGHC
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?
For a first-pass, none at all. Go easy first, then optimize if
necessary. Your users may not even notice. Given that Numbers itself
is ... how shall we say ... unconcerned with performance ( :-) ), you
can probably relax a bit yourself. In my situation (I actually have
two separate ones with the same requirements), performance is
everything and so is the ability to heavily reorganize and otherwise
curate the data prior to using it.
For me, it's worth losing some sleep over. YMMV.
--
I.S.
_______________________________________________
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
