AppleScript getting better over time?

Greetings, all. I am implementing a document mgmt system and one of final the parts of the strategy is to actually look at the destination folder and confirm the document was moved to the right place before deleting the copy on the originating client. I was planning to do this with a shell script launched out of the database that fires an applescript. However, it occurred to me I could easily run my script with a folder action. I wrote some recently for something else and they are working very consistently.
In the past I had some problems with folder actions and shied away from them for a good long while. In fact, there are many times I think that AppleScript hash’t received the updates it should over time, and now we have Automator, which I don’t particularly like.
The doc mgmt system is a serious system. Here’s my question: Do you think folder actions are more reliable than they were 5 years ago, are they ready for prime time? Has OS X finally gotten to the place where these things can be used in serious database environments? Or is Apple still setting AppleScript to the side, and secretly planning to get rid of it?
What do you folks think?
Thanks, Lenny

Now that was a lot of questions at once.

AppleScript is living, but nothing much have changed with regards to Folder Actions.

On the other, hand, I hear that hazel rules are the stable alternative to Folder Actions, so I’d download a trial copy if I were you. I can’t think of any other way that is fairly simple, yet reliable.

Whilst Folder actions tend to be good enough for most, I’d personally use a launch agent to either run a script periodically to check, or use syslog to do it for you:

Monitoring a Directory
The following example starts the job whenever any of the paths being watched have changed:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.example.watchhostconfig</string>
    <key>ProgramArguments</key>
    <array>
        <string>syslog</string>
        <string>-s</string>
        <string>-l</string>
        <string>notice</string>
        <string>somebody touched /etc/hostconfig</string>
    </array>
    <key>WatchPaths</key>
    <array>
        <string>/etc/hostconfig</string>
    </array>
</dict>
</plist>
An additional file system trigger is the notion of a queue directory. The launchd daemon starts your job whenever the given directories are non-empty, and it keeps your job running as long as those directories are not empty:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.example.mailpush</string>
    <key>ProgramArguments</key>
    <array>
        <string>my_custom_mail_push_tool</string>
    </array>
    <key>QueueDirectories</key>
    <array>
        <string>/var/spool/mymailqdir</string>
    </array>
</dict>
</plist>

Referenced from: https://developer.apple.com/library/mac/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingLaunchdJobs.html

However, I’m not prescribing that you do it this way, just that you have alternatives.

If you want to keep with applescript to do your stuff, running applescript from within your bash script (or referencing you script from the bash script) is simplistic enough

If you need reliability I suggest everyone to use watchpaths as Woggledog example.

I don’t think Apple is setting AppleScript to the side. AppleScript is still the easiest way to send and receive AppleEvents between applications. So the real question would be then: “Will Apple set AppleEvents to the side?”. Well I don’t think so either. AppleEvents is not something that belongs or is directly related to AppleScript anymore. There are many applications that uses AppleEvents without the use of AppleScript because you can send these events yourself in many other programming languages like Python, C and C++ for example. There are mach messages to communicate between processes but sending an AppleEvent is a lot easier.

Well if your thoughts are based on the fact that AppleScript development seems poor compared to the front end I can understand your reasoning. The fact is that the AppleScript community is still small even if the growth of desktop from Apple is huge in the last 15 years. The ratio of AppleScript users and total Apple desktop users has decreased.

Another important reason of slimming down the number of AppleScript users is AppStore. How? Early Apple users will agree that the choice of applications wasn’t very huge, small compared with Windows platform, however almost every application was scriptable. Today we have a store with thousand different applications but only a few are scriptable.

Apple is an company like anyone else who is interested in profits. AppleScript is not directly a profit maker as an selling point while it was an selling point in the '90s. The reality is that Apple will keep only a very small team of developers working on AppleScript and the question is if they can keep up with the other developments. Well it seems they do a good job. The development is maybe “slow” but the focus was the last 8 years more towards merging AppleScript into Objective-C. First they somehow failed with scripting bridge but they succeeded with AppleScriptObjC.framework, a cocoa framework that is capable of connecting AppleScript with Objective-C. Also AppleScript-Studio was very maintaining project that has consumed a lot of time for Xcode 1.5 thru 3.2. That also showed that development of AppleScript is far from standing still.

The developers of AppleScript seems to be continuously busy to make the AppleScript easier to make use of the Cocoa framework so eventually we’re able to use NSAlerts instead of display alert commands from a scripting addition in plain AppleScript code. On the other hand while scripting additions seems to fade away the latest release notes for Mavericks indicates that in nearby future scripting additions will be updated again in it’s security, that indicates that scripting additions will be there for a while.

And, to add to DJ Bazzie Wazzie’s post, don’t forget Shane Stanley’s contribution with ASObjC Runner as a means of bridging the gap between AppleScript and ObjC. As Shane says on the site, the introduction of Libraries in Mavericks has changed the picture:

While I can’t claim to be up to speed on this development, I do use ASObjC Runner all the time.

PS: I use Hazel too, instead of Folder Actions. Well worth the price.

I was quite tired last night. Sorry for the meandering post… with too many questions.

That said, what I quote above was the real issue: “tend to be good enough” ? Is that really the case, or are folder actions really quite stable, at least in Mavericks?

Thanks,

Lenny

Their instability is legend and they are frequent causes of frustration for newbies; perhaps that’s sloppy coding, more so than an innate problem. I would question using folder actions for your intended purpose of document management”there are better, less gimmicky alternatives.

Hello.

I agree with Marc Anthony, I think that the best solution would be if you have a trigger, or post action from your DBM, you can use for ‘postflight’ operations to be the best solution, if that is viable then.

Thanks, to the both of you… well, to everyone who responded, of course. That’s about what I was thinking of. I have created a shell script which launches an applescript. It’s easy to have the database trigger it (as it isn’t a package). Using Helix, and it has some nice doc mgmt functionality… this should be a nice, robust system.

Thanks!

Lenny