Re: Adobe's lousy AppleScript implementations
Re: Adobe's lousy AppleScript implementations
- Subject: Re: Adobe's lousy AppleScript implementations
- From: has <email@hidden>
- Date: Fri, 27 Sep 2002 15:44:27 +0100
David Crowe wrote:
[list of inconsistencies in object names/models]
Yeah, it can be pretty depressing when different applications decide to do
things just a little differently to everyone else, particularly if there
doesn't seem to be a significant advantage in this to offset the obvious
cost.
[big long if-then block with lots of different 'tell application' blocks in it]
>
Any hints as to how to simplify this would be appreciated.
I'm not sure the basic problem can be simplified any: different
applications need talked to in different ways. You could, however, change
the way you construct such scripts if this sort of thing is becoming hard
to cope with.
Here's one alternative approach you might try:
1. You can structure your code so that all the application-neutral stuff is
kept in one place, and all the application-specific bits are kept in
another. Next, subdivide the application-specific stuff, wrapping all the
bits relating to an individual app into its own little package.
2. Once you've divided everything down like this, the next step is to
define yourself a standard "lingua franca" which the application-neutral
code can use to talk to _any_ one of the application-specific packages.
3. For example, app-neutral code might say getTopDocumentBounds() to an
app-specific package - it doesn't matter which one - and the package will
_always_ return a value in the form {top, bottom, left, right}. Your
app-neutral code is then able to do whatever it is that it wants to do with
that data.
4. Once your app-neutral code is done futzing around, it can send another
message to the app-specific package saying setTopDocumentBounds(top,
bottom, left, right), and the package wiil _always_ performing the action
of setting the document's bounds, though the exact details of how it does
that is entirely up to it.
Once you've established a common set of rules by which the app-neutral code
can speak to an app-specific package and ask it to do certain tasks, the
only other thing to design is the bit that picks out an app-specific
package for the app-neutral code to talk to. And this bit is pretty easy:
you could use an if-then block, or you could iterate across a list
containing the different packages until it finds the desired one.
--
So what's the practical upshot of all this then? More initial design work
required, for one. More lines of code to type, for another. Bigger initial
overheads, in other words. Not sounding too good so far, eh? But the
benefits of reorganising your code this way will become apparent if this
sort of problem is a regular occurrence.
For example, let's say that as well a having routine for moving windows,
you want another routine that can resize them. Using your original
strategy, well, you'll probably just write another routine similar to the
first, only changing the window-moving bits into window-resizing bits
instead. So now your script is twice as long. Now do the math, assuming you
want to perform 4 different window-related operations. Now add a couple of
operations that perform another set of tasks in each app, given that once
again the application-specific code is a little different each time.
You'll quickly end up with a huge, very ugly and hard to maintain script.
Worse, five minutes later, the boss will roll in and say "Great! Now can we
add support for applications WibblerPro and FubblerMax too?" With any luck,
you'll be elegible for parole in another 6-10 years.
...
Now consider this under the system I've suggested:
- You tell your system which application it'll be working with today, and
it goes and sets up the relevant app-specific package ready to talk to.
- We've already covered what's required to get the first function, window
moving, up and running. It's a fair bit of work just to perform a single
task; but wait and see what happens next...
- To create your window resizer routine, you only need to write the code
which fetches the new window size values. Once you've got that data, you
can send it to the app-specific package via a setTopDocumentBounds()
message with one more line of code. Same thing to add your other window
munging routines [assuming that they also use the same gTDB()/sTDB() calls,
of course].
- In adding your new behaviours, it's the same idea: you gather up all the
bits that change from app to app, and distribute them across your
app-specific packages, each time ensuring that, at the end of the day,
*each package presents an identical interface* for the main system to use.
Assuming that there's more app-neutral code than app-specific stuff, you'll
soon start to see the savings, both in terms of complexity and, quite
possibly, in raw lines of code as well (for those who worry excessively
about such things). There's other perks when it comes to testing and
debugging, and future expansion, but it's this idea of splitting the
problem areas into small, simple, freely interchangeable components that
hide individual inconsistencies from the rest of the system that's the
important bit.
--
Okay, that's probably enough information to be mulling over at this point.
I've deliberately avoided going into more detail, throwing in lots of fancy
terminology, or showing actual code samples, because I figure it'll be
easier to see if the *main principles* make sense before trying to explain
the actual mechanics. So if this makes sense, let me know and I'll see
about posting the next bit; if not, tell me where I've lost you and I'll
see if I can address that.
HTH
has
--
http://www.barple.pwp.blueyonder.co.uk -- The Little Page of AppleScripts
_______________________________________________
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.