My very first AJAX application

Finally I lost my virginity in AJAX :) The application I chose as guinea pig is very simple: a financial calculator that I have been rewriting in several languages since 1993 (Clipper, Access, Visual Basic, Excel, Delphi, Java, and Javascript). The version shown in the picture is TurboGears/AJAX.

Of course this specific application fits better as pure Java or Javascript, without remote calculation. The point was to send a XML HTTP request, and receive the answer asynchronously. The "Wait..." message, plus an artificial pause of 1 second at the server side, makes clear that calculation is remote.

Turbogears is proving to be more and more convenient. It was very easy to export the calculation methods in JSON interface, and very easy to call them from Javascript side using Mochikit helper functions.

Of course that asynchronous programming, plus having to deal with two dissimilar languages, makes development inherently more difficult. But you can't avoid that if you are developing for the Web, and TurboGears really helps in this way.

If you are interested in play with this calculator, download the Turbogears project from this tar file or, better yet, the Egg file. Note that this project is for Turbogears 0.9.

Python Eggs are a new format proposed for Python packages, that Turbogears makes use to install itself. When you create a new Turbogears application, egg configurations are put in place, and packaging is just one command away.

Beginning with TurboGears

After trying Zope 3 and finding it too "bureaucratic" for development, I was seeking for a Python Web framework. It seems that one framework will take off now: TurboGears. Before that I was somewhat tempted by Webware (which still is a good option), but TurboGears offers a more verticalized and complete solution (from database access to Javascript/AJAX).

I am still far from doing anything useful with TurboGears, but saw enough to like it. It is simple to understand, easy to install, completely made in Python, does not hide things from the developers and is very Pythonic.

One criticism I have, is that they try to sell the idea the components fit in the MVC object model, being Kid XML templates the View and CherryPy as the Controller. It is true if and only if you put a good amount of Python code inside the XML templates, and I hate to put software "intelligence" in XML.

Zope 3 has a more "correct" implementation of the MVC model for Web software, I have to admit. The whole problem was that all glue code between Model, View and Controller had to lie in ZCML (the Zope 3 XML grammar).

But this TurboGears small problem is something easily fixable in your software project: make Kid + the front-end classes of CherryPy as your View, and the back-end classes of CherryPy being the Controller. The glue code is inside CherryPy, of course being Python, which was all I desired :)