Re: NSDocument Default Contents
Re: NSDocument Default Contents
- Subject: Re: NSDocument Default Contents
- From: James Quick <email@hidden>
- Date: Tue, 15 Jul 2003 11:11:49 -0400
On Monday, July 14, 2003, at 07:52 PM, The Amazing Llama wrote:
I'm implementing an NSDocument subclass, which is simple enough.
I know that if I want to make something happen in all documents, new
or opened, I put that code in -init.
If I want it to take place only in opened documents, the code goes in
-initWithContentsOfFile:
Where should I put code that should fill a new document with 'default'
data? Should I put it in -init, and then erase it in
-initWithContentsOfFile? That seems a little kludgey.
Better ideas?
Sorry if this is redundant, but I thought I responded late last night,
and did not see it in the
list this morning or in my Sent folder. Oh, well.
The way you talk about -init and -initWithContentsOfFile, suggests that
you are thinking about
init methods in terms of partitioning responsibility among the methods.
Perhaps the better
idea you are looking for is actually a different way of looking at
initialization.
Try this idea on for size.
Instead of partitioning responsibility for initialization tasks among
various methods, think
about the information you need to supply the initialization process,
and the default
behavior you wish when something is unknown. By doing so,
initialization methods
reduce to a designated initializer which is called when all the
required information is
known, and 0 or more other initializers which are called when one or
more pieces of
information are unspecified.
In this pattern the designated initializer is the end of any path
through the initialization
message chain. The path leads from incomplete to complete
specification of data.
In each step one or more pieces of information are specified, until we
know enough
to do the job.
Let's take your your situation as an example.
By asserting that a new document instance must have a specified content
and type, the
natural designated initializer becomes:
-initWithContentsOfFile: (NSString *) fileName type: (NSString *)
ofType.
-init's role, thus is reduced to that of declaring what content to use
when none has been
explicitly specified.
Since we have two NSStrings to play with here, we have several choices
about how to
specify the need for default data. Perhaps it makes sense for you to
say that a nil object
passed as the fileName parameter means use the 'default' data.
Alternatively you might
prefer to examine ofType instead, specifying that
[ofType equals: @"default] or
[ofType hasSuffix defaultSuffix]
indicate that default data is to be used. For this example a nil
fileName will serve.
// Designated initializer
-initWithContentsOfFile: (NSString *) fileName type: (NSString *) ofType
{
BOOL usedDefault = FALSE;
if ((self = [super init])) {
if (fileName == nil) {
usedDefault = TRUE;
fileName = [self returnFullPathToDefaultDataOfType: ofType];
// Yeah, lousy method name there but you get the point....
}
// Now that name and type are known, do all your business.
if (usedDefault) {
// do additional work, perhaps unsetting memory of the path
// so on first save the document does not attempt to overwrite
// the default template, etc.
}
}
return self;
}
-initWithContentsOfFile: (NSString *) fileName
{
return [self initWithContentsOfFile: fileName ofType:
currentDefaultFileType];
}
- init
{
return [self initWithContentsOfFile: nil];
}
You may wonder why I chose to defer specifying the file to use for
default data to the
designated initialiser. I did so, here, under the assumption that the
documents may
support multiple types, or for some other reason it may be difficult to
predict the
appropriate behavior until all the other information required for
initialization is
known. Also, I felt it was appropriate, since it was the most extreme
example by
doing absolutely all the work in the designated initializer. In other
cases it may be
wise to find the information earlier like:
- init
{
return [self initWithContentsOfFile: [self getFileNameForDefaultData]];
}
Note that in some Classes there may be several initialization chains.
A number of
Cocoa class clusters have multiple designated initializers for good
reason. In
most cases, however, having multiple designated initializers, is
undesirable.
I Hope this helps.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.