Re: Adobe's lousy AppleScript implementations
Re: Adobe's lousy AppleScript implementations
- Subject: Re: Adobe's lousy AppleScript implementations
- From: has <email@hidden>
- Date: Sun, 29 Sep 2002 12:11:58 +0100
Michael Sullivan wrote:
>
[much good stuff snipped]
>
>
The key thing has doesn't tell you, which is necessary to use this
>
approach,
(Please note: any problems had with my demonstration are due to entirely
different reasons...:p [1])
>
is that you want to keep most of these wrapper classes for
>
your application's problem children in a stayopen applet script that
>
runs on startup.
You _can_ do it this way if you wish, but you certainly _don't_ have to.
It's not "key". It's not even directly related to the problem at hand.
<aside>
My example binds that module to the scripts which use it at compile-time,
which should be fine as long as you don't mind the larger file sizes, or
recompiling the individual scripts whenever the app module changes
[Smile/SD users can automate this task if they find it too tedious]. This
seems a reasonable balance for the given problem, but more importantly to
the discussion is also by far the simplest to describe [hence least likely
to distract from the important stuff].
If a more dynamic system is preferred, your script server approach is one,
while dynamically loading the module is another. But I don't want to get
sidetracked into that here.
</aside>
...
>
Put your monolithic script with a pile of complex handlers and script
>
object wrappers in such a file,
[...]
>
tell application "Macintosh HD:Applications:MyScriptServer"
>
tell acrobatObject
>
resizeFrontWindow(windowRect)
>
end tell
>
end tell
First comment here:
The whole point of the system I described is that there are no 'complex'
handlers. This was the OP's problem: for each window-related task he was
trying to perform, his routine was one big conditional block, with lots of
little 'tell app "foo" to do it this way', 'tell app "bar" to do it
slightly differently', etc. blocks. The use [or not] of a script server,
though a useful addendum, is not directly related to the problem I was
solving.
Second comment here:
Your resizeFrontWindow() example would suggest it's doing the very thing I
explained how to avoid: it's tightly coupling your window-munging code
[jog, resize, etc] to your app-specific code ['bounds of
document/window/pdf window'], reducing flexibility and reuse, and
increasing overall system complexity. Which is to miss the whole point,
sorry.
The app-specific code should be as small, simple and *generic* as possible,
otherwise it ends up overspecialised - which takes us back to the same
situation we had to begin with. Thus, it should - no, *must* - be the
*absolute bare minimum* necessary to hide the object model implementation
differences between Acrobat, FrameMaker, et al under a common, standard
interface, and not one word more. *All* the higher level semantics like
FrontWindow, BackWindow, Resize, Move, Tile, etc. are kept in the
*app-independent* code: that way you only have to write that stuff *once*,
rather than for every application.
-------
The magic word that's the solution in all this is "abstraction" [see
<
http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?query=abstraction> for
definition]; essentially, the "longer", indirect ["But I don't see the
point of it..."] path actually turns out to be the shorter route to solving
anything beyond the simplest of problems. Unfortunately, we see folk trying
to solve non-simple problems with skills and techniques that just don't
scale to the task. When you've grown used to the one way of thinking, it
can be hard to approach a problem from any other angle. But when the idea
clicks and the lights come on... everything changes. [2]
Remember, there is no spoon. ;)
has
[1] In getting my example code to work, please note there _was_ one big
stonking SNAFU in it. The newDefaultApplicationObj() constructor code was
deeply broken; I copied and pasted from an older, rougher draft, but, being
half-asleep by then, forgot to fix the method names and object references
along the way. Here's the corrected version, sorry for any inconvenience
caused:
======================================================================
on newDefaultApplicationObj(applicationObj)
script
property parent : applicationObj
on getWindowBounds(windowID)
set {wLeft, wTop, wRight, wBottom} to bounds of window
[NO-BREAK]windowID
return {wLeft, wTop, wRight, wBottom}
end getWindowBounds
on setWindowBounds(windowID, wLeft, wTop, wRight, wBottom)
set bounds of window windowID to {wLeft, wTop, wRight,
[NO-BREAK]wBottom}
return
end setWindowBounds
end script
end newDefaultApplicationObj
======================================================================
[2] BTW, I'm reading this at the moment:
<
http://www.mip.sdu.dk/~mik/papers/oo-languages.pdf>, which talks of the
difficulty in transitioning practised procedural programmers-thinkers to
OOD/OOP, and how to solve it (basically, by starting with OO in the first
place). Good stuff, makes a lot of sense.
--
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.