Get the Facts on Automator

Are Actions only AppleScript-based?
Actually, Automator Actions are Xcode projects and therefore can be created using any language or frameworks supported by the OS. Naturally, that includes AppleScript, but it also includes Cocoa and Carbon frameworks, Objective-C, C++, Java, Shell, Perl, etc., or any combination of these.

How are Actions created?
When you select File >> New Project, in Xcode, you are presented with a list of all of the various types of projects that can be created using Xcode. In Tiger, this list will include new templates: one for creating an Automator action using AppleScript, and one for creating an Automator action using Cocoa.

The AppleScript-based Action template is basically an AppleScript Studio project with a preset UI widget for the Action’s preference pane that appears when the Action is added to Automator’s workflow list. The AppleScript Action project template includes a script containing the “on run” handler that will hold the script code that is executed when the Action is run. The really neat feature of this template is that the buttons, lists, and other items in the UI widget (called a Nib) don’t require any AppleScript code to have their values automatically passed to the Action’s run script. The template uses “Cocoa bindings” to assign each UI element to a parameter whose value is part of an AppleScript record passed to the main script. It’s mostly done through a simple “click and link” process in Interface Builder!

The Cocoa-based Action template uses the standard .m and .h files and structures used by traditional application developers. This template also includes the same UI widget that is used to display any preference options for Actions.

How do scripters and developers take advantage of Automator?
This is an interesting question whose answer really outlines the potential and scope of Automator.

For those scripters who use AppleScript Studio, creating Automator Actions will be nothing new and probably a bit simpler as you’re not creating an entire application but a project containing just the AppleScript code necessary to perform the task. If you haven’t looked at AppleScript Studio before, you should now.

It gets more interesting for traditional application developers. They may view Automator as a way to expand the sales and use of their application by releasing sets of Actions that work with their products. If their applications already have AppleScript support, this will be easy. If they don’t, then it’ll be much harder to use their applications in Automator Workflows. Because of this, Automator can potentially drive adoption of AppleScript by application developers.

Of course, application developers can write Actions in other languages beside AppleScript. They can even break the functionality of their applications into a group of Actions. For example, a smaller developer who has an application that processes gizmos can incorporate the same application code into a group, or “Suite” of Actions for processing gizmos and sell the collection as an alternative to the application.

Either by breaking out the application functionality or by adding AppleScript support to their applications, developers stand to benefit from making their applications work with Automator. After all, it will be on every Tiger-based computer. :>)

Why do I want to take advantage of Automator?
Automator’s easy-to-use interface will certainly drive renewed interest in automation for a variety of users, both professional and consumers. The concept of “scripting for the rest of us” is very appealing and addresses the common problems faced by all computer users. And with Microsoft Office 2004 and the Adobe CS suite of applications all offering considerable AppleScript support, the potential for writing really cool useful AppleScript-based Actions for companies and individuals alike is tremendous.

Is Automator a replacement for AppleScript?
No way. We don’t think so. Automator just gives AppleScript even more reach, depth, and validity. It will make more people recognize the importance of automation. It will drive adoption of AppleScript in applications. It will bring AppleScript to people who never would have used it before. Because they’re so light-weight and portable, AppleScript scripts will continue to be written, shared, and used. Automator just provides another means for scripters to deliver the power of AppleScript.

Apple is supplying more than 100 actions when Automator ships with Tiger. As developers add even more for their own apps, we see Automator maturing very fast. Macscripter will be hosting a completely new section dedicated to Automator Actions very soon, so please stay tuned!

So basically an automator action works like this (?)

You create a NSView that contains all the customization options in IB, using the bindings panel to set values for when it runs. (Advanced Question: what does it bind to? do you create a custom class to hold the values and then connect a NSObjectController to it to do the bindings?) (Question: when you are in automator, is there any of your code running?) After designing the view for use in automator, and setting it up to pass parameters to your code, you write your code. A automator action written in applescript has a tiny bit of glue objective-c code (just like a normal Applescript Studio app) that gets environment and argument values to pass to your script when it’s on run handler is invoked.(?) While the automator action may send apple events to other applications, it’s not required to… it can do any kind of processing. (Advanced Question: because any language can be used, is the information passed to the code as a xml plist on stdin? that would be nice for perl developers… and most other languages… maybe not as nice for Objective-C, unless the template comes with the parser already ready to go)

Question:“Automator action” is the only term I have heard, but there’s kind of four parts… what are the proper names? (A)Automator action the plugin bundle. (B) Automator action the view used in the Automator application. (C) Automator action: your custom code run when the set of configured actions is invoked. (D) Automator action the collection of customized actions saved as a workflow, made accessable in the script menu or elsewhere.

Man, I can’t wait! :smiley:

Dont know if this has been posted yet but