Re: Cocoa an Resource Forks
Re: Cocoa an Resource Forks
- Subject: Re: Cocoa an Resource Forks
- From: rsharp <email@hidden>
- Date: Thu, 14 Jun 2001 11:25:10 -0500 (CDT)
On Thu, 14 Jun 2001, David Herren wrote:
>
Why on earth would you want to use resource forks for anything? Resource
>
forks are at best a legacy item that should die die die...
I agree that in moving foward, we should look at other solutions.
In looking at my current carbon apps, I typically store three
types of entities:
(1) Graphics Data
(2) Configuration Data (Carbon 9.x and earlier stuff like 'SIZE',
'BNDL', etc.)
(3) Persistent objects (or at least data from which objects can be
rebuilt)
I think that Cocoa's object persistence schemes and the fact that we now
have bundles does indeed elminitate the need to store such data is a res
fork. Bundles are cool in that you can now have separate graphics files
and not worry that the user will see them or accidentally delete some of
them.
I'm also looking forward to the easier localization abilities. True, you
could have multiple resource files each with a particular locale, but it's
so much better to just include the localizable files into those well-named
folders. The OS will automatically choose the right one to use. Nice!
I can also see using IB to create custom objects that you can then read in
from your nibs. This could potentially replace the case where we used to
create custom TMPL resources for persistent structures.
Speaking of which, is there a way in IB to create say a custom "editor"
for one's object? I guess I'm looking for something like MetroWerk's
Constructor app. It's easy to define an object's field type and an
appropriate editor will be used for that field. e.g. one such field could
be an int that could only have a certain range of values (e.g. month).
It would be cool to open up your object and be able to assign a value via
a popup button.
Rick Sharp
Instant Interactive(tm)