Re: Question about Saving a document
Re: Question about Saving a document
- Subject: Re: Question about Saving a document
- From: Paul Lynch <email@hidden>
- Date: Sat, 17 Jun 2006 16:27:56 +0100
On 15 Jun 2006, at 11:15, Francis Derive wrote:
On Jun 14, 2006, at 10:45 PM, Paul Lynch wrote:
On 14 Jun 2006, at 11:48, Francis Derive wrote:
You say "You don't want to have your model instantiated in the
nib" but, in the Apple's "Developing Cocoa Applications Using
Bindings: A Tutorial", this is what is made : an instance of the
model named "Converter" is instanciated in the nib, then an
instance of an NSObjectController - the content of which is the
above model, etc...
You shouldn't assume that Apple examples all follow best practices
(they try, but can't always succeed), nor that their examples are
always entirely typical usages.
I had envisage this argument - an example always being a toy-
example - but I can't be convinced about what would seem a
deficiency as I will show.
I wasn't intending to claim that the Apple examples are toy examples
- quite the contrary. I believe that the Apple engineers are very
sensitive to claims of examples being impractal, or demoware, and
they strive to avoid it.
Where I believe that they err is that many examples are heavily
overloaded, being examples of multiple techniques, and therefore of
little use as tutorial examples. However, where they produce demos
and tutorials, as in your CurrencyConverter example, they are fit for
the purpose.
A nib will certainly contain many view objects (windows, buttons,
fields, etc), as well as instantiated controllers, both bindings
controllers and your own classes.
Your controller objects will interact with both view objects, and
model objects. Most commonly, model objects are instantiated
inside your controllers. In a few cases, and the
CurrencyConverter is one, you can have a model object that is
instantiated inside the nib, simply because it is convenient to do
so.
"simply because it is convenient to do so" - but isn't it why nibs
can be so useful, I mean even in *real scale examples* ?
Nibs are of real and practical value. However, they (in general)
contain view and controller objects, and they function in this
world. Because it is so easy to connect between view objects and any
object in a nib, it is generally better practice to avoid putting
model objects in a nib.
If you are right, I immediately rework ( I had done it, and I do
it again here ) this currency converter example by
- deleting the Converter NSObject instance ( the Model ) from the
nib, and
- I create an NSDocument subclass with, as you said, an instance
variable set to the model object ( I will have to show you how I do
that, because I had doubts about my doing that ).
That should work - although it certainly isn't the only way of
expanding this example.
But this point : do I keep in the nib the Object Controller ( the
content of which had been set to the above model object in IB ), or
do I delete it also ?
Controllers need nib connections, so yes, it stays. Although if you
are following the bindings tutorial, I believe it isn't required any
more, and the MyDocument class takes its place.
If I were to keep it in the nib, I would have to do the connection
between this Object Controller and its model object - which is now
an instance variable of the above NSDocument subclass.
Programmatically, by a setContent method - if I am not wrong ?
Here are the strategies that I can think of:
- make Converter an instance variable inside MyDocument, which is
therefore directly accessible to the load/save routines;
- keep converter instantiated inside the nib, but in load/save
extract and set the values from Converter through some proxy object,
most probably a NSDictionary.
You need to implement a connection from your document controller
to the converter object,
"document controller" ? Isn't going too far ?
Depends which example you are following! The basic Cocoa example
(http://developer.apple.com/documentation/Cocoa/Conceptual/
ObjCTutorial/ObjCTutorial.pdf) is a single window app with Converter
and ConverterController. However, the bindings update to this
(http://developer.apple.com/documentation/Cocoa/Conceptual/
CurrencyConverterBindings/CurrencyConverterBindings.pdf) substitutes
MyDocument for the ConverterController class.
Using NSDocument gives you a lot of extra functionality, with
arguably less effort invested.
Paul
_______________________________________________
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