Q on AppleScript Object Model

Hi,

First of all this is my first post here - it’s a general question and I’m sorry if it is in the wrong place. I’ve already solved several long standing issues by reading posts here - really a great resource!

My Question:
I’m trying to understand AppleScript dictionnaries - I find it is never easy to work out much of practical use from them, probably because I don’t understand the context.

What I really don’t understand is the concept of an “Element”. In the Apple AppleScript reference it says that an Element is an Object inside an Object Class. Ok… And Object Classes also define Properties, which beling to all instances of the Object Class.

If I translate this to a sort of generic OO language (which I suspect is a grave error :slight_smile: ), this would say that Element X extends it’s Parent Object Class - so that all properties of the Object Class belong to the Element, plus whatever is defined or over-ridden by the Element. This is obviously not true for, for example, Mail.app. Here we have a Message OC, with Elements called “Recipient”, “Recipient cc”, “Recipient bcc”, and a property “sender”. In Address Book, “first name” is a Property of “Person”, but “email” is an Element…

Can somebody try to clarify this, or point me at a source which can explain it in general terms ?

thanks!

There are some absurd dictionaries (believe it!), but generally, in a regular dictionary you can find commands (eg, “display dialog”) and classes, which are part of the application/osax object model. You can also find some special stuff for commands, such as “constants”, but this is another question.

In an object-based dictionary, you can allways find a typical structure. Eg, in a text editor:

Document, paragraph, word & character, are elements “owned” by the object “window”, and they work in references:

And each “element” has some properties (if the applescript-implementor decides it):

So, more basically, you can understand the Finder as an application. And there are folders within such application, and files within such folders. So, files & folders are elements of Finder. And those elements have properties (eg, “modification date” or “creator type”).
Or your family is an object which contains a mother and a son. Both mother & son have their own peculiarities: hair color, heigth and so on. Every person in your family is an element, and every element inherits its own properties.

Some times, developers make a bad-design of their applescript dictionaries. Or, some times, an object requires an special treatment. I don’t know Mail, but in Entourage you can find some paradoxes. A “message” has as property a “subject”, “headers” and “time received”. But the “recipient” is an element, since it supports itw own properties, which are the mail address and the recipient type. Really, the “recipient” should be a property, but it is an element. Also, teorically, the “address” is an static property, but it has two components: address & display name.
These are the good news… But you can find also apps out there which define commands as “save”, which won’t work, or references to an element called “document”, which will throw an error if you try to reference it… These are the absolutelly bad designed dictionaries, owned by apps which are NOT really scriptable. Hmmm… Eg, “Adobe Streamline” in classic & “Silhouette” in OS-X.

Some more samples: most of browsers support the event GURLGURL (open url), but Safari doesn’t. You must then open a web page using the property “URL” of the object “document” (which is an element of the object “application Safari”).

set URL of document 1 to "http://www.google.com"

On my mind, this is an example of “bad-design”, until Apple supports a command to handle a GURLGURL event, since the most important command in a browser should be this one!

Thanks for the inputs! I’m beginning to work out the underlying logic and this explanation has helped a lot. I had already noticed that the general quality of Dictionaries was variable… I actually have a fairly complex script which ties iView Media Pro, MacSQL and Fetch to update my website, and I have to say that the inconsistencies between the logic and the syntax between the various dicts really had me tearing my hair out. I guess that finally the AppleScript interface is actually an API which exposes quite a lot of the host application’s inner logic…so some differences are going to exist.[/u]

jj: sorry to say this, but you’re definitely wrong here. Have you ever seen a message with more than one recipient? I sure have. If recipient was a property, what would you do, have it sometimes be a list, and other times be a simple string? That would be really confusing. Also, the recipient should have properties. That’s good design. Now, it would be nice if Entourage ALSO let you just get recipient as a property that just holds the whole text of the TO: field. Perhaps they could name it “recipient raw” or something like that. But, if I had to choose, I’d pick their way. Their way let’s me work with a group of recipients, not have to parse a big string looking for commas that aren’t inside a pair of quotes. Yuck!

Anyway, your overall point is something I heartily agree with: many developers do make horrible choices.

Oh, by the way, Safari does support “open location” which is the new, standard, form of open URL. It’s the same command - you just need to use that syntax. Also, it’s non-browser-specific. You can tell the Finder to “open location SomeURL” and SomeURL will be passed on properly to whatever application is supposed to handle that type of URL (ie. mailto:, http:, ftp:, etc)

One really strong example of bad implementation is in Safari when they added tabs. They didn’t put them in the dictionary. You can only get information about the FRONT tab in a window. The other tabs don’t exist, from AppleScript’s view-point. Tabs should be elements of windows, and documents elements of tabs. OR, you should be able to get document 2 of window 1, and that would get information about the 2nd tab. SOMETHING! Instead, I just don’t use tabs at all. :frowning: I’ve got a background script that saves all my open windows’ URLs so that if I crash, I can open back up all the pages I was waiting to read. Tabs would keep that from working.

True!
Originally, a recipient should be a property, a comma-delimited string, but the implementation of the “address” stuff turned it into an element (ancient Outlook times?)
About “open location”… Safari allways supported this event. Obviously, a browser must support a standard GURLGURL event received from the system, but this is the only browser which does not throw a little bridge to applescript, defining this event in its dictionary and enhacing it slightly (eg, “open whatever in window whatever” or “open whatever in tab whatever”, save to a file or add simple support for POST data)