Category: Scripting

A note about department names

I’m still working on the issue, but it looks like if you name your News Item departments with spaces in them that you can get errors from AppleScript when parsing the resulting XML output from sitePrefs.get (“newsitem.departments”). I don’t know whether AppleScript isn’t parsing the XML correctly, or whether Manila is outputing malformed XML, but consider this a word to the wise.
more…

On the importance of modeling Manila

I did the preceding UML (Unified Modeling Language) sequence diagram with a little tool called ObjectPlant. It’s a shareware UML tool that just became my new best friend. There are times when you have to stop and draw what you’re doing in a project, even a moderately complex project like this one. I’ll be posting some more pictures like the one below as my version of the “Busy Developer’s Guide to ManilaRPC” that Daniel put together.
more…

It’s not work, just fun

I’m playing around a bit more with Radio UserLand. It’s going to take some patience to make it work, as I really want to get it to point at this site and not at my Radio Weblog. Meanwhile I’ve decided how to move forward on Manila Envelope, which was felled right before launch with an impossible problem with the preferences. I’m going to have to write my own code to write and read an XML preference file. Should be fun. Dig we must…

Unexpected snag

I’m going to have to delay the release of Manila Envelope. When I used it yesterday morning it was working, and now the preferences have broken. This, I guess, is a danger of using someone else’s code without fully understanding it. I’ll have to do some digging through Cocoa to figure out what’s going on.

In the meantime, I’m hitting the road after a great night’s sleep at my in-laws in New Jersey. Next post will be from Washington, DC.

Thanks and keep the feedback coming

I kind of paused this morning after I wrote the last entry. I’m surprised looking back at it that I’m still working on these scripts. I mentioned the first script I was going to write in July, half joking, in an email to Dave when Apple announced they were going to be baking in SOAP support in 10.1. I wrote the script when I got 10.1 more as a proof of concept than anything else. It works reasonably well. Why am I going forward?

Well, I never had the time to learn all the stuff I wanted to know to program in Cocoa, for one thing, and this is a quick way to learn Interface Builder and some of the other tools in the free Dev Tools IDE. There have been other features that I’ve wanted to add to my existing scripts–it bugs me, for instance, that you type your password in plain text in a dialog box, and that there’s no interface for clearing your stored information.

But mainly I’ve had feedback from a number of people who have convinced me that this stuff is worth investing time in. One, the server guy at a major state university, wanted help in getting his faculty to use the web for knowledge management. (I still haven’t added his feature. Soon, hopefully.) A few scripters have thanked me for the effort I had put in because they use the tool every day.

It’s great to know people are out there reading and blogging. If you find my tools useful and you have suggestions for how to improve them, or just want to drop me a line, please do. My mailbox is open, and as soon as this last paper’s done I’m going back to do some more scripting.

AppleScript Studio vs. old AppleScript, take 1

I’m digging deeper into AppleScript studio this morning. It’s really starting to blow my mind. The basic concept is simple: take the power of Cocoa applications, object oriented applications that can tap all the built in frameworks to add lots of power to your application, and build an application on top of them — specifying the actions to be executed using the English like syntax of AppleScript. This is so much more powerful than just providing GUI for AppleScript. It’s like getting PowerBuilder, my old programming language, dropped into my lap all over again.

I’m going through the tutorial now and am noting differences between “old-school” AppleScript under Mac OS X and the new AppleScript Studio. Some starters:

  • You write AppleScript Studio applications in Project Builder and do the user interface in Interface Builder. This gives you access to a lot of features, like…
  • …a built in debugger!
  • It looks like it’s now up to the developer to make source for AppleScript Studio applications available as a separate file. Under old AppleScript, you could distribute an AppleScript “application” that was doubleclickable but could also be opened by Script Editor if the recipient wanted to see how you did something.
  • A small point: the “display dialog” command now creates a window that has a proper title bar.

Over the next few days I’ll be going through this stuff in more detail (while I’m writing my last paper of the semester) and will post my findings.

Good software makes up for a lot

E-Lab is done, except for our final presentation to the company we consulted to. Kickin’ back with some software. The new developer tools are out, and I’m a playin’.

AppleScript Studio. I love it. Mac OS X, an IDE free in every box (or at least downloadable). From the documentation distributed with the dev tools:

AppleScript Studio combines an application framework with a development environment, allowing you to provide sophisticated user interfaces for applications that execute AppleScript scripts. AppleScript Studio comprises features from AppleScript, Project Builder, Interface Builder, and the Cocoa application framework. With AppleScript Studio, you can quickly create native Mac OS X applications that support the Aqua user interface.

AppleScript Studio requires Mac OS X version 10.1.2, or the December 2001 Developer Tools CD.

Script update

New script update today. I made a minor change to one of my supporting scripts, SOAPXMLRPCHandler, that should improve the ability of scripts calling it to return successfully when talking to slow websites. If you are using any of my *2Manila or *2Blog scripts, you’ll want to download this performance fix.

Oops

Sorry for the multiple postings. I’ve got to make some adjustments to my script–it keeps reporting timeouts when it’s actually completed sending the message.

Oops

Interesting issue. When I paste text from an email, it comes in with line breaks — which are ignored in the HTML and end up running words together. Got to do something about that–maybe a new scripting challenge. After I finish my exam today, of course.

Lucky

So as evidenced by the previous news item, I’m pretty lucky as a programmer. I hadn’t bothered testing iTunes2Manila with a streaming audio source as the current item before, and I wasn’t sure it would work. Not sure why it doesn’t have a closing quotation mark, but at least the script doesn’t crash.

Scripting Manila and iTunes

New scripts today. First, a version of the iTunes script I wrote a few days ago that posts the currently playing item directly to a Manila website as a news item. Second, some modules that contain functions for making SOAP calls and calling Manila RPC interfaces.

As a programmer, I was big into reuse of code through object orientation. It bugged me for a long time that I couldn’t figure out how to make that work in AppleScript. Today I’ve got one version working. It’s not very clean, because it requires a lot of drag and drop installation, but it’s getting there. The other good thing is that it will cut down on the amount of pain in writing and deploying these scripts because it separates a lot of the Manila “glue” code from the parts of the scripts that actually do things.

All the scripts can be downloaded from my scripts page.

One note about iTunes2Manila–if your site is hosted on editthispage.com like mine is, you may get some timeout messages. I’m still playing with avoiding these, but (as you can tell from my home page), just because you get a timeout doesn’t mean that the news item didn’t get posted.