On Jul 13, 2009, at 15:42, Christopher Campbell Jensen wrote:
At first I figured this was a nice way of designing things. Each
separate view element/window has it's own controller, and thereby
reducing the amount of different tasks that the MainWindowController
needs to deal with.
I am now reconsidering, as the amount of communication that will now
have to happen between these three views is causing me many
headaches, as I am struggling to see how I can get this all tied
together. What I am hoping for, is that there is a way that the
different views can create subsets of the core data repository (as
in the search followed by the user selecting his desired results)
which will be held in the managedObjectContext (or similar) and can
then later be accessed by the other views.
What I mean, is that one operation of narrowing down the set of data
will be held so that a the next operation executed is now only
executing on that narrowed set. This would mean that each of my
views didn't need to communicate with each other, instead they would
perform their "narrowing down" on the core data set, and then hand
control back to the MainWindow, which would then use only that
narrowed down set for the further activities.
If you have made it this far, congratulations! I know this is a
mess, and I am sure there are plenty of you who are upset with me
for going about this all wrong. I am sure a lot of people will
disagree with the outlined workflow, and be able to suggest better
ways, but I am for now primarily interested in solving this
technical challenge, as this app will mostly be for personal use and
it's main purpose is for it to be a learning experience for me.
This is also my first post to this community, so if I apologize if I
have broken any written or unwritten rules. I hope someone will be
willing to offer some advice, or partial solutions; and please let
me know if parts require further explanation, or perhaps a diagram
to clear things up.
In terms of the app delegate, window controllers and view controllers,
it sounds like you've done things perfectly for your given user
interface design.
In terms of the "narrowed down" set of data, you haven't quite thought
your MVC design through.
What you have discovered is, for your application design, the desired
data model is *not* the core data managed object context, but a
smaller abstracted object graph.
Think of your data model as the narrowed down data, which is (as an
implementation detail of the data model itself) backed by the core
data managed object context. Your data model consists of (I'm
simplifying, of course) three collections: the set of core data
entities your user wants to choose metadata types for, the
corresponding set of metadata values for each type (for populating
your popups), and the set of data values for each metadata value.
It's not clear if these three collections will themselves need to be
saved somewhere, for the next time the user runs your application. If
so, you could save this information as another set of core data
entities, ready for fetching the next time your application starts. If
not, then these collections are just objects you keep in memory and
throw away as soon as the movie is re-written.
Is that any help?
_______________________________________________
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
