Re: Javascript for automation quastions
Re: Javascript for automation quastions
- Subject: Re: Javascript for automation quastions
- From: has <email@hidden>
- Date: Thu, 11 Dec 2014 22:59:19 +0000
Deivy Petrescu wrote:
> Some questions that I could not find the answer (plenty more to come).
>
> First, how does one get “me” in JSA ?
The equivalent to AppleScript's special `me` variable is JavaScript's
special `this` variable.
> Example:
>
> set k to path to me
You want either `se.pathTo(null)` or `se.pathTo(this)`.
The first returns the path to the current process (this is equivalent to
`path to current application`, since AppleScript's `current application`
is packed as a typeNull descriptor).
The second returns the path to the script file, if known (it depends on
how the host process loaded the script into the OSA component instance),
or the path to the current process if not.
> Second, “runScript", according to the dictionary it takes text:
> "run script script : the script text (or an alias or file reference
to a script file) to run”
>
> In AppleScript the following works:
>
> In JSX the following does not work
>
> se = Application.currentApplication()
> se.includeStandardAdditions = true
>
> scrpt= "Application('Mail').activate()"
> se.runScript(scrpt)
> Error:"Error on line 6: Error: Expected script but found string.”
Welcome to the brain-damaged incompetence that is JXA. There's one way
to make an Apple event bridge or OSA component work right, and that is
to make it work exactly the same as AppleScript. Which, for reasons
known only to them, the AppleScript team repeatedly refuse to do. As a
result, various operations that work perfectly in AppleScript fail in SB
and JXA, and users have no clue what's gone wrong or why, and often
their only option being to go back to using AppleScript.
In this particular case, JXA is trying to pack your string value as a
descriptor of typeScript, not typeUnicodeText, which is obviously
nonsense. While StandardAdditions' dictionary may claim that `run
script` takes a script object as its direct parameter, that doesn't make
it true: the type information given in app/osax dictionaries is for
documentation purposes only, and is not guaranteed to be either complete
or correct. AppleScript ignores this information. JXA ignores twenty
years of AppleScript, and uses this information in a misguided
workaround for another bad design decision: using strings to represent
class and constant names instead of adding its own JS classes to
represent these types properly.
Needless to say, two wrongs do not make a right, but I guess the AS team
slept through Boolean Logic 101 class because they just keep doing it
anyway. (Scripting Bridge screwed this stuff up as well.)
You can turn off this particular brokenness as follows (though, needless
to say, this means class and constant names will break instead, so won't
work in all cases):
se = Application.currentApplication()
se.includeStandardAdditions = true
se.strictParameterType = false // disable JXA stupidity
scrpt= "Application('Mail').activate()"
se.runScript(scrpt, {in:"JavaScript"})
se.strictParameterType = true // re-enable stupidity
BTW, despite what the StandardAddition dictionary says, it appears the
default language is _always_ AppleScript, so you need to include the
'in' parameter as well.
> However if I try the following works, but it throws an error
>
> se.runScript(Application('Mail').activate())
Well, that example is obviously wrong since you're passing the
`activate` command's return value to `runScript`. While the AppleScript
runtime is able to serialize live script objects, handlers and
properties and all, AFAIK JavaScriptCore doesn't provide any
serialization support beyond the usual JSON stuff. So even if the AS
team knew what they were doing and designed and implemented JXA's OSA
component support 100% correctly, it still wouldn't support _everything_
that AppleScript does. This is the fundamental failing of the whole Open
Scripting Architecture system: it's lousy at supporting any language
that wasn't written from the ground up to support it - in other words,
any language other than AppleScript.
Mind you, given what a crippled, broken mess JXA is, I wonder why they
even bothered. The original plan announced at WWDC13 was for application
developers to embed JavaScriptCore directly into their apps and let it
talk directly to the app's own Cocoa APIs. Which, admittedly, wasn't a
great plan; but given the choice between a mediocre plan executed
competently, and a good plan botched in execution and ignored upon
release, I know which one I'd have gritted teeth and accepted.
...
My recommendation is that folks who already know AppleScript should
stick to AppleScript. As to folks who don't already know AppleScript,
grit your teeth and learn it anyway, because it's the only supported
option that actually works right, and the only one with a user community
capable of helping you when you get stuck (and you _will_ get stuck a lot).
Regards,
has
_______________________________________________
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