ZopeX3 learning from others.

As I said in a previous post, the documentation for ZopeX3 is much better than what came with Zope 1. I found the programmers tutorial a very good starting point. Also some googling found this on-going series of blog entries creating a Todo. Nothing like learning about something by example.

Zope Deja vu

It's 1999, I have downloaded Zope 1, and I managed to create a simple website that gets it's data using SQLMethods from a database. I had to learn a new markup language called dtml to get my dynamic webpages. It has no session management but not an issue at the time. To enhance it's functionality I need to create a product, that's were it starts to get hard. The documentation is minimal. But I stick with it, and six years later Zope 2 is still the Web Application Framework at work.

It's today, I have downloaded ZopeX3, and I managed to create a simple website that gets it's data using SQLMethods from a database. I had to learn a new markup language called zcml to get my dynamic webpages. It has no session management but not an issue at the time. To enhance it's functionality I need to create a product, that's were it starts to get hard.

The documentation is much better, but I seem to spend more time editting xml than actually writing code in the python. At least the coding seems more like normal python programming, and the use of components, interfaces, adaptors and testing looks promising and maybe Zope will once again lead the way as the Python Web Application Framework. The bigger question for me is, should we be considering it as a replacement for Zope 2 at work or wait and have a look in another 3 months. Or maybe we should look at Five, the Zope 3 in Zope 2 project. Just like I did with Zope 1, I will stick with it and keep playing, and hopefully it will deliver like Zope 1 and 2 did.

Python and Beer, it must be a Python Meetup Group

Last thursday was the bi-monthly Sydney Python Meetup. Excellent beer, interesting talks and people. Thanks for organising the meeting Alan.

What's all the excitement about XMLHttpRequest

The buzz on many blogs is Google's use of XMLHttpRequest to allow the browser to do requests of the backend without a page refresh. To the best of my knowledge XMLHttpRequest or similar functionality has been part of javascript support in IE and Mozilla for a couple of years. We have been using it for an application at work for the last 20 months to make XMLRPC calls to dynamically update the browser and a SVG view. The biggest issue in the past is getting it to work across browsers, and rather than writing javascript with lots of "if (browser == 'X')" code I would recommend taking at look at the joslait javascript library. As well as providing a set of routines which allow XMLHttpRequest functionality on many browser versions and a XMLRPC client, it has a number of other useful routines.

WSGI Wiki Application

For my WSGI talk at the Sydney Python Meetup I decided that showing a simple "hello world" or echo WSGI application would not hammer home why WSGI is so good. So I decided to create a WSGI wiki app. Also to show what is needed to convert an existing Python CGI script I decided to base it on Ian Bicking's CGI wiki in the Web Framework Shootout. So after about 80 minutes work this is what I came up with and was able to run under isapi_wsgi. It still needs some final touches but it works.

import cgi, os
import cgitb; cgitb.enable()
import Wiki


# There's several different actions that may occur -- we
# may just display the page, we may edit it, save the edits
# that were submitted, or show a preview.  We define each of
# these as a function:

def printPage(page):
    pp = []
    if not page.exists():
        pp.append("This page does not yet exist.  Create it:")
        pp.append(printEdit(page))
    else:
        pp.append(page.html)
        pp.append('<hr noshade>')
        pp.append('<a href="%s?edit=yes">Edit this page</a>'               % page.name)
    return "".join(pp)

def printEdit(page, text=None):
    # The text argument is used in previews -- you want the
    # textarea to be loaded with the same text they submitted.
    pe = []
    if text is None:
        # This isn't a preview, so we get the page's text.
        text = page.text
    pe.append('<h1>Edit %s</h1>' % page.title)
    pe.append('<form action="%s" method="POST">' % page.name)
    pe.append('<textarea name="text" rows=10 cols=50 style="width: 90%%">'           '%s</textarea><br>' % cgi.escape(text))
    pe.append('<input type="submit" name="save" value="Save">')
    pe.append('<input type="submit" name="preview" value="Preview">')
    pe.append('</form>')
    return "".join(pe)

def printSave(page, form):
    ps = []
    page.text = form['text'].value
    ps.append(printPage(page))
    return "".join(ps)

def printPreview(page, form):
    ps = []
    ps.append('<h1>Preview %s</h1>' % page.title)
    ps.append(page.preview(form['text'].value))
    ps.append('<hr noshade>')
    ps.append(printEdit(page, form['text'].value))
    return "".join(ps)

def application(environ, start_response):
    # PATH_INFO contains the portion of the URL that comes after
    # script name.  For all actions, this is the page we are using.
    pagename = environ['PATH_INFO'][1:]
    if len(pagename) == 0:
        pagename = "frontpage"
    page = Wiki.WikiPage(pagename)
    form = cgi.FieldStorage(fp=environ['wsgi.input'],environ=environ)
    start_response('200 OK', [('Content-type','text/html')])
    response = []
    response.append("<html><head><title>%s</title>" % page.title)
    response.append(page.css)
    response.append("</head><body>")
    # Here we use fields to determine what action we should take:
    # edit, save, preview, or display
    if form.has_key('edit'):
        response.append(printEdit(page))
    elif form.has_key('save'):
        response.append(printSave(page, form))
    elif form.has_key('preview'):
        response.append(printPreview(page, form))
    else:
        response.append("<h1>%s</h1>" % page.title)
        response.append(printPage(page))
    response.append("</body></html>")
    return response

dotNet client testing of python web services

As I said in a previous post I have been testing .NET client calls of our financial app web services. I found a good "free" tool called WebServiceStudio that allows quick and easy interactive testing of web services. Our web services use the Python ZSI web service package and this seems to work fine with dotNET clients, as long as you keep the parameter and return types simple. Otherwise you will spend alot of time handcrafting WSDL and for that you need a good WSDL editor.

As if I haven't learnt enough programming languages..

As much as I enjoy programming in Python and feel it is the closet fit for how my brain works, I still have the need to checkout other languages.

After listening to Dr Chris Wright at OSDC last year, I made a mental note to checkout Scheme and also learn about continuations. After finding some tutorials on the web, I started playing with PyScheme It was great for trying out simple examples and made me interested enough for something to try out more complex things. I found Dr Scheme which is an interactive, integrated, graphical programming environment for the Scheme, MzScheme, and MrEd programming languages. It is multi-platform running on Windows (95 and up), Mac OS X, and Unix/X. It has great interactive syntax checking which is very helpful when debugging complex scheme code. There is even talk of a plug-in that will allow you to use the tool to program in Python called PLT Spy

At work I needed to check that some web services for our financial app worked when called from .NET As we currently only support RPC style, writing WS clients in C# is not much fun. I really needed an agile programming language. I could have used PythonNet but really wanted to try out a CLI language. As IronPython seems to be going nowhere, I decided to try out Boo Since some of the syntax is based on Python, I feel at home using it. And based on one days use, it makes working in .NET fun.