Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AppleScript vs. JavaScript Application Support

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:
http://lists.apple.com/mailman/options/applescript-users/email@hidden
Archives: http://lists.apple.com/archives/applescript-users

This email sent to email@hidden


Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.