Re: Script objects 'as string' in an identifiable way
Re: Script objects 'as string' in an identifiable way
- Subject: Re: Script objects 'as string' in an identifiable way
- From: email@hidden
- Date: Thu, 8 Nov 2001 20:32:05 -0500
On Thu, 8 Nov 2001 11:14:25 +0000, has <email@hidden> asked,
>
>2. You can pass script objects between applications, but its pretty slow. I
>
>have one script server which I call in a block that looks like this:
>
>
Slower than calling handlers in a script server? Or is either method
>
equally slow?
Fundamentally, asking a script server for a script object is an interapplication
handler call, and so is slow. What I was doing was to ask for a script object
(which was one interapplication handler call), and then asked the script object
to do a bunch of things (which were local handler calls). If I asked the server
to do each of those things, each request would be an interapplication handler
call, and so slow.
When calling script servers, its important to realize that these calls are slow.
An interapplication handler call takes 10 milliseconds. A call to a Scripting
Addition takes only 1 millisecond. And a call to a script's own handler takes
10 microseconds.
>
I guess if you're using them much, the best thing would be to load the
>
object into a variable in your own script and access it there. I'd use the
>
parent property for this, only the value's persistent and there's no way to
>
'refresh' it by doing 'set parent to load script "foo:bar". (The recent
>
'import' debate didn't come up with any simple solution either.:/)
In the particular situation I had, the script server had a bunch of
configuration information, which changed slowly, and was called by a bunch of
small scripts that were called by ListSTAR in response to different types of
e-mail and on different timers. Each small script would ask the script server
for an object that did the job needed, would do that job using the script
object. It was faster than loading the object from disk with a run time "load
script" statement, and easier to manage configuration that a compile-time "load
script". It also allowed me to change the script server, and change the
underlying configuration of the system, without having to shut down and restart
every other component, and without inconsistent data during a transition. The
script server acted as a gatekeeper and mediator, but without doing everything
itself. Essentially, the script server empowered the little scripts to do their
jobs. The server didn't do the job, it just gave the little scripts the code
and the information needed to do the job.
But actually, I didn't do things this way just for efficiency. I did it so the
code would be easier to read, while not being too inefficient and not being too
labor intensive to deploy.
I had started with a loadable library:
property HotFolders: load script ...
-- lists are generated based on incoming e-mail (code not shown)
tell (HotFolder for "Proposal") of HotFolders
pick of winnerList
reject of loserList from "Topic 01-42"
end tell
(Some minimal background on the application. An e-mail List Server is managing
the distribution, evaluation and selection for funding of research proposals.
This script would handle an e-mail from the evaluation panel chair, selecting a
list of proposals that would be approved for funding and a list that wouldn't.
Those actions involve moving the files around, stamping them with new status,
and sending messages to other people. So I defined an object I called a
HotFolder, which would know how to do these things. Then I created a number of
these objects, each one holding proposals at one stage in their life cycle. I
stored those in a list, and produced a handler that allow a script to ask for an
individual folder by name.)
That approach worked great, until I changed the script library. Then I had to
shut down the list server, recompile all the little scripts, and restart
everything. Also, each little script had, embedded in it by the 'load script'
command, the whole library, of which it used maybe half the code and only one of
the multiple script objects. So, I made the script server a separate
application, and dynamically got the objects needed.
That made the call look like this:
tell (HotFolder for "Proposal") of application "Hot Folders"
pick of winnerList from "Topic 01-42"
reject of loserList from "Topic 01-42"
end tell
If I wanted to do it entirely with a server, without passing objects around, it
would look more like this:
tell application "server"
pick of winnerList from "Topic 01-42" out of "Proposal"
reject of loserList from "Topic 01-42" out of "Proposal"
end tell
All verbs, no objects, which is the real reason I don't like it. Every call to
the server has to provide the full context the verb, so it has to say which
folder. I prefer the hierarchical approach. Its like preferring,
tell file "Foo" of disk "Bar" of application "Finder"
set label index 1
set name to "Baz"
end tell
over
tell application "Finder"
set label index of file "Foo" of disk "Bar" to 1
set name of file "Foo" of disk "Bar" to "Baz"
end tell
The object approach also reduces the number of Apple Events between sent between
applications, but that's secondary.
--
Scott Norton Phone: +1-703-299-1656
DTI Associates, Inc. Fax: +1-703-706-0476
2920 South Glebe Road Internet: email@hidden
Arlington, VA 22206-2768 or email@hidden