On Jul 31, 2008, at 7:25 AM, jda wrote:
ResourceFork is deprecated and scheduled for oblivion, so I'm
looking for another solution to handle the following situation (on a
Mac, of course)
The Resource Fork as you know it is deprecated, but that doesn't mean
that you still can't store resources. I know that you will prefer to
continue with a single file scenario (more comments on that below),
but Apple has dictated that we're to do it the "new" way and that
"new" way is bundles. Look at rtfd, pages, key, etc. files - they're
actually folders containing the necessary bits of information for the
file.
While I don't think that either way is better from a developmental
standpoint, I do find the abuse of inode consumption created by a
bundle hierarchy versus the original multi-fork files to be a bit bold
- disks are huge, gobble 'em up!. I'm sure that Apple has their
reasons, as I'm also sure they'll never share those reasons openly
with the rest of us, and the RS team are only doing what they need to
do to try and catch up with Apple's platform.
I have a series of ancillary text files whose names my app displays
to the user in a listbox. These files contain connection information
that my app uses to access different Internet sites. There is one
function (it doesn't matter what) that can be enabled or disabled,
and I want the user to see that in the listbox display.
My solution has been to add a resource of my own making to each file
that contains text, either "true" or "false". If "true", the name of
the file is displayed in italics in the listbox. If "false" it is
displayed in plain text. So all I need do is check the resource of
each file (there may be many hundreds of them) and then set the text
style of the listbox cell accordingly.
That sounds like a great use for an XML plist file. Why create
multiple files (again, inode consumption) when you can easily
generate, parse and maintain a single XML file that contains all of
this info with the tools RB offers today.
Without the resource fork, I can see only two solutions when I
iterate over each of these files. One is to open each file, read in
the data, determine if the function is enabled or not, close the
file, and then set the listbox. This is clearly a poor solution with
many hundreds of files to examine. The second solution I can think
of is to assign a different extension to the files (e.g. .en for
function enabled, .dis for function disabled, or some such thing),
that my app can examine as it iterates over the file names to
determine if the function is enabled or not. This also strikes me as
kludgey and prone to cause problems.
Basically I would like a way to determine a simple boolean setting
of a file without having to open it and parse its contents. The
ResourceFork was perfect for this. I'd appreciate any thoughts on
the replacements I've come up with, or any I haven't considered.
But, you were opening and parsing the file each time you accessed its
resource fork.
Again, change your layout to place all of your information into a
single XML file and manage it with the tools that RB offers - one
file, easy access, no resource fork deprecation worries.
Tim
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>
|