Re: Tracking changes to NSTableView datasource
Re: Tracking changes to NSTableView datasource
- Subject: Re: Tracking changes to NSTableView datasource
- From: "Michael Ash" <email@hidden>
- Date: Sat, 1 Nov 2008 23:05:45 -0400
On Fri, Oct 31, 2008 at 6:37 PM, Andre Masse <email@hidden> wrote:
> Hi,
>
> I have a datasource for an NSTableView which is a NSMutableArray (call it
> mainArray for the moment) and I'm not sure which way is better to manage
> add, update and delete rows. I can use either one array for each of those
> cases or add a field to the mainArray (like 1 for new, 2 for update) and
> only one array for the records to delete (I'm using a back-end database).
> The first problem with the former is if (when) the user add a row and modify
> it later on (but before any updates to the back-end are done) I will need to
> check if its a new row (by quering the newRows array) and then not add it to
> the update array if it is. Not counting keeping both array content in
> sync... With the later, only checking the field will tell me if its a new
> row or not. At this point, I prefer the second method and can't see too many
> problems with it... Now, how you guys handle these kind of things?
I don't know if it's compatible with how you want things to work, but
an interesting feature of the NSTableViewDataSource protocol is that
you don't actually need an NSArray backing store at all. You can
instead just get and store data directly to whatever, well, stores
your data.
For example, if you have a directory listing in a table, then you
don't need to fetch the whole directory and store all the pertinent
information in an array. Instead you can just fetch the information
about the Nth file when the table queries it. This has some advantages
in simplicity, and also performance. The table is smart enough to only
ask for items that it actually needs in order to render, so for a
large data set it's only going to ask for the small fraction of items
that are visible. This means that the app doesn't have to pause while
building the directory listing.
In your case, you could hook the table directly up to the database,
bypassing the intermediate representation altogether. When the table
requests an item, query the database and return the data. When the
table updates a value, set the value in the database. As I said, I
don't know if this matches with how you want it to work, but if it
does then it could simplify what you're doing quite a bit.
Mike
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden