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 07:39:18 -0700 (PDT)
- Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
Many thanks for your reply, much appreciated.
> The approach I would take would be to have the note
> objects know how to draw themselves, and have a note
> manager which manages the notes and tells them when
> and where to draw, either in or around the textview.
I think you are right and that creating a note manager
is definitely the way I should go. My note objects are
actually split into two classes - a model object and a
view object, which draws the note. At the moment the
text view is handling notifications that tell the
margin view to create note views to represent note
models, but I will create a note manager to do this
part of the job and to handle the array of notes.
The reason I have separated the note objects into
models and views is that the text view that uses them
can appear in two states - with or without a margin.
If it has a margin, then the notes are drawn there and
the user can edit them. The ranges to which they are
attached are highlighted in the text view. If the
textview does not have a margin, tool tip rects are
set up for the ranges of text that the notes are
attached to, so that the note will appear when the
user leaves the cursor over a highlighted range. Only
the note model is required for this state.
So my new setup would be like this:
Note model (contains the range of the text to which it
is attached in the text view and the note string)
Margin view - deals with creating/removing note views
Note view - created by the margin in response to
notifications from the note manager
Note manager - creates, deletes and updates note
information and posts notifications of any changes
Text view subclass - for custom drawing
The only remaining problem is that the text view still
needs to update all of the ranges to which the notes
are attached in didChangeText, which should really be
part of the controller's job. I don't want to make the
notes manager the delegate of the text view and do it
all in textDidChange: because that makes everything
less flexible (the text view would not be able to
given an arbitrary delegate).
> IMO using coredata & bindings really helps be more
> rigorous about all this since almost all the code
> you are writing becomes controller code, so that
> almost every object you create explicitly is a
> controller.
Unfortunately I have yet to discover the benefits of
CoreData as I can't afford the membership to get Tiger
previews until my application is mature enough to earn
its keep, but I would be very grateful if you could
elaborate on how bindings might help me in this
situation. I had set about making everything
KVO/KVC-compliant with the intention of just
monitoring changes on the data for updating views and
setting up undo/redo, when I realised that this would
be too simplistic. For instance, it is no good
updating all of the note views in the margin when text
in the text view is edited until *all* of the notes
have been updated, otherwise there will be too many
updates - thus I cannot simply monitor changes to note
model data.
Sorry for the long post, and thanks again for the
help,
Keith
__________________________________
Yahoo! Messenger
Show us what our next emoticon should look like. Join the fun.
http://www.advision.webevents.yahoo.com/emoticontest
_______________________________________________
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