Re: Property Parent : load script (Changing File)???
Re: Property Parent : load script (Changing File)???
- Subject: Re: Property Parent : load script (Changing File)???
- From: Jason Bourque <email@hidden>
- Date: Wed, 16 Jan 2002 20:00:03 -0500
Thanks everyone, in two lines of code I did what I needed.
property pLib : load script ((path to startup disk as text) &
"Scripts:Default Script Lib")
property parent : LoadScript("", "Handlers Lib", (path to startup disk as
text) & "Scripts:") of pLib
Thanks,
Jason Bourque
On 1/16/02 7:13 AM, "has" <email@hidden> wrote:
>
Jason Bourque wrote:
>
>
> What I would like to happen when I compile a Property Parent is the
>
> following.
>
>
>
> At compiling the property it finds the newest version of a script that
>
> begins with "HandlerLib " in a specified folder ((path to startup disk as
>
> text) & "Script Handlers:").
>
>
>
>
>
> This script itself is a loadable script. A Library of sorts.
>
>
>
> So the script will never run, just contain sub routines.
>
>
>
> So this eliminates the set the value at run time possibility.
>
>
>
>
>
> I thought of using a run script.
>
>
Not necessary. Try this:
>
>
>
on loadParent()
>
--your code to find and return the sub-library here
>
end loadParent
>
>
property parent : loadParent()
>
>
>
I use this sort of thing quite a bit to make properties self-initialise
>
their values at compile time.
>
>
>
>
As far as loading at run-time goes (something I much prefer doing for
>
libraries, as it avoids the need to recompile everything each time you
>
change a single component), there's a number of methods you could use:
>
>
1. You can daisy-chain libraries together and then use a handler call that
>
propagates down that chain, loading a fresh copy of each library into its
>
respective property as it goes. You just load the topmost library into your
>
script, then send it the 'initialise' message.
>
>
2. A similar approach to 1. is to pass a record of libraries down through
>
the call itself, letting the recipients grab the bits they need.
>
>
3. Alternatively, you can load all the libraries into a set of properties
>
within a single script and let them access each other from there. In that
>
situation, you need to add global declarations to the top of each library
>
before they can see one another.
>
>
4. Probably the most exotic approach of all is to wrap your library code in
>
a constructor function. This is a great approach if you want to use the
>
parent property to inherit from another script at runtime. Just load the
>
script and call the constructor function to get a freshly-baked library out
>
at the other end.
>
>
>
How you'd do it would depend on your architecture. Also, if using a
>
chain-loading method, make sure you avoid creating any closed loops in the
>
chain (e.g. A loads B, B loads C, C loads A).
>
>
>
My Big Project of the moment uses all of methods 1 thru 3 (and other
>
projects have used 4), so I know these techniques are all quite usable.
>
Also, I can't get over how much easier my code's gotten to maintain through
>
using multiple small files instead of a single big one - regardless of how
>
modular the code is otherwise. If anything, I think the multi-file approach
>
helps you design good modular code right from the go (makes it harder to
>
throw together messy hacks than write good code to begin with - focusses
>
the mind, y'know - and it pays off in the end).
>
>
>
I'm afraid the above's just a quick summary of techniques, unfortunately -
>
I'm busy on other stuff right at this moment, so further details and
>
working examples might need to wait a bit if the above's not enough to get
>
you rolling. (Hmmm... y'know, sometimes I get these funny notions that I
>
should just go write up a book about this stuff. Maybe that should be The
>
Next Big Project - though d'you think anyone'd buy it?:)
>
>
>
HTH
>
>
has
>
_______________________________________________
>
applescript-users mailing list | email@hidden
>
Help/Unsubscribe/Archives:
>
http://www.lists.apple.com/mailman/listinfo/applescript-users
>
Do not post admin requests to the list. They will be ignored.