Re: Getting comments as a list... Delimiters???
Re: Getting comments as a list... Delimiters???
- Subject: Re: Getting comments as a list... Delimiters???
- From: email@hidden
- Date: Tue, 7 Aug 2001 22:16:50 -0400
On Tue, 07 Aug 2001 10:23:55 -0400, Robbie Newton <email@hidden>
asked,
>
One problem that we have right now is when
>
a file gets 'lost' in the system or misfiled. Since we can't put the whole
>
project number and component number in the name of each file, if it gets
>
filed under the wrong project folder then it is 'lost'. See what I mean?
>
So...
>
>
I was thinking that if there was a way to add fields to the info box ( + i)
>
for files then we could have a field for the project number and a field for
>
the component number. That would solve the problem because, a file were to
>
get misfiled in that case, all one would have to do is hit ( + i) and view
>
the project number and component number. With that said...
>
>
The idea of finding a way to 'add' fields to the info dialog for files is
>
very far fetched. We not quite comfortable hacking the Mac OS to add some
>
new features. Nor are we at the skill level to design an extension to do it.
>
So... ~ here's the kicker ~
>
>
Using basic database ideology, do you think its possible to write delimited
>
information to the comments field with the intent of being able to retrieve
>
that delimited information to separate fields elsewhere? (or from other
>
scripts)
There are three questions hidden here.
1. Where do you keep the data.
2. How do you access the data. (a script detail problem)
3. What do you do with the data. (a big system design problem)
As to where, there are a couple of possibilities here. You could use the
comment field and structure that data in a way that you could parse out. Then
if you want more complex inforamation, use the comment data as an index to look
up the details in a database. You have the advantage that the key data would
also be readable and modifiable by the user. But, you have the disadvantage
that the data would be readable and modifiable by the user... You are also
limited to a certain number of characters (255, I think), and your
representation and parsing method must be robust for any other use of the
comment field. (For example, web browsers will put the URL a downloaded file
came from in the comment field, so your script can't misbehave if the comment
"
http://www.applescriptsourcebook.com/blah/blah/blah.html"; shows up. So you'll
have to define some structure for your data, like
Project:[Ducky], Component:[53]
And then devise a way to pick the data out of the string. I'd recommend using
RegEx Commands, and match the example above with the pattern
"Project:\\[([^]]*)\\].*Component:\\[([^]*)]\\]"
but you could also use AppleScript's Text Item Delimiters (in which case you'd
want something symmetrical, like
]-[Ducky]-[53]-[
To parse this, set AppleScript's Text Item Delimiters to "]-[", and pick items 2
and 3.
The other big possibility would be to use the resource fork. This approach
would include using resources that are defined for specific purposes, like the
'vers' 1, 'vers' 2, 'STR#' 1, 'STR#' 2, and 'TEXT' 1, or creating your own
resource. First, you should look at the utility VersionEdit, which is an
display and editing tool for the resources I listed above (and a few others that
wouldn't be suitable). It seems like the 'TEXT' 1 resource may be good choice.
Its the "Product Description" field, and is free-form text, up to 32K bytes
(although 480 bytes or less is recommended, for the use of utilities that
display the text as an abstract).
Alternatively, you can just define your own resource, and put whatever you want
into them. If you use your own resource, you can avoid the need to parse out a
string; you just write two resources, or two strings in an 'STR#' resource.
Also, you can write more data in the resource, and perhaps get away from the
need for an external database entirely.
Question 2 is how to access this data in a script. The file's comment you can
access using the scripting addition "Akua Sweets". It has the command "extended
info for" that will give you a record that includes the comment if you use the
option "with desktop comment". Then, to write it, you take that record, change
the comment field, and write it back with "apply catalog info". For example,
set newComment to "Project: Ducky"
choose file returning duckyFile
set fileInfo to extended info for duckyFile with desktop comment
set desktop comment of fileInfo to newComment
apply catalog info fileInfo to duckyFile
Accessing resources is just about as easy. (Perhaps easier, since you don't
have to read them before writing to them.) You do need to pick a four-letter
code that no one else in the universe is using (its best to include wacky
option-key characters). Or, if you think your resource fits into an existing
template (like an 'STR#'), you could use that type and pick a number that no one
in the universe uses (between 128 and 32,767).
For your application, I'd recommend you use an 'STR#' resource. It can hold any
number of strings (I think up to 32K of them; definitely at least 255 of them),
each string up to 255 characters. As an 'STR#', you'll be able to edit the
resource with ResEdit, as well as using it in a script.
If you go with an 'STR#' resource, you can use the "add string list" and
"extract string list" commands from GTQ Library's scripting additions. If you
go with your own resource type, you can use "add resource" and "extract
resource" from the same collection. It gets a little complicated keeping data
types straight when you extract the data, though. The "extract data" command
can return the data as a string, which is good if that's what you put there.
Or, you can ask it to return it "as data", and you will get something of <<class
data>> back. You can then use a "cast" command from Ed Lai's "programmer's
osax" to cast it to the data type you originally had. I did that for a script I
wrote that stamped files with dates. But if you are using more complicated
structures, I think its safer to use the scripting addition "Sigma's Coercions",
which can coerce an arbitrary data type "as data string", which is a string you
can put in the resource. Then when you get it back, you can coerce it back "as
original class" to get the data you originally put in there.
But for your particular application, I'd use an 'STR#' resource, with two
entries, for your project number and component number. I prefer to name the
resource, and access it later by name, which is easy to do with the GTQ Library
additions.
Finally, the big question #3: you have a script snippet that can read and write
the project number and component number onto a file. What system do you build
around them? Here, you have to become the designer. Certainly, you'll want a
droplet that you can drop a file on that you can enter the information for, and
another that will display the data contained in the file. If you want a
Finder-like interface, you'll need to use Facespan or Dialog Director to manage
a Display-Edit-Save window for the a file (otherwise, you stuck with Display
Dialog driven question-and-answer, one parameter at a time. "Choose the project
for this file:" and "Enter the component number for this file:" If you want to
bring in database information, you can use AppleScript to interface with
FileMaker or Valentina (to name two products I've used).
Other uses will depend on how you are already using AppleScript in your
workflow.
I've done something pretty similar to this for attaching project numbers,
scores, date mailed out, and other data to a file in its resource fork. I'll
pack up the scripts and post them on my web site in a few days. (Have to get
some changes made today, to deliver to the customer tomorrow.)
--
Scott Norton Phone: +1-703-299-1656
DTI Associates, Inc. Fax: +1-703-706-0476
2920 South Glebe Road Internet: email@hidden
Arlington, VA 22206-2768 or email@hidden