Re: determining encoding on documents
Re: determining encoding on documents
- Subject: Re: determining encoding on documents
- From: Francisco Tolmasky <email@hidden>
- Date: Mon, 21 Jul 2003 11:04:32 -0700
I've read it, but mostly I was concerned with opening files that my app
did not create. BBEdit has an autodetect for encodings. If someone
makes a UTF8 file in another program, I want them to be able to read it
from mine.
On Monday, July 21, 2003, at 07:57 AM, James Quick wrote:
On Monday, July 21, 2003, at 03:26 AM, Francisco Tolmasky wrote:
When using loadDataRepresentation:(NSData *)data ofType:(NSString
*)aType how can we determine the encoding of the document? (For
example, UTF8 vs ASCII, etc.)?
Take a step back, I think you need a bit more context.
You won't be just sending that message to any old NSDocument instance.
The use of the NSDocument pattern requres the developer to define a
subclass
of NSDocument and absolutely requires that you implement certain key
methods.
Their are other methods which you are recommended to implement, but
which
NSDocument provides default behavior for.
Among the required methods you must provide is
loadDataRepresentation:ofType:
(or provide a related method readFromFile:ofType: or
loadFileWrapperRepresentation:ofType:)
At least 1 of these three will be used to read the data your Object
saved to disk via
How does it know, because it is entirely up to you. The data in the
document
was stored using another method you will write yourself. This may
have been in
your implementation of dataRepresentation: ofType: . The default
implementation
of writeToFile:ofType: calls your custom dataRepresentation:ofType
method
which converts the content of your docement represented by the state
of your
model objects, into an NSData object, which is then saved to disk by
NSData's
writeToFileAtomically.
So, the content of the data can be as complex or as simple as you
choose.
It could be as simple as a chunk of ascii text, or an object hierarchy
encoded via
NSArchiver's archivedDataWithRootObject: to which you might pass the
model
object which implements the state of the document contents.
I would suggest you either read or reread the following:
file:///Developer/Documentation/Cocoa/TasksAndConcepts/
ProgrammingTopics/Documents/index.html
And the Documentation for NSDocument,
For background NSDocumentController, and NSWindowController
would help.
For reading and writing the content, review the Archives and
Serialization Topic and:
NSKeyedArchiver, NSArchiver,NSKeyedUnArchiver, NSUnArchiver
<ReligiousOpinion>
I would strongly suggest you read/skim a large portion of these
document quickly,
possibly a few times. Treat it as you would a trashy Novel, the
Classes are the
people and their methods develop their characters. Try to absorb the
lay
of the land, so you can see how the objects are collaborating and
interacting
to do various tasks. Thes, come back, after a few hours or a day, and
read
smaller amounts more carefully. It really will hep. Now, as you
focus on
a specific problem you will be more likely to recall that some object
is willing
to do that part of the problem for you, and not try too hard.
The most common difficulty with Cocoa (at least in my opinion) is that
there is so
much functionality available, one is tempted to start using it. In
reality, the functionality
is what it is, largely so you don't have to use it!
By overriding a very small bit here, or expressing your object's
willingness to respond
in certain ways there (for instance by implementing a delegate method
or expressing
interest in a particular notification, you can get a great deal done
with very little effort.
The trick to Cocoa, is letting your code express it's interests, and
it's capabilities,
so that the Appkit can do the work for you. As programmers we are too
prone
to the belief in the adage "If you want it done right, do it
yourself". In Cocoa, that's
fighting the AppKit rather then working with it.
Think like a CEO, not like a coder, then delegate, and let the
framework know
you are willing to listen and respond when they ask questions!. Your
application
controller is an executive, the appkit a capable employee. Don't
micromanage.
</ReligiousOpinion>
As you can see nobody can really answer the question about 'how can we
determine the
encoding of the document'. You will write typically write
dataRepresentation: ofType
and loadDataRepresentation: ofType: in parallel. The structure of the
document
is defined by what you put in them. The only generally useful advice
here is that when you
implement a bit of code to save a subset of the data in via
dataRepresentation:ofType:
add a matching bit of code to load that data via
loadDataRepresentation: ofType.
Also remember that using KeyedArchiving, you can operate in smaller
chunks
for both efficiency and increased clarity.
I hope this helped.
Francisco Tolmasky
email@hidden
http://users.adelphia.net/~ftolmasky
_______________________________________________
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.