grahambinns.com

B.W. McAdams writes to say:

Just to point out, there's been code on the Django Wiki for nearly a year to do XML-RPC:

http://code.djangoproject.com/wiki/XML-RRC

You're quite right Brendan, there has, and it was this code that originally inspired me to create the django_xmlrpc app that I posted about the other day. Unfortunately I didn't acknowledge this fact at the time, mainly because I was surprised to receive an email from someone wanting to use the code and was rushing to get the Google Code and Launchpad projects for it up-to-date, and for that I apologise (I believe that the code on the Django wiki is in fact yours, so please accept the apology on a personal level, too).

The reason that I created a Django app to for handling of XML-RPC requests even though there was already code available for this purpose, is that I'm a glutton for easy-to-reconfigure code. As such, I added the use of XMLRPC_METHODS for defining XML-RPC-exposed functions.

So thanks, Brendan, for pointing out my omission. If there's anything else you spot that could be changed, don't hesitate to let me know.

(Also, your comment highlighted an issue with my comments-handling system, so thanks for that, too.) 

When I first started thinking about re-writing grahambinns.com in Python using the Django framework, one of the things that I knew I wanted to be able to do was make blog posts (amongst other things) using the MetaWeblog API, which is one of the many zillion XML-RPC blog posting APIs that exist out there in the intartubes.

XML-RPC isn't one of the features that Django supports out-of-the-box for fairly obvious reasons; whilst it's not exactly a niche market it is something that needs to be specifically tailored to the sites that use it, so implementing it would exactly be the first priority for the Django cadre.

Because Python already offers some pretty kick-ass XML-RPC library code in the form of xmlrpclib (Python rocks, by the way), which made it easy to implement a simple XML-RPC server myself, I did. And now you can use it, if you want to.

django_xmlrpc (as I've unimaginatively called it) offers a Django app that allows you to expose your functions through XML-RPC. At present it doesn't support introspection, but that's the next aim for it.

You can find django_xmlrpc, along with instructions about how to use it, at its Google Code site (n.b., I'd like to use Launchpad exclusively for this, but for the time being I'm using Google code until I can get round to setting up a wiki and what have you). If you've got any issues, please report them using either Google Code's bug tracker or (for preference) the project's Launchpad bug tracker.

I'm working on making my MetaWeblog implementation a little more generic; more news on that as and when.

I've just discovered a new game to play with Django: creative slugging. Here's how it works: 

Django's SlugField class provides a means to create a slug field in a database table and allows you to auto-populate an instance based on the contents of another field. In my blog app, I've used the contents of a post's title field to create the slug by default, though I could happily enter any value I liked as long as it was unique for the day of posting.

When auto-population of a SlugField happens in the Django admin interface, the source is turned into a valid slug - all lower case, whitespace replaced with hyphens - using javascript. There's an analogous template filter, slugify , that does the same job.

Interestingly, though, whilst slugify merely removes the whitespace and invalid characters and returns a nicely-hyphenated version of whatever it's given in the first place, a SlugField's auto-population mechanism also replaces common - perhaps unnecessary - words: a, the, it and this all go by the wayside, as do several others.

Which leads me to the game. You'll notice that my post about Dell's agreement with Canonical to offer Ubuntu on its new systems has the slug "dell-offer-ubuntu-its-systems," which as you can see changes the meaning of the headline somewhat. I'm wondering just how creative I can get with this thing.

You know, just for when I'm bored. 

Looks like we're up-and-running. Bon. The DNS propogation took longer than I expected, partly because the update didn't go out until 9:30 GMT, which I'd managed to not notice. Anyway, seems like everything works (for the time being at least), so I'll call it a win.

There are still a couple of tweaks that I need to make, but they're mostly on the back end, so you won't see them. For the most part though, Django handles things admirably, which makes me feel all warm and fuzzy. Doing the development work for this site - and in turn learning how to use Django - has been a lot of fun, so I'm going to keep playing with it; you might find you see a lot more tech-oriented posts on here now as a result.

That's not to say, however, that I'm not still making things up; on the contrary, I'm steeling myself to start on Novel-the-second in the very near future (probably next week or the week after). It's just a case of getting all if my creative ducks in a row (it's the shooting them part that worries me). I've got plenty of ideas and plenty more to come but I can't help feeling that if I don't start now one of two things is going to happen:

1. I'll spend all my time world-building and writing down ideas and not actually write any prose or
2. Someone else will write the story before I do.

And now I need to fiddle with my Python.

[Edit]

Before I forget, props must go to Simon Willison , whose blog introduced me to Django (he co-created it) and whose django_openidconsumer library I used as a replacement my own, less comprehensive OpenID consumer implementation. Many thanks Simon.

Then the transition worked and you're now viewing a post from the all new grahambinns.com. Come have a look around. If you find any bugs, please report them at trac.grahambinns.com/newticket.

Cheers,

Graham