I'm developing a Cocoa application with bindings, as should be
obvious. I do apologize if this is a newbie question, but my searches
of the documentation haven't made any of this clearer to me.
I'm trying to make use of the MVC pattern, properly isolating UI code
from my model objects using controllers, and of course using the
standard Cocoa view objects. My application communicates with a
subprocess using NSTask and some NSFileHandles, and stores the
resulting communication text in an NSMutableString. (I take proper
precautions to make sure the string doesn't just grow arbitrarily
large.) To a large extent, the form that the storage of the text takes
is completely irrelevant.
The reason for this is that I want to display this text in an
NSTextView. Probably the most efficient way to do that would be to
provide the NSTextStorage object myself and update it as necessary,
but I don't quite understand the text system well enough to do this,
so I'm working with the simpler ways of controlling the content.
This brings me to the "Attributed String" and "Data" bindings of
NSTextView itself. What it wants is either an
NS(Mutable?)AttributedString or an NSData containing RTF data. I have
neither of those in my model object; I have an NSMutableString
containing plain text data.
My understanding of the MVC pattern says that it would be an
unnaceptable leakage of UI code into the model if I provided methods
in the model object to return the data in those formats.
This brings me to the controller object, which is where such "glue"
code belongs. At the moment, I bind the views to the model using
NSObjectController. But NSObjectController doesn't provide the
functionality I need.
The question becomes, do I subclass NSObjectController, or do I
replace it entirely with my own controller object? For my application,
which is (for the moment, at least) managing a model object which is
always the same and handles data that doesn't fit a simple get/set
paradigm (all my accessor and action methods do some level of state
management!), it seems like NSObjectController's intention is useless.
Is there some convincing reason I should be sublcassing the Cocoa
controller instead of writing my own? I don't need management of the
content object (it's always the same object), editing management (the
model's data is only displayed by the UI, not managed), or any other
service NSObjectController provides.
In the same vein, should I even bother worrying about using the
exposed bindings when managing the NSTextStorage directly is a much
more efficient solution? And where does the NSTextStorage belong, in
the model or the controller? The model really seems like it should
only be responsible for dealing with the NSData of the text it's
getting from the subprocess.
I realize that all of this suggests that my understanding of the MVC
setup in Cocoa is less than ideal; I'm eager to be educated :).
-- Gwynne, Daughter of the Code
"This whole world is an asylum for the incurable."
_______________________________________________
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
