|
jif wrote:
We can batch-read arrays of property values from _javascript_ for Automation object specifiers referring to a collection of objects, using objects.getProperty()
Object collection in JSA also have a .setProperty(), method but this seems to fail on collections, though it works on individual objects.
Does objs.setProperty() expect some particular argument types that haven't occurred to me.
Nope. You're working on the fundamentally broken assumption that
JXA's Apple event bridge has anything to do with Arrays or
collections, or bears any resemblance to _javascript_ objects,
methods, or behaviors in general. In fact, I'm not even sure where
you got getProperty from, as it's not a documented method, so I
suspect it's a poorly named private method only intended for
internal use by JXA's AE bridge. Not that there's any point in using
it yourself, anyway, since _javascript_ already lets you specify any
object attribute using standard bracket syntax, should you want to
identify an attribute via arbitrary string rather than hardcoded
identifier:
someObject["someProperty"]
someObject["someProperty"] = newValue
(JXA does promptly bugger things up here by also trying to use the
same syntax for constructing by-name element specifiers, though
attribute names take priority, so good luck trying to identify any
element whose name is the same as a dictionary-defined keyword. But
I digress.)
At the moment this looks like a point of sharply asymmetrical functionality - batch setting of properties works in AppleScript, but is appearing to fail in _javascript_.
1. Lots of stuff is missing or broken in JXA: the engineers who
wrote it basically don't understand how either Apple events or
_javascript_ work and choose to ignore those of us who do. If you're
curious, you can find the prototype _javascript_OSA component I sent
them as reference here:
<http://sourceforge.net/projects/appscript/files/>; six-week
hack done in haste, and still worked better than their
"professional" effort. BTW, they borked their Objective-C-AE bridge
in 10.5 and have never done anything about that, so don't hold your
breath for future improvements in JXA either.
2. Don't use private methods, obviously; use the documented APIs:
that's what they're there for. In principle, you should be able to
get and set multiple properties by writing:
someElements.someProperty() // get someProperty of someElements
...
someElements.someProperty = someValue // set someProperty of
someElements ... to someValue
If that breaks, well, you're probably SOOL. (Honestly, AppleScript
may suck as a language, but it's the only officially supported
option that speaks Apple events correctly.) There might or might not
be a `set({to:someValue})` method supported too for situations where
using the `=` operator is disallowed by JS's parser (one of many
problems I pointed out prior to JXA's release), but I'm too lazy to
check right now.
Of course, you probably don't know to write it this way yourself,
because it's completely unlike standard a JS-style object-oriented
reference. In fact it's not OOP at all: because Apple event IPC is
actually Remote Procedure Calls that take simple first-class
*queries* as arguments. The target application evaluates those
queries against a relational graph that represents an idealized View
onto an application's user data (the Apple Event Object Model), then
performs the requested operation on the identified data. Thus the
above examples are actually describing are one-to-one and
one-to-many relationships, *not* _javascript_ object properties and
arrays of objects, or anything else you'd find in the more familiar
OO world.
Not knowing this is not your fault either, because nowhere in the
AppleScript, SB, and JXA documentation does Apple ever bother
explaining to anyone how this technology actually works; indeed,
while AppleScript merely obfuscates it, SB and JXA *intentionally
lie* about it, reinforcing the already rampant misconception that
it's just like OOP. And then they wonder why professional
programmers are so confused, frustrated, and infuriated by it when
it suddenly behaves in ways utterly contrary to their own
(misinformed) mental model.
FWIW, I've stuck a short explanation of the mechanics here:
<http://hhas.bitbucket.org/understanding-apple-events.html>;
not brilliant, but still miles better than anything you'll find on
Apple's site. There's also a page of examples that may give you some
idea how expressive AE queries really are:
<http://hhas.bitbucket.org/examples.html>. Oh, and you might
want to read the following paper by one of the original AS designers
as it provides some valuable insights into what this whole circus is
really about:
<http://www.cs.utexas.edu/~wcook/Drafts/2006/ashopl.pdf>. TBH,
knowing how flawed and inferior to AS they are, I can't recommend
using either JXA or SB for automation work - at least no more than
you're prepared to throw out and rewrite in AS if/when you do run
into its baked-in brokenness - but hey, up to you.
Regards,
has
|