Search this site

[prev]  Page 2 of 2





xmlrpc javascript library and pimp rewrite

Yet Another Rewrite of Pimp, my music jukebox software, has commenced. This time, I'm writing it in Python. This was the best excuse I could find to learn python. I've tinkered with it before but never written an application in it.

Anyway, the interface has moved from telnet-based to web-based and uses XMLHTTPRequest (AJAX) to perform XMLRPC calls on the purely-python webserver. Python provides a wonderful standard module called 'xmlrpclib' to marshall/unmarshall XMLRPC requests and responses to/from python and XML. JavaScript, howver, lacks these marshalling features.

Some quick googling found jsolait and vcXMLRPC. Both of these are huge frameworks and are well beyond my particular needs. BOTH of them have "the suck" and fail to cleanly load into Firefox without warnings. Bah! Back at square-one. I'm left without a way to marshall xmlrpc requests and responses between javascript and xml

I spent some time learning about XMLRPC. Turns out it's a very very simple xml-based protocol for calling methods and getting results. JavaScript has DOM already so parsing XMLRPC messages is very easy.

Take a look at the 'rpcparam2hash' and 'hash2rpcparam' functions in pimp.js and see how I convert between JavaScript hashes (dictionaries) and XMLRPC messages. If I get bored I may create my own xmlrpc library specifically for making xmlrpc calls with javascript. If you want this to get done, please let me know and give me encouragement ;)

xml, xslt, and kioskweb!

I put some more work into my kiosk interface today. I made the keyboard widget highly pluggable, such that you can drop one anywhere on a page. The particular place I wanted to try this first was on the Drink machine login page.


If you do a 'view source' on that page, you'll see that it looks somewhat like html, but there's this little widget tag that you shouldn't recognize. An xslt sheet turns that tag into something more useful - Look in your dom inspector for the actual result. This shows you how I'm somewhat planning on building this web-based kiosk interfacing system.

The end result will be that you can write your pages in psuedo XHTML and drop in fully featured widgets with simple tags like the widget tag. I currently support two forms of input (xml-wise) - those are XHTML with slight modifications and something I came up with that's less html-oriented. An example of this can be seen in this directory: projects/kioskweb/demo/xml

The entire interface is in xml, any html pages you may load are actually static html pages generated from xml. If you want to take a look at my xslt sheet, then click here. Opera 8 does not appear to support doing xslt client-side, so if you are using opera the pages won't render properly if at all.

This project is going to be all over xml/xslt like a donkey on a waffle.

web-based kiosk user interface

Dropping Wendy off at the airport earlier this week reminded me to work on the kiosk interface project I've wanted to work on. I started it today, it uses XML, XSLT, and JavaScript. The current implementation is pretty crappy, but visually it gives you an idea of how things might work.

To be frank, it looks like Any Other Webpage and doesn't appear to have anything special about it, but the cool part comes soon, I guess.

See it:

Kiosk web interface, website design, et al.

For the past several years I've more or less ignored the existance of HTML 4, CSS, and JavaScript. My web design has centered around a fluent knowledge of html tables and little else. My new website design is much more in tune with today's web technology. Hopefully, assuming I can get off my butt and do it, I'll be writing a few articles in the coming weeks about things I've learned and whatnot.

I started a new project today to try and do a kiosk interface completely via a web browser. I'll post a link to it when I've actually finished up work on it. It uses XML, JavaScript, DOM, and fun with CSS. I've already found a "feature" of Opera that's making me want to switch to back to using firefox for the devices this interface will run on, but I haven't decided yet.

I may just end up writing something that uses the mozilla rendering engine and nothing else, but that's probably more work put into this than I want to spend. More on things as they develop...