Re: How best to archive in CSV format
Re: How best to archive in CSV format
- Subject: Re: How best to archive in CSV format
- From: Denis Stanton <email@hidden>
- Date: Wed, 18 May 2005 07:31:12 +1200
Hi Louis
Thanks a lot. This really answers my question. I have already gone
down this path, modifying dataRepresentationOfType: and
loadDataRepresentation:ofType:.
I was thinking that I could do something nicer using NSCoder
subclasses, but the problem is NSArchiver wants to put out a lot of
additional information about the object graph and all I want in the
file is the simple text contents of the end nodes of that graph. I'm
not going to be writing a generalised csv export tool at this stage as
this is really just a proof-of-concept program at this stage. The
concept being "that task that the accounts department hates would be so
much easier if you gave them this little program - and a Mac to run it
on"
Thanks for a really detailed answer, right on target.
Denis
On May 17, 2005, at 6:49 PM, Louis C. Sacha wrote:
Hello...
No, you probably wouldn't want to implement this in terms of an
NSCoder subclass or pattern. It might be possible, but it would make
things significantly more complicated than they need to be. NSCoder is
designed from a perspective of allowing each object to determine the
best way to encode itself, and allows an object to store it's data in
an arbitrary manner. If you attempted to implement CSV using NSCoder,
your goal would be the exact opposite: you would need to make each
object conform to a particular way of being encoded.
A more applicable pattern would be to add your own methods to the
relevant NS-base classes using categories and create your own separate
archiving and unarchiving process, similar to the methods NSArray and
NSDictionary objects have to read and write themselves in XML.
Writing code to work for a variety of abstract cases is more difficult
than writing code to handle a specific case (and it's not trivial to
do it right). To start with, the best option is probably just to
implement the code within your document subclass, based on the
particular model you are using.
Essentially, in your document class implementation of
dataRepresentationOfType: and loadDataRepresentation:ofType:, instead
of using a flavor of NSArchiver, you would use your own code to read
and write CSV. Since you know the model you are using to feed the
tableview, you only need to worry about the objects that your model
uses or allows and implement the code to read and write your model as
the CSV format you've been provided requires.
You'll still need to work out all the "interesting" details of reading
and writing CSV, but you don't need to try to make it fit within the
existing NSCoder archiving mechanism.
Hope that helps,
Louis
That's not the part that worries me. My question whether I should be
writing this CSV conversion stuff inside the standard methods
encodeWithCoder and initWithCoder, and if so how. It seems the
Cocoa architecture has a well-thoughtout mechanism for archiving and
I should try and work within it. My problem is the example I have
produces a binary coded disk file and I need csv text. I want to
make the Cocoa archive mechanism work with csv.
I know that there are traps in this as one of my data columns could
contain commas, so I need to worry about quotes, but for the present
task I do have to conform to csv because I am going to propose this
Cocoa application as a replacement for an existing web-browser based
data entry program and it's important to show that it can simply
replace the older program with out requiring anybody else to change.
Denis
Denis Stanton
Orcon Internet Limited
(09) 480 9299
http://www.orcon.net.nz
_______________________________________________
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