I added a BDSKAliasFile object (separate from the BDSKFile object,
but in the same file). It has the problems described below, but
should be doing what we discussed. These are the methods that I think
should be used:
Reading (field -> file object):
-initWithBase64String:
Saving (file object -> field):
-base64StringRelativeToPath:
Adding a file:
-initWithURL:relativeToURL:
-initWithPath:relativeToPath:
Getting properties:
-fileURLRelativeToURL:
-pathRelativeToPath:
One annoying thing: when writing or archiving a BibItem, we need to
replace the fields with the current values. At which point do we
remove those fields, and add them? Also, should BibItem archive these
file objects, or should they be passed just through the fields as
base64String? NSCoding doesn't work for these file objects.
Christiaan
On 18 Oct 2007, at 11:38 PM, Christiaan Hofman wrote:
On 10/18/07, Adam R. Maxwell <[EMAIL PROTECTED]> wrote:
On Thursday, October 18, 2007, at 08:35AM, "Christiaan Hofman"
<[EMAIL PROTECTED]> wrote:
>> Still don't see how to handle new documents.
I forgot about that until after I sent the message. You previously
suggested caching the save-destination URL ivar off in BibDocument,
and I think that would work with a new accessor, as long as we can
override a point that has the real destination.
>OK, the docs say it can use both relative and absolute paths, you
can even
>specify in which order it searches. By default relative first, then
>absolute, then node ID.
Good...I didn't see that. Interesting that Apple's had relative
path-based solutions built in to Carbon for all these years, but
Cocoa mainly requires absolute path/URL.
Well, cocoa also does not support aliases to start with.
>I saw that using FSResolveAlias the alias is automatically
updated. When we
>use (different) relative paths (e.g. for Export) this is unwanted.
So either
>we have to make a copy of the alias, or use FSMatchAlias, which is
a bit
>more work. Perhaps we should not keep a BDAlias but an
AliasHandle, because
>we need to do some custom things (like this) that BDAlias can not
handle.
>Also when there is no file name we may just use an alias without
base path.
>The alias is used basically just for backup, when the FSRef is
invalid or
>null. We may want to update it in some cases though (for a Save
As, or when
>creating a new file object, or when copying items between documents).
>Anyway, I think we just should need a BDSKAliasFile subclass that
contains
>an FSRef and an alias for backup.
Yeah, that's roughly the same conclusion I came to when I woke up
thinking about it this morning :/. I also need to forego all
thought of optimization while we try to get this working! Maybe
even a new (public) class altogether, since the current BDSKFile
wouldn't be able to figure out which class to create? I guess a
new initPersistentFileWithPath: or something might do as well. We
probably don't want to inflict aliases on the orphaned file finder.
--
adam
Another thing, when an item is generated it does not know about its
document (and therefore the base path). So we need to find a way to
handle that. Perhaps the alias should be resolved to an FSRef lazily?
Christiaan
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Bibdesk-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bibdesk-develop
