Good morning! I did some pretty intense work last night on ManilaEnvelope. I still don’t have it up and running (for that matter, I haven’t decided whether the name is all one word or two), but I have some new insights on AppleScript Studio.
First a word about my process. I started with my original TextEdit2Blog script, as recently revised to use external script files containing Manila and SOAP handlers. I built a UI, wired it to a new script that contained TE2B, and started adding responder methods that handled actions from the UI.
The first thing I found was that the mechanism that I had previously used to get the external script files usable inside TE2B wasn’t really necessary–I had brought the handler scripts into my project. Unfortunately, I couldn’t figure out how to access the functions from within the new main script. I made the decision to temporarily collapse everything back into one file while I sorted things out.
Next I found some issues with the new implementation of display dialog. The old implementation was modal, which is great if you’re scripting and less good if you have a fully responsive user interface. Apple appears to have made the decision that a regular “display dialog” command won’t halt the user interface. This was causing all sorts of problems in running the script, since it needs four parameters that were originally being collected by separate dialogs. This was one of the main motivating factors to move away from pure AppleScript toward a more UI intensive solution, so I rolled up my sleeves. Eventually there will be a separate prefs window to collect username, password, and URL, but for now they’re out on the same window.
Separate note: why is it so hard to figure out how to mask the password input in a standard NSTextField using Interface Builder? One would think that’s standard enough that it should be pretty easily accessible.
The rest of the evening was spent getting the code in a more or less legible form. Even in a strange programming environment, refactoring was still the best solution. There are a lot of cleanly structured methods now that I’m going through and changing one at a time as I wire up new bits of the UI and figure out what else has changed in the scripting environment.
So those are the struggles I’ve had. What’s been good? Well, I really really dig dialogs attached to the main window as sheets. I was able to reuse a lot from Apple’s sample applications, including a well defined progress window. And when I was trying to decide how to structure code that was originally written procedurally to respond to a user interface, the tutorials and help were great. Apple’s tutorial script does a reasonably good job of explaining how to implement model-view-controller (MVC) in AppleScript Studio.
MVC in AppleScript? Yeah, that’s the last thing. This isn’t your father’s AppleScript. It’s got a lot of power and despite Apple’s best efforts it’s a mindwrench coming here from simple interapplication scripting. But to me it feels like home.