Re: MVC, storing VIEW-specific information and core data
Re: MVC, storing VIEW-specific information and core data
- Subject: Re: MVC, storing VIEW-specific information and core data
- From: "I. Savant" <email@hidden>
- Date: Mon, 9 Mar 2009 16:16:29 -0400
On Mon, Mar 9, 2009 at 4:04 PM, Karolis Ramanauskas <email@hidden> 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 (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