Re: Nice Automator article on O'Reilly
Re: Nice Automator article on O'Reilly
- Subject: Re: Nice Automator article on O'Reilly
- From: Christopher Nebel <email@hidden>
- Date: Wed, 4 May 2005 15:43:56 -0700
On May 4, 2005, at 12:30 PM, Martin Orpen wrote:
Don't say I didn't warn you in the thread "The future for
AppleScript".
I'd originally written this for the "The future for AppleScript"
thread almost three months ago, but never posted it because it would
probably have devolved into me saying "I can't tell you that until
Tiger ships." Obviously, that's no longer an issue, and Martin still
seems to be stuck on the same point, so here we are...
On Feb 10, 2005, at 3:57 PM, Martin Orpen wrote:
on 10/2/05 8:24 pm, has at email@hidden wrote:
Martin Orpen wrote:
And what do you think the simplest way for an ISV to provide
hooks for
Automator is going to be?
Well, if you've got a choice of two methods and you've written
the app in
whatever-C then I doubt that you're going to bother inserting an
AppleScript
Automator Action when you can see Cocoa Automator Action sitting
below it.
You're confusing 'AppleScript' for 'Apple events'.
I'm not confusing anything - just repeating the two options
available when
you use the Tiger version of Xcode - look at the Automator page on the
developer site to see for yourself.
You know, there are a lot of misunderstandings running around here.
[1] I'm guessing Martin is referring to this bit from <http://
developer.apple.com/macosx/tiger/automator.html>:
There are three general types of Automator Actions that you can
create:
- Actions that control an application to get something done. If the
application is scriptable, AppleScript can be used for these types
of Actions. Objective-C is a good choice if the application has a
public API, such as Address Book and iChat.
- Actions that use system frameworks or other system resources to
get something done. This is typically a job for Objective-C.
- Actions that perform a "bridge" function, such as prompting the
user for input, writing output to disk, or converting data from one
type to another. These types of Actions can be written in either
AppleScript or Objective-C.
So, misconception number one: AppleScript actions imply all
AppleScript all the way down, Objective-C/Cocoa actions imply
Objective-C/Cocoa all the way down. As they say in my country,
"no." There are indeed two basic interfaces to actions: AppleScript
and Objective-C. That is, your action is either going to have an "on
run" handler (AppleScript) or a "-[MyAction
runWithInput:fromAction:error:]" (Objective-C). This does not
dictate (much) what you do once you're inside that handler. If you
start in AppleScript, you could do everything else in a shell script;
if you start in Objective-C, you could start calling C stdlib or
shell calls or even start throwing Apple events around -- whatever
gets the job done. (Obviously, some things are easier in some
languages than others, hence the "much".)
Moving on to misconception number two: it's easier for application
writers to provide an Objective-C API than it is to make their
application scriptable, especially if they're already written in
Cocoa. Again, no. As an application vendor who wants to Play Nice™
with Automator, your task is to expose a programmatic interface to
your application so that the actions can get at the interesting bits.
[2, 3] (Revisiting misconception #1 for a moment, this "programmatic
interface" just has to be callable from at least one of AppleScript
or Objective-C -- it does not have to actually *be* AppleScript or
Objective-C. Python, for instance, would be an unusual but workable
choice.)
So, given full freedom, what do you (the application writer) do?
Well, being lazy, as all good programmers are [4], you want to do as
little as possible. For any reasonably well-designed Cocoa
application, adding scriptability is actually the lowest-cost
solution. Refactoring stuff into a callable framework is usually
hard. Added bonus: if you make your application scriptable, then
other people will write actions for you!
Forget any notion that an Objective-C action implies talking to an
Objective-C (Cocoa) application -- it doesn't. Forget any notion that
an Objective-C/Cocoa application will have an easier time exposing a
pure Objective-C interface -- it won't. (Well, unless it has
already. Omni did. On the other hand, their stuff is all
scriptable, too.)
Oh yes, and the third misconception -- more of a bias, really:
Automator is inherently useless to someone who already knows how to
write scripts. Well, that depends on how much you enjoy writing
scripts by hand. For instance, I'm perfectly capable of writing a
script that will recursively walk a folder tree lower-casing all the
file names. But you know what? I'd rather not bother, especially
when, in under a minute, I can build an Automator workflow that does
the same thing. Added bonus: it's so bloody easy that I don't even
have to bother filing it for the next time I need it.
--Chris Nebel
AppleScript and Automator Engineering
[1] All right, two. Big ones. About Automator. Misconceptions
about M. Welch are not my department.
[2] More importantly, a programmatic interface to the data your
application works on. This is a subtle but important distinction --
consider Address Book. Automating Address Book the application is
not very important; what matters is automating your address book data.
[3] Ideally, you'll write some actions too, so your users don't have
to.
[4] No, really. Larry Wall said so. The other two virtues of great
programmers are impatience and hubris. _______________________________________________
Do not post admin requests to the list. They will be ignored.
Applescript-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden