Re: Attachability
Re: Attachability
- Subject: Re: Attachability
- From: Cal <email@hidden>
- Date: Tue, 6 Feb 2001 12:00:30 -0500
Peter Fine <email@hidden> wrote:
>> There are other sources on the Web, but this is the Apple one:
<http://developer.apple.com/dev/techsupport/develop/bysubject/iac.html>
In addition to the articles by Cal Simone, read:
Programming for Flexibility: The Open Scripting Architecture, 18 develop
26(June 1994)
> I have looked at the online docs but they seem aimed at
developers rather than
> scripters.
- To make an application scriptable, you have to be a programmer
(probably one who works on that application).
- To support QuickTime in an application, you have to be a programmer
(probably one who works on that application).
- To make an application attachable, you have to be a programmer
(probably one who works on that application).
See a pattern here? Basically, to implement any OS or Toolbox
service, you have to be a programmer.
I know that, but you can glean some useful information. The "Programming for
Flexibility" article has some paragraphs in (more or less) plain English
which helped me.
I've also played around a little with SD, Smile and Style but find
their documentation of attachability too brief and cryptic to
provide much of
a basis for experimentation.
That's the truth. If you find anything, please post.
Chapters 8 and 9 of the ASLG are relevant, but also too brief and cryptic
IMHO. Trial and error (lots of error!), especially with inheritance and
delegation, is the only way I've made any progress.
Those who know (e.g., Mark Alldritt, Emmanuel Levy, Jon Pugh, Cal Simone,
Richard23) either can't or won't discuss this stuff in language a mere
scripter could understand. In Cal's case, I believe he doesn't think it's
worth the effort, on the basis it's much too complicated and not very
useful. With the others, I've come to the conclusion they've internalized
OOP and can't see things from the perspective of those of us who have not.
User interface issues are not covered in the aforementioned articles,
which provide information on how application developers can provide
the capabilities associated with attached and embedded scripts. The
information is intended for developers because so few developers
implemented this and, without developers providing such capabilities,
you (the scripter) don't have access to them.
From the sound of it, Stephen Bryant (the original poster), asked for
information on techniques and uses for attaching scripts. To start
we'll need to know what Stephen means by "attachable".
I glanced at my column "Attaching and Embedding Scripts" from Develop
Issue 26. One thing that might be helpful for users is the
definitions of attaching and embedding. To wit:
"- An attached script is a compiled script or script application
that's associated with a menu item in an application; the script is
executed when the user chooses that command. This type of script
usually resides in a particular place, such as a Scripts folder.
Script attachment can be implemented quickly and, at its most basic
level, doesn't require your application to be scriptable."
For attachable applications, it's simple; drop your script in the
folder where the application expects those scripts to be (often a
Scripts folder in the application's folder). Usually they appear in
a Scripts menu in the menu bar. There are dozens of applications
that deal with this.
"- An embedded script is a compiled script that's associated with an
interface element belonging to an application or with a document. The
script can be stored with the application's data, often in a special
file known to the application, or embedded within the data for a
document file."
This gets more cloudy. Developers can implement this sort of thing
in their user interface in _any_ way they want (clicking a button can
run a script, dropping something in a container, there's a variety of
possibilities). In the Issue 26 column, I avoided discussing user
interface considerations for applications that run embedded scripts
-- that's a matter for the developer of the application to determine.
There are only a handful of applications that implement this, most
notably HyperCard and FaceSpan. To conclude, it's up to the
publisher of such an application to provide information on how to
work with embedded scripts, and what sorts of uses.
[Extra geek topic: There's a third level, tinkerability, where an
application allows a scripter to write a script that overrides the
functionality of the application's implemention of that verb, so that
users and solutions providers can change the behavior of an
application. Only two or three applications (Smile, SD, and possibly
one other application) are tinkerable. If you really know what
you're doing, and you keep your overrides to yourself, then it can be
cool...but unleashing this on the user community at large would be a
potential support nightmare -- I don't want to start another fire on
this here, because it has been discussed over and over and over since
1993. (Just imagine if FileMaker supported this; customers would be
calling Filemaker Inc to say that closing a window no longer works --
because a solutions provider or database consultant dropped in script
that overrided the "close" event forgetting to pass through close
message to Filemaker so the window would actually close. This is one
case where too much openness in an application's architecture can
cause significantly negative impacts for companies that aren't in
fact causing the problem. So, way back then, once Apple realized the
implications, Apple stopped encouraging that developers make apps
tinkerable, though the technology still works.)]
I hope this is helpful.
Cal