Re: AppleScript vs. JavaScript Application Support
Re: AppleScript vs. JavaScript Application Support
- Subject: Re: AppleScript vs. JavaScript Application Support
- From: has <email@hidden>
- Date: Wed, 20 Jun 2007 23:00:58 +0100
Rick Gordon wrote:
When an application offers a JavaScript interface into its object
model, such as Adobe Bridge or Acrobat (whose AppleScript support
is minimal compared to its JavaScript support), what is going on
under the hood that causes the disconnect?
Are they not both access the same events model?
No. The typical JavaScript interface is patterned after DOM, which is
a simple, straightforward object-oriented model. That tends to map
quite closely to the way an application's business layer (the 'Model'
in MVC) already works, making it straightforward to bridge.
The Apple Event Object Model, on the other hand, is query-based,
requiring an extra layer of logic on top to interpret those queries
and turn them into operations on the Model layer. (Think of Apple
events as a bit like XPath over XML-RPC.)
Are there any workarounds? Is there a serious risk that the future
of AppleScript is impacted by the platform-independent JavaScript
model?
In Cocoa-based applications, you get Cocoa Scripting which provides a
reasonably usable/reliable mechanism for doing most of this work.
OTOH, cross-platform applications tend to use Carbon which requires
developers to do more of the support work themselves. Either way,
getting the interface and implementation (look and feel) 'just right'
is not a trivial task - even Apple, who you'd expect to provide best-
of-breed scriptability in their applications, seem to have problems
with this.
What ammunition do AppleScript proponents have to evangelize for
AppleScript support in existing and future products?
It all comes down to cost vs. benefit. If developers think that the
initial cost of implementing Apple event support will be outweighed
in the longer run by the commercial benefits (increased sales,
customer loyalty, etc.), then they're more likely to provide it. If
not, they'll invest that engineering time on other features that will
provide a better return.
Personally, I'm a bit torn on the issue. With hindsight, it's easy to
see that Apple missed an opportunity with the OS9->X move to simplify
and streamline the Apple Event Object Model, which was deliberately
overengineered to compensate for System 7's dreadfully inefficient
multitasking. In OS X, interprocess communication is a lot more
efficient, reducing the need for such a complex - and tricky to
implement - system. However, it seems to be what we're stuck with.
One thing that would certainly help reduce the pain is better high-
level framework support for non-Cocoa applications, making it easier
for those developers to implement Apple event interfaces in their
applications, but that's something for others more knowledgeable in
that area to discuss.
One significant advantage of providing Apple event and (on Windows)
COM interfaces will be better interoperability between programs. An
embedded interpreter (of any language) tends to live in a world of
its own, whereas providing an IPC interface allows any program or
language that knows how to talk to that interface to communicate with
that application. For example, several scripting/programming
languages already know how to talk to Apple event and/or COM
interfaces, including AS and ObjC (Apple events only), VB (COM only),
Perl, Python, Ruby, and the inevitable C (both). [1] Therefore,
applications that are often used as part of a larger workflow will
benefit from providing an external programming interface instead of
or in addition to an internal one.
HTH
has
[1] e.g. See my sig. for high-level Apple event bridges to Python,
Ruby and ObjC.
--
http://appscript.sourceforge.net
http://rb-appscript.rubyforge.org
http://appscript.sourceforge.net/objc-appscript.html
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden