RE: Compact Handlers Togo!
RE: Compact Handlers Togo!
- Subject: RE: Compact Handlers Togo!
- From: "Bourque, Jason" <email@hidden>
- Date: Thu, 16 Aug 2001 11:45:34 -0400
>
Personally, I like putting my handlers into a script server.
>
A script server, for those who are wondering, is a script saved as a
>
stay open application. If there is an asciiSort() handler in the script
>
server then another script can use that handler by telling the script
>
server to asciiSort() just as you would tell any application to do
>
something.
>
Do you have every handler in a library? Is there a problem with file size,
memory allocation for the stay open app?
>
Remember that putting globals into your handlers lets the data inside
>
leak into your script body. Good and Bad. When you have 100 handlers, will
>
you remember the variable names in the first? Forget them at your own
>
peril.
>
Alter them in another handler or in the body and your first handler may
>
misbehave.
>
Good point, I will keep that in mind.
Thanks,
Jason Bourque
AppleScript Developer
Corporate Marketing and Communications
MFS Investment Management
617-954-5312
>
----------
>
From: Paul Skinner
>
Sent: Thursday, August 16, 2001 12:26 AM
>
To: 'email@hidden'
>
Subject: Re: Compact Handlers Togo!
>
>
on 8/15/01 1:53 PM, Bourque, Jason wrote:
>
>
> Hello everyone,
>
>
>
> I have been thinking that the handlers I create aren't that portable.
>
i.e.
>
> Copy the handler. Any properties or globals associated with the handler
>
must
>
> be copied to the top of the script
>
>
Properties must. As you show in your handler, globals can go anywhere.
>
>
> So, I thought including the Properties and Globals in the actual handler
>
> would make it much more portable.
>
>
I don't believe that properties can go in handlers in any way. I get
>
compilation errors if I try to fit them in there.
>
>
> First to treat globals like properties and have the last value of global
>
> keep after a run.
>
>
Right, I remember the discussion on the persistence of Globals. I
>
found
>
this in the ASLG...
>
>>from the ASLG
>
>> Scope of Script Variables and Properties
>
>> If you want the value of a script variable to persist after a script is
>
run,
>
>> or if you wish to use the same identifier in several different places
>
in a
>
>> script, you can declare it as either a script property or a global
>
variable.
>
>> AppleScript keeps track of properties and global variables across
>
multiple
>
>> handlers and script objects within a single script.
>
>
> Below is the script that demonstrates what I have accomplished, but I am
>
> looking for comments about it. i.e. If it is useful and am I
>
understanding
>
> the logic correctly, general comments.
>
>
Personally, I like putting my handlers into a script server.
>
A script server, for those who are wondering, is a script saved as a
>
stay open application. If there is an asciiSort() handler in the script
>
server then another script can use that handler by telling the script
>
server to asciiSort() just as you would tell any application to do
>
something.
>
>
--scriptserver application. Saved as stay open.
>
on beeper()
>
beep 3
>
end beeper
>
>
>
--Handlerless script.
>
tell application "scriptserver"
>
beeper()
>
-->beep,beep,beep
>
end tell
>
>
There are many ways to load handlers into your scripts, some WAY
>
cooler
>
than this one, I won't get into them here.
>
I have a lot of handlers and if I had to put them each into every
>
script
>
they'd be HUGE. I'm talking about disk space here and not the script's
>
text
>
size ( AKA 32k limit in Script Editor. ). In short, when you use 'load
>
script' and compile, a copy of the handler you specified is stored within
>
the script. It doesn't count toward the 32K limit, but it is in the file.
>
If
>
you modify the handler, you must reopen the script and recompile to get
>
the
>
new handler functionality.
>
Some people like to load their libraries into their script. I like the
>
idea of having one instance of every handler that all of my scripts can
>
access. I also like being able to modify a handler and have the new
>
version
>
be instantly used by all of my scripts. Of course, this requires care when
>
modifying them to avoid breaking dependant scripts. I feel like it a lot
>
easier to maintain. With a load script method you'd have to open every
>
script that contained a call to the modified handler and recompile them.
>
>
> Please post all responses to the list, for I am in two locations with
>
> different email.
>
>
Sounds like a portability problem. ; )
>
>
> Thanks,
>
>
Snip! Script.
>
>
> Jason Bourque
>
>
Remember that putting globals into your handlers lets the data inside
>
leak into your script body. Good and Bad. When you have 100 handlers, will
>
you remember the variable names in the first? Forget them at your own
>
peril.
>
Alter them in another handler or in the body and your first handler may
>
misbehave.
>
But it does, as you point out, offer persistent values within the
>
handlers. I can see a lot of uses for that.
>
Personally I try to pass the handler data in the call and get data
>
back
>
in the results without any other communication. If you are trying to build
>
portability into your handlers, it seems like internal globals could be a
>
weak point.
>
I use properties to provide persistent and 'globally available' values
>
to scripts and handlers, but I put them in the script server, they're
>
available to all of the scripts and handlers but they're all declared in
>
one
>
script. This prevents me redeclaring them. The compiler won't allow a
>
property to be declared twice in one script.
>
>
--
>
"AppleScript is digital duct tape."
>
Paul Skinner
>
_______________________________________________
>
applescript-users mailing list
>
email@hidden
>
http://www.lists.apple.com/mailman/listinfo/applescript-users