• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Question about Saving a document
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


References: 
 >Question about Saving a document (From: Francis Derive <email@hidden>)
 >Re: Question about Saving a document (From: Paul Lynch <email@hidden>)
 >Re: Question about Saving a document (From: Francis Derive <email@hidden>)
 >Re: Question about Saving a document (From: Paul Lynch <email@hidden>)
 >Re: Question about Saving a document (From: Francis Derive <email@hidden>)

  • Prev by Date: Re: future proof icon sizes?
  • Next by Date: Re: Blocking loops
  • Previous by thread: Re: Question about Saving a document
  • Next by thread: XXFinderView?
  • Index(es):
    • Date
    • Thread