[apologies for slow reply; been out of town a few days]
Graham Jones wrote:
> > 1. Put any properties containing shared state into a library of their own.
>
>What does this do? How is it an advantage?
Neatness. It's easy to share that library between all the other libraries that require access to those variables, and it's less stuff to be floating around your app's main namespace.
> > 3. Have your main script pass to each library a reference to each of the other
>> libraries it uses. The library should bind each of those references to a
>> property in itself. Now when one library needs to refer to another, it just
>> refers to the appropriate property.
>
>A little lost here, but I think this is where my program is suffering. I
>gather from the last poster that one key to my problem is that when I load a
>script file into a property I'm just getting a copy of it, not a reference
>to the actual script (I had thought I was).
A 'load script' command will read a script file and create a new script object from that data. e.g. If you call it twice, you'll get two initially identical objects, not one, so changes made to one will not affect the other. The solution is to load each script only once, and share them throughout your entire program.
Example: let's say your application has two libraries, both used by your main script. In addition, library 1 uses library 2, and you want library 1 to use the same copy of library 2 as is used by the main script.
------- library 1 -------
property _lib2 : missing value
on __init__(lib2)
-- initialise this library
set _lib2 to lib2
end __init__
on doSomething()
...
_lib2's doSomethingElse() -- call a handler in library 2
...
end doSomething
---------------------
------- library 2 -------
on doSomethingElse()
...
end doSomethingElse
---------------------
------- main script -------
property _lib1 : load script (alias "path:to:library 1")
property _lib2 : load script (alias "path:to:library 2")
on __init__() -- call this handler from your 'will finish launching' handler
-- initialise all your libraries here
_lib1's __init__(_lib2)
end __init__
...
---------------------
Now your main script has direct access to both library 1 and library 2, and library 1 has direct access to library 2.
Obviously, since this only works for scripts you load and distribute yourself, it won't help in situations where your GUI is sending events to multiple scripts and you decide those scripts also need to communicate with one another. (The only solutions to that are kludges like using a hidden GUI widget or application prefs as the go-between, or restructuring your app so that all GUI code is in a single main script.) But it will solve your ills where you need to modularise other code for one reason or another.
> > If you want, you could use AppleMods Loader system...
>
>I really want to stay away from my app being dependent on 3rd party stuff in
>other locations on the user's drive if at all possible. If I can do it
>without this, I would much prefer it.
If you bind your libraries at compile-time, not run-time, you only need Loader installed on your development machine. Simple example here:
http://freespace.virgin.net/hamish.sanderson/MVCExampleProject.sit
Even if you don't actually use it, it's worth taking a look at AppleMods just to get an idea of how you can do non-trivial modular construction in AS; as well as the Loader system itself, some of the libraries come with examples of use, including a couple with complete working applets (e.g. HTMLTemplate). I figured out a lot of things in designing and writing Loader, and since I never finished writing a book on all the theory stuff and how to apply it in AS, studying the AM documentation and code is probably the next best thing. :)
>I wish I had known about the file size limit at the beginning! I read the
>ASStudio documentation from cover to cover, and there was so little info on
>splitting into multiple scripts...
Most folks don't get to the point where they hit AppleScript's built-in limits, and those that do can often solve their problems just by structuring their code better (e.g. using loops and handlers instead of lots of repetitive cut-n-paste). Unfortunately there's not much on how to use libraries and modular construction because AppleScript, unlike other languages, doesn't have a formal framework for this stuff; and besides, it falls more into 'real programming' techniques which is not something that any AS documentation ever really goes into. (e.g. I learned all this stuff from reading high school textbooks and general advice books like Code Complete.)
HTH
has
--
http://freespace.virgin.net/hamish.sanderson/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Applescript-studio mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/applescript-studio/email@hidden
This email sent to email@hidden
