Re: best way to save document level settings?
Re: best way to save document level settings?
- Subject: Re: best way to save document level settings?
- From: Donald Hall <email@hidden>
- Date: Tue, 9 Dec 2003 23:51:16 -0700
Randall,
Thanks for such a lengthy reply. My document is actually stored as
text and is meant to be read by a second (background) program. I want
to keep it as text to allow the user to be able to easily inspect it
and to make minor adjustments via a text editor. A bundle seems like
it would hinder this. I thought of putting the information in the
document file itself, but it would mean changing the second program
and in any case the information on the sorting columns and sorting
directions has nothing to do with the actual data needed by the
second program. These table settings are not crucial, so if they're
lost by the user using a non resource fork savvy tool to move or copy
the document, it's not a big deal.
Regards,
Don
On Tuesday, December 9, 2003, at 02:32 AM, Donald Hall wrote:
My thanks to everyone who replied. I am looking into using
NDResourceFork as it seems the logical place to put this
information is with the document itself. Any solution I can think
of using the program's preference .plist gets messy quickly if you
want to keep track of the existence of the document files so as not
to be carrying around information on deleted documents in the
.plist file.
What happens if the user is not using the HFS+ file system?
A second file named ._filename.extension is created in the directory
containing the file on non-HFS+ file systems (I think--it could be a
directory containing a single file for each fork other than the data
fork), but if there are file systems that do not support filenames
beginning with '.', I don't know how that situation is handled. I do
know however, that on non-HFS+ file systems it is really easy to
lose or misplace the resource fork if any BSD tools or applications
that are not resource fork aware touch the document.
Also note that, unless you are careful, if the document is to be
shared by multiple users, one user's preferences can wipe out
another user's preferences if the preferences are within any fork of
the document itself.
Here are three other suggestions:
1) if your document is a bundle (like .pbproj or .rtfd documents) or
can be stored as a bundle (like OpenOffice.org or StarOffice
documents (they are zipped directories)), you may want to store
user's preferences in a .plist within the bundle.
2) if your document is a serialized data structure, store the
preferences within the document itself.
3) store a user's per-document preferences in ~/Library/Application
Support/Your Application Name/ using some key stored inside the
document to reference the preferences set. Your preferences set
should be small enough so that most of your users will not have
problems with the disk filling with gobs of small documents as well.
Thanks again,
Don
--
Donald S. Hall, Ph.D.
Apps & More Software Design, Inc.
email@hidden
http://www.appsandmore.com
_______________________________________________
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.