AppleScript_ The Definitive Guide - Matt Neuburg [226]
So much for how to associate a script with a folder. What about the code that goes into a folder action script? The StandardAdditions scripting addition defines (in the Folder Actions suite ) five events that may be sent to a folder action script:
adding folder items to
Called when an item newly appears in the folder.
removing folder items from
Called when an item in the folder disappears.
opening folder
Called when the folder's window is opened in the Finder.
closing folder window for
Called when the folder's window is closed in the Finder.
moving folder window for
Called when the folder's window is moved or resized in the Finder.
Your folder action script will contain a handler for each event to which you'd like it to respond. (One and the same script can respond to more than one event.) In this example , our folder automatically decodes any .hqx files that are put into it (it is assumed that you've installed StuffIt Expander , which doesn't come with Tiger):
on adding folder items to ff after receiving L
tell application "Finder"
repeat with f in L
set n to name of f
if n ends with ".hqx" then
tell application "StuffIt Expander" to expand f
end if
end repeat
end tell
tell application "System Events"
if process "StuffIt Expander" exists then
tell application "StuffIt Expander" to quit
end if
end tell
end adding folder items to
The script runs when any file is put into that folder, so the first step is to ignore everything except .hqx files. We call StuffIt Expander to decode each appropriate file. This leaves StuffIt Expander running, so at the end we look to see whether StuffIt Expander is running, and if it is, we quit it. A folder with this script attached functions as a kind of magic decoder drop box for .hqx files.
A common error is failing to take account of the fact that the folder action script may do something to an item in the folder such as to trigger the same (or a different) folder action script. This circularity is not a problem as long as it is not vicious. This is one reason why, in the previous script, we test the name of each file; as we expand a file whose name ends in .hqx, we create a new file that triggers the script again, but we ignore it because its name doesn't end in .hqx.
CGI Application
A CGI application (for common gateway interface, if you must know) is a process that supplements a web server. When a request arrives for a page, instead of simply fetching a file on disk, the web server can turn to a CGI application and ask it for the page; the CGI application is expected to compose the entire HTML of the page, including headers, and hand it back to the web server, which sends it on as the reply to the client that made the request.
Before Mac OS X, the communication between a web server and a CGI application was conventionally performed on Mac OS through Apple events. In particular, an Apple event usually known (for historical reasons) as the WebSTAR event is sent by the web server to the CGI application, describing the page request. The CGI application hands back the page as the reply to this Apple event (see http://www.4d.com/products/wsdev/internetspecs.html). This means that an AppleScript applet could be used as a CGI application; such, indeed, was the traditional approach. Terminology for the WebSTAR event is defined in the StandardAdditions scripting addition; it is the handle CGI request event. So in the past, you would write an applet implementing an event handler for handle CGI request, and point your web server at that applet as the CGI application for certain web page requests.
With the coming of Mac OS X, however, all this has changed. Of course if you're still using WebSTAR or some other web server that implements