On 29 Jan 2008, at 2:53 AM, James Harrison wrote: > On Jan 28, 2008, at 5:38 PM, Christiaan Hofman wrote: > >> So in templates you should most often use something like >> [EMAIL PROTECTED] or [EMAIL PROTECTED] >> instead of $urls.Local-Url.path, samilar for the URL. Also >> $fields.URL, and $URL, was probably never a good choice, as it may >> contain latex stuff. The first linked file (or URL) should be the >> most relevant one. > > Thanks very much for the useful overview. I've done a bit more > experimentation and I'd like to check a couple of additional things-- > > We're trying to use a template to generate a phrase like: > > "Available at <remote url>, last accessed on <date last accessed>." > > ...which will provide the url and last accessed date for electronic > resources and web pages based on the files that are linked from the > references in BibDesk. The assumption is that most users will wish to > maintain a remote url to the source of electronically-available > references, which should yield the remote url for the phrase above, > but they may also have urls to other locations as well as local files > linked to the same reference. > > It appears that I should use <$remoteURL> to access remote urls, and > the built-in template editor provides <$remoteURL.absoluteString/> as > the appropriate tag/modifier for a url for a web page. That yields a > url when used in a template with a test web page reference. I tried > the form <[EMAIL PROTECTED]> and also the same > tag without the absoluteString modifier, with test references that had > one or more than one linked web site. None of the tags that contained > "@firstObject" yielded any text when used in a template. >
No, not $remoteURL but $remoteURLs (it's a collection), $remoteURL is deprecated, as is $localURL and $localUrlPath. The template editor is not completely updated yet. In fact it cannot deal with collections like local files and remote URLs, you can only do that by hand. For a type that contains a URL field you can use $urls.Url, which used to be equivalent to $remoteURL (but isn't anymore). Again: there are URL fields (mostly deprecated) and the new linked objects. They are not the same. Anything starting with $fields and $urls refers to the (URL) fields, never the linked objects. To refer to the linked objects you should use the $localFiles and $remoteURLs *collection* keys. The deprecated keys $localFileURL and $remoteURL now refer to the first linked file or URL, but that's only done for compatibility of old templates. You should not use them in new templates. They may be removed in the future. > When more than one url is linked, <$remoteURL.absoluteString/> yields > the url associated with the first thumbnail in the details window; > rearranging the thumbnails changes which url is returned by > $remoteURL. > > So it seems that I should use $remoteURL and let folks know that the > page that should be used as the remote URL needs to be kept at the > front of the thumbnails on the details window. People can maintain the > lastchecked field with the date the url was last reviewed separately > and manually. > No, see above. > Just an observation--the order of the main display of thumbnails does > not reflect the order of the thumbnails in the details window, and > there is no visual feedback of the important role of the first url > either in the main or the details displays. Since electronic links in > references are likely to increase in importance, some thought in this > area might be a good idea. > > Jim Harrison > UVa They are ordered according to publication, type, and alphabetically (in that order). Christiaan ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Bibdesk-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bibdesk-users
