On Mon, Mar 9, 2009 at 4:04 PM, Karolis Ramanauskas <karol...@gmail.com> wrote: >> STOP IT. >> >> That's right. Stop it. >> >> No no, just .... just stop it.* > > I needed that, ;)
Sometimes a comically cold splash of water helps. ;-) > I can't come up with a better way either, I've been > sitting and reading all this morning, my platonic MVC ideal a little > diminished... For what it's worth, I speak from experience here. I have a similar situation (different data mining 'views' on a large data set, each with multiple graphical representations, each of which have their own custom settings defined by the user - all of which must be persisted so the user can switch between saved views). For a short moment, I was also momentarily confused as to how / where to store this information. I got over it. ;-) For this, I have a "SavedView" entity. The saved view stores all graph settings as well as the current configuration of the data view (how the data is cut, shuffled, stacked, racked, and computed). > Perhaps this could be one-to-many relationship so I could > associate several view settings (for different views, if needed, more than > one view per app) with one object! Ha, really this would only mean adding > one property to my model and it will not even be reflected in code since > Core Data defaults will probably suffice. Well the original idea was: Node <----->> Representation ... you'll need to add a "Representation" entity with appropriate attributes, but then all you need to do is ask for the representation whose node is x and whose associated view is y. For performance, you'll want to grab all the needed representations in one go (see "batch faulting" and other approaches in the Core Data guide) so you're not making multiple round-trips to the data store (if using SQLite or some other atomic store). But that's for later, if you see a performance problem. -- 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
