Re: MVC view/controller separation question
Re: MVC view/controller separation question
- Subject: Re: MVC view/controller separation question
- From: Keith Blount <email@hidden>
- Date: Mon, 4 Apr 2005 09:33:40 -0700 (PDT)
- Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
Many thanks for the help again, Serge.
My note view objects do update the note model directly
at the moment, as I pass them a reference to the model
data when they are created. They also set up undo/redo
on getting and losing first responder status.
Hopefully that part is running okay (but as I'm only
part-way through refactoring, it is only hopefully at
the moment).
Rather than have the document handle text changes - I
want to avoid this because I want the text view and
its associated note objects to be as self-contained as
possible - the way I think I am headed is now as
follows:
The text view will set up an instance of a
NotesManager controller object when it is initiated.
This notes manager will observe all changes to the
notes and send notifications accordingly, so that the
margin and text views know when to update. This way,
text views will be able to share notes managers if
they share text storage (to keep two views in sync,
for instance).
The text view can then just send the notes manager a
method such as
updateNoteRangesUsingAffectedCharRange:replacementString:
or something similar, or just post a notification with
this information. The text view will have to
communicate with the notes manager directly no matter
what, as its contextual menu will have the option to
add a note etc...
Hopefully this is at least a little more MVC friendly,
although it does still rely on a view creating and
calling methods on a controller rather than the other
way around, which does seem backward...
Thanks again,
Keith
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden