The Alagad Technical Team Blog

The Pain And Agony of XML-RPC Blog Publishing

Alagad recently published a new corporate website. A part of this project was the Alagad Team Blog, which I wrote. The blog is nice, but it is written on top of Farcry and thusly, is a pain to add new entries to. (It requires a vast number of clicks before you can publish your new blog entry.) Furthermore, TinyMCE, which Farcry uses as it’s primary editor, is really not the best tool for editing blog entries. All too frequently the HTML comes out a bit wonkey.

So, I decided to implement one of the XML-RPC standards for blog editors. After researching this a bit, I settled on the Metaweblog API which is documented in a few places on the internet. This is where my problems started.

XML-RPC itself has a fairly clear specification. It’s easy enough to implement too (though I wonder why we invented this wheel when we already had Soap). In fact, there are a few XML-RPC implementations for ColdFusion which already exist. Unfortunately, I had a few problems with the XML-RPC components and tags that I found and they didn’t seem to work 100% of the time. That forced me to write my own solution (which is attached to this blog entry below).

My Implementation is simply a CFC that accepts another CFC via a property and automatically translates XML-RPC requests to method calls on the component when the handleXmlRpc method is called. There’s a lot of flexibility in how this is handled.

Here’s an example of how I used this:

This is a CFM file that essentially creates the xmlRpc CFC, and the component which I want to access remotely. The remote component is passed into the xmlRpc component property and then the handleXmlRpc() method is called. This method translates the XML-RPC request into a method name and arguments. Using custom metadata the correct remote method on the remote component is identified and invoked.

Also, rather than using a CFM, you could easily add this code into your remote CFC’s pseudo constructor:

The problem here is that the ColdFusion debugger doesn’t seem to be able to properly debug this use case and it’s show itself to be easier to simply use a CFM.

No matter which technique you use, here’s an example remote method:

Take note that a custom property, rpcName, is specified and that the access is set to remote. The xmlRpc CFC matches the rpcName and confirms that the method is remote before invoking it.

Anything that the method returns is translated back into an XML-RPC response and retuned to the calling application. This works most of the time, but is subject to some problems related to data type translation. Seeing as ColdFusion is loosely typed it’s hard to tell if “1234” is an integer or a string and you can’t turn a component instance into XML (or at least I did not).

Once I had a way to invoke remote methods on a CFC via XML-RPC and could return values, I started to implement the Metaweblog API. And, like I mentioned, the API is helpfully documented in several places. The problem, however, is that every place documents it differently. That is to say, the documents each specify deferent requirements and it has been quite hard to create a meaningful implementation of the standard.

The other problem is that the Metaweblog API builds on the Blogger API and I never did find a clear and complete document describing the Metaweblog API. (Not to mention that most of the documents that I did find were only partially comprehensible).

My strategy in completing the implementation was multifaceted. I ran ColdFusion from the command line so I could watch output and errors. I also made extensive use of the ColdFusion 8 debugger. I watched the Apache access and error logs. I also invoked methods on the CFC with various blog editors and watched the various results to determine the exact methods being called and the data being passed in. I then looked up the documentation for the methods and did my best to implement the functions correctly.

It was my hope that I could use Contribute CS3 to edit my blog. I liked the idea of being able to see my styles and designs as I edited entries, and Contribute seemed like a natural fit. The thing is, and it pains me to say this, Contribute really doesn’t work well with blogs (nor anything else, as much as I wish it did).

When you setup a new blog, Contribute will create a bogus entry with placeholder text which it will subsequently publish, download from your blog, use to make a Dreamweaver template, and then delete. This is an awesome concept, but it fails to deliver. The problem is that the Dreamweaver engine simply can’t handle complex layouts. The spacing was all off, all sorts of scripts were showing in funny locations, it stripped out chunks of my site, and more. I mean, it looked really bad. Not so bad I couldn’t live with it, but so bad it annoyed me.

The killer, however, was that contribute didn’t import the CSS styles defined for my blog. I couldn’t use my .code css class to style code, much less any other classes to style anything. They simply didn’t show up in the list of styles. This list only showed header styles and paragraph. Nothing more, nothing less. What’s odd about this is that if you edit a website with Contribute all the styles show up in the list.

I read the documentation (almost all of it, buy the way) and all it said about this was that administrator had disabled styles. I’m the administrator and I did not! Much less, you can’t “administrate” blogs in Contribute!

So, from here I tried a plethora of other editors, all of which, for lack of a better term, suck. I tried Qumana, which exposed a bug in my xmlRpc CFC. Specifically, I didn’t implement a part of the spec that allowed programmers to be lazy (if a value is a string you don’t need to use the <string /> tag). Once that was fixed, subsequent tests of Qumana would hang after getting a list of blog entries. It was a dead end.

ScribeFire, a plugin for Firefox, is terrible. It doesn’t even add paragraph breaks (or line breaks) when you hit enter. Not to mention that ScribeFire looks like a bit of a hack job. Also, it couldn’t insert code blocks at all.

MarsEdit is not a wysiwyg editor (to my annoyance), but it was simple and straightforward. The only problem with it is that it didn’t encode HTML correctly in its XML-RPC requests, resulting in invalid XML. Useless.

I even fired up Microsoft’s Live Writer in VMWare. This was also a pain because Live Writer pretends to try to import your blog styles, but it doesn’t really. It creates a temporary entry like DreamWeaver, then proceeds to request your home page 9 times before deleting the entry.

Instead, you have to create a static HTML file with “macros” in it that look like this: {post-title} and {post-body}. Once you specify the location of this file in a separate XML file Live Writer works like a charm. That is, if you don’t want to insert blocks of code or Flash files or anything that’s not uber-Microsoft-technology. (I wonder why?!)

So, right now I have about 90% of the Metaweblog API implemented, but I can’t find an editor that isn’t a useless pile of bits (especially on OS X). I’m starting to wondering why I’m going to all this trouble.

Does anyone know of an blog editor that both works and is useful?

16 responses to “The Pain And Agony of XML-RPC Blog Publishing”

Leave a Reply