RE: Snow Leopard osax security and 'run script' with parameters
RE: Snow Leopard osax security and 'run script' with parameters
- Subject: RE: Snow Leopard osax security and 'run script' with parameters
- From: has <email@hidden>
- Date: Fri, 8 Jan 2010 18:01:30 +0000
Scott Babcock wrote:
> In responding to a different thread (Use AS operators dinamically), "has" provided the solution to my parameter-passing dilemma. The 'run script' event is merely used to create a script object on the fly. The code is not actually executed by 'run script', so the Snow Leopard OSAX context restriction doesn't come into play. The new version of the contrived example looks like this: [...]
<sigh>
Build a better shotgun, and the world will stick its feet under your door...
...
To be fair, there are a few situations where dynamic code generation in AS _is_ the best (or only) way to go.
For example, if you're using dynamic code generation to construct large quantities of unit tests for testing your applications' scripting interfaces then I'd say that was an entirely legitimate use as AppleScript's Apple event support is, after all, the de facto reference implementation. None of the other Apple event bridges are 100% quirk-for-quirk compatible with AS's AE support (appscript's closest, but still has some differences), so if you were to use any other language then you do run the risk of false positives/negatives in your tests.
Another legit use case would be if you need to do funky runtime stuff within a script that's running from within an attachable application. In that case, you're pretty much stuck with AS, as it's the only scripting language currently available as a fully featured, fully working OSA component (and the only one that's ever likely to be).
For nearly everything else, you'll be far better off using Python or Ruby, both of which are blessed with an abundance of introspection capabilities and numerous other goodies. As far as adding AE support, I'll not suggest Scripting Bridge as it's prone to compatibility problems with quite a number of apps, including Office ones, but appscript [hem-hem] is quite solid these days and even provides compatibility options for extra gnarly customers like MediaPro. (Incidentally, I seem to recall the MacBU using Python appscript in their automated build processes, so some precedent there.) FWIW, I've spent the last year now doing heavy-duty workflow stuff with Python+PyObjC+appscript, and they're absolute troopers; so much more productive than AS for medium-to-large scale development it isn't funny.
HTH
has
--
Control AppleScriptable applications from Python, Ruby and ObjC:
http://appscript.sourceforge.net
_______________________________________________
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