Re: system events XML suite -- it seems to be caching and holding XML objects
Re: system events XML suite -- it seems to be caching and holding XML objects
- Subject: Re: system events XML suite -- it seems to be caching and holding XML objects
- From: has <email@hidden>
- Date: Sun, 16 Oct 2005 19:36:14 +0100
Steven D. Majewski wrote:
>I stuck the 'make new XML data' in a loop, followed by a 'log text of
>result' .
>Looking at the log, it looks like 'result' get's translated into 'XML
>data "X"' ,
>so it looks like what gets returned by 'make' is not the object, but
>a reference
>by name to the object.
That is how the Apple Event Object Model works. It's not like distributed object systems that supply local objects that act as a transparent proxies to the desired remote objects. Instead, AEOM objects exist solely within the application domain, where they may be identified by simple query objects (what ASers call 'application references') passed as parameters to Apple events. You can send query objects to an application, typically when you want to do something to specific application objects identified by those queries. And the application can send query objects back to you, typically to allow you to locate the new or existing objects that were created or moved in response to your command.
i.e. Manipulating an application's AEOM is all about using query objects; constructing them, sending them, receiving them. It's not too unlike using something like SQL to manipulate the tables in a relational database. Application scripting makes a lot more sense once you realise this, and appreciate all of its implications. It's just about the most important and valuable piece of information ASers can know, yet one of the least well explained, discussed or understood. Go figure.
Now, the 'quality' of returned query objects varies from application to application. In situations where it makes sense, well-designed applications will return queries that are guaranteed to identify the same object or location (depending on which is appropriate) the next time you use them. Not-so-well-designed applications may return queries that are spectacularly vague in what they identify. For example:
- Address Book is very precise: it returns unique by-ID references to group and person objects; they're not very human-readable, but they're guaranteed to locate the same objects the next time you use them (even if those objects move in the meantime).
- Finder gets is reasonably precise: it's impossible to have more than one file or folder in the same location with the same name so it can reliably use by-name references there, although it does fall down with reliably identifying disk objects since it is possible to have more than one disk object with the same name. (Ideally, Finder would return queries that identify disks by ID for reliability, and files and folders by name for readability.)
- TextEdit is sloppy as heck: it returns by-index references to documents, so there's no guarantee that a reference returned by 'make new document' will still point to that same document object later on, even though this is the behaviour that users most commonly want.
System Events' XML suite seems to fall into the semi-reliable category along with Finder's disk elements: perfectly reliable - i.e. doing exactly what you want and expect - until two with the same name come along at once, and then things get... 'interesting'.
>And later:
> get every XML data whose name = "X"
>
>returns:
> {XML data "X", XML data "X", XML data "X", XML data "X", XML
>data "X", XML data "X", XML data "X", XML data "X"}
>
>However, 'get first XML data' and 'get last XML data' seem to return
>the same thing.
Correct, both return a by-name query identifying an XML data element named 'X'. Which is perfectly valid, but it's not the most helpful response because when you send that query back to the application in another command it will invariably identify the first XML data element named 'X', which may or may not be the one you actually wanted. What you really want is for System Events to return a by-ID reference to the XML data element. Consider filing a feature request on it.
You might also file an enhancement request on Apple's Scripting Interface Guidelines, asking that it drum these issues into developers a bit harder than it currently does. It's probably one of the harder judgement calls for developers to make when deciding how their scripting interfaces should act, particularly if they don't regularly do application scripting themselves, and I suspect they could still use a bit more guidance.
HTH
has
--
http://freespace.virgin.net/hamish.sanderson/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Applescript-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden