Re: Cocoa an Resource Forks
Re: Cocoa an Resource Forks
- Subject: Re: Cocoa an Resource Forks
- From: email@hidden
- Date: Fri, 15 Jun 2001 12:43:47 -0400
resources are a nice concept, It shouldn't be used to store your data as
a document producer, but it can be used to enhance the document in many
way.
A bit like categories are used in Objective-C to enhance an already
compiled class.
- Finder could (and it does I believe) use resources to enhance
documents by adding custom icons, extra comments, etc.
I am sure we can all think of one way a specific document can be
viewed/treated in a slightly different way by an other application that
would require to add new information to it ... and resources are just
great for that. In the same way ObjC Categories are great to add
features not originally designed by the creator of a class.
We should take this opportunity to realize that our beloved Cocoa API is
biased against UFS.
When we ask for file with a path name, we also unfortunately include the
extension most of the time.
When we are dealing with extension, what we really mean is dealing with
the type of the file. UFS would look for the extension, HFS would look
for the type.
The word extension itself, does mean an extra value attached to the
name. It doesn't have to be that way on all file system.
The api should abstract us from the file system specifics. The carbon
API is (probably) biased against resources (pure guess here, I never
actually looked at the carbon API).
Both api should reflect a way to access the content of a file, the name,
the type, the location, the permission. This could all be abstracted as
a dictionary-like object, where you ask for the right key:
typeOfTheFile = [aDocumentObject typeString]
-(NSString*)typeString could be implemented on UFS to always return the
extension, and on HFS to try our best as the current OS-X is doing.
This api should be at the file system level (available in Darwin), and
mapped in Cocoa and Carbon.
For too long, the api we used to build our application and our complete
operating system was implementation specific (if UFS, then the api deal
with path and extension and unix-like security, if something else, then
the api is ... something else). We should rethink all this and abstract
the concept of a file in a refreshed api.
NB: As a user, I hate that I don't have easy access to change the type
of a file (or any of it's attributes) because the tool I use to navigate
through my file (Finder) only allow me to change the name of the file.
In that exact case, I do prefer the type of the file to be part of the
name as an extension so I can see it and can change it quickly and
easily.
can we vote for a new filesystem api ?
- jfv
On Thursday, June 14, 2001, at 12:25 PM, rsharp wrote:
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)
_______________________________________________
cocoa-dev mailing list
email@hidden
http://www.lists.apple.com/mailman/listinfo/cocoa-dev