Scripting a Cocoa app
Scripting a Cocoa app
- Subject: Scripting a Cocoa app
- From: email@hidden
- Date: Tue, 19 Mar 2002 15:17:53 -0800
Howdy, folks. I've spent the past half-day wading through the doc on
scripting support in Cocoa, as well as the Sketch example. Most of it
makes sense, but I'm left with a few questions that I'm hoping I can get
answered. I'm not experienced with AppleScript -- I read a book on it a
little while ago (AppleScript in a Nutshell, horrible book BTW, really
needs a good editor to go over the whole thing), and wrote a few very
short Finder scripts to automate my disk image making process somewhat,
but there are many things about AppleScript I don't "get". So forgive
any foolishness, please.
The big thing I don't get is what types of information I can return to
AppleScript, and how those types get coerced into things AppleScript
understands. Sketch, for example, defines attributes like xPosition and
fillColor that it defines to be NSNumber and NSColor, respectively.
AppleScript, presumably, doesn't know about NSNumber and NSColor, so
they must be getting coerced by somebody (right?). I didn't find
anything about who does that, though, or what types are and are not
supported. Can I have an attribute that is an NSImage? What about an
NSData? The Finder lets you set the frame of a window using a {x, y, w,
h} syntax; how would I make an attribute in Cocoa that worked the same
way? Sketch's attribute are, unfortunately, very vanilla and don't do
much to elucidate this question.
Another thing I don't get is the distinction between attributes and
to-one relationships. What governs one's decision regarding whether a
given property should be an attribute or a to-one relationship? Are
there efficiency concerns here? Are there things which are only
supported by one or the other that drive the decision? Or is this
largely an aesthetic choice, based on whether the property "feels" like
an innate attribute of the object versus a separate object? The doc
seemed to emphasize this distinction, while never spelling out why the
distinction existed in the first place.
Another thing I don't get is subclassing of NSApplication in
scripting. Sketch, for example, defines an object "NSApplication" that
is a subclass of "NSCoreSuite.NSApplication". Does this effectively
hide the "NSCoreSuite.NSApplication" class for scripters of Sketch, or
will both be visible, or how does this work? Furthermore, Sketch
defines an attribute "orderedDocuments" for "NSApplication", but doesn't
implement it; it appears to inherit it from NSApplication. Why is this
necessary? It's an NSDocument-based app; shouldn't this facility be
handled automatically by Cocoa? If not, why do no other inherited
document-related things need to be defined in Sketch's suite? I notice
orderedDocuments is missing from the terminology file; is its
terminology inherited from the core suite, even though it itself is not?
How does the application script object "work", anyhow? How is it
designated as the top-level object that scripts talk to? Can one define
other top-level objects in the same way, or is there always just the one
"application" object, and other things are accessed via that object's
relationships? What if I want my top-level object not to be an
"application" object at all -- can I do that?
Thanks for any help you can give a poor newbie scripter. A pointer to
a scriptable app with source that has more complex attributes and
relationships than Sketch would be very welcome. I didn't find anything
relevant on cocoadevcentral or stepwise, but if I just missed it, please
let me know!
Ben Haller
Stick Software
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.