Uwe’s weblog

I’ve been building a simple app to test rdf and XUL and came unglued trying to get the content of a XUL tree cell.

What confused me was that the original function which was called by the onselect=”" attribute on the tree control actually worked until I made a small change to enable column sorting.

For some reason the tree control needs the flags=”dont-build-content” attribute to enable column sorting. I’m still trying to find some reference or explanation for this though.

After adding the flags= attribute to the tree column sorting worked fine but the doSelect function stopped working.

I searched all the forum lists and thumbed through my XUL reference books only to come to the same conclusion. Something other than what I was doing was wrong.

Most of the examples I came across used the getCellText function so I re-wrote the function to:

Needless to say this didn’t work and resulted in the following error:-

Error: uncaught exception:
[Exception... "Could not convert JavaScript argument - 0 was passed, expected object.
Did you mean null? arg 1 [nsITreeView.getCellText]"  nsresult: "0x80570035
(NS_ERROR_XPC_BAD_CONVERT_JS_ZERO_ISNOT_NULL)"  location: "JS frame ::

So I re-wrote it slightly to this:-

Same error!

You’ve gotta love Mozilla for the excellent JavaScript Console without which I would never have known where the problem was.

When I actually bothered reading the exception I worked out that the second parameter (arg 1) was supposed to be an object and not an integer. According to the docs I’d read the getCellText function took two integer arguments - namely row and column. Well it used to - once upon a time.

After futzing around for a while I ended up trying different approaches and finally gave up and went searching again for a possible cause and hopefully a cure.

The answer I needed was on Bugzilla all along.

It seems that not only is there a bug but the syntax for the getCellText function has also changed. Luckily the bug entry had a workaround that solved the problems I was having.

I wanted to re-use the function on different tree controls so I changed it to accept a column id and modified the workaround suggested on Bugzilla. The final function now looks like this:-

It works!

So the moral of the story is Check the bug list before wasting countless hours tripping over undocumented features aka bugs.

In a recent post by Brendan Eich on his Brendan’s Roadmap Updates Mozilla blog and echoed on Ajaxian it would appear that our favourite programming languge is about to land on the desktop in the Firefox browser in more ways than one.

Not only is Pythonic syntax finding its way into JavaScript (JS2) but we are soon to see Python in Firefox as an alternate scripting language.

Since reading about Python in XUL last year I must say I’ve been eagerly awaiting this development.

I don’t mind JavaScript as a language and there are certainly plenty of well developed libraries like Script.aculo.us, MochiKit and Dojo which make our job easier but I am looking forward to being able to use Python at both ends of client/server web app development.

Scripting XUL with Python will be pretty close to GUI Nirvana.

In a recent e-mail a fellow programmer who is also looking at Pylons for web application development raised the following question:

Paraphrased:
Pylons appears to have many dependencies. [list omitted] What happens if any of the packages Pylons depends on stops being developed?

A damn good question. This question has to be in the back of every developers mind irrespective of which tool set they work with and affects open source as well as closed source developers alike.

Admittedly my response (inset) was rushed and written in the wee small hours so I’ll try to clarify further below.

Hello [omitted],

Yes you are correct there are many requirements when developing web apps in Pylons. The minimum you will require is Paste and Myghty. PasteScript and PastDeploy are development time tools. Assuming you want to use javascript you would also add RailsHelpers, simplejson, prototype and possibly scriptaculous. If you use the postgres database you then add postgresql, psycopg2 and SQLAlchemy to the list. And it goes on.

I’m not sure what to advise as this is the case with any web framework. Even if you designed your own using WSGI you would be importing standard Python library code which will also change over time. The same issues exist with commercial frameworks and it’s even worse. If the proprietor goes out of business you don’t even have the source code to fall back on.

If we look back at the twisted/Nevow/Newfox stack we have the same issues. At present NewFox is stalled waiting for Nevow to be refactored while Nevow is being run against the current and no longer supported twisted 1 framework. When twisted 2 comes out it starts all over again.

The simple answer is that no matter which language and framework you use there will be dependencies. The upside of the this is that you get them all with source code.

If you look at alternative server side languages like PHP, .NET, Coldfusion, TuboGears, etc the same problems in longevity arise and this too worries me. This trend has been getting worse over the last few years rather than better.

What are your thoughts?

As you can see, my response, wouldn’t have gone a long way to allay his concerns.

After re-reading my response I know I’ve left quite a lot out and it may not make much sense to the casual reader as there have been dozens of exchanges between us over the last few years.

Our individual projects are targeted at totally different audiences yet the underlying requirements are very similar.

We are both developing Intranet applications based on Web2.0 technologies. In other words users interact with our applications via a web browser. All the logic and application software are on a central server or in his case several servers offering different resources and data to a central application server.

There are roughly 30 individual libraries or packages we are integrating into our respective applications. Some of these have reached a stable state being at version 1.0 or greater whilst others are still in beta. Packages we are using are maintained in various ways. Some are are complete packages available as Python .egg files, others are downloadable from cvs or subversion repositories whilst others are just source downloads in .tgz files. Keeping all this under control is and will remain a constant chore for the foreseeable future. Talk about shifting sands.

Where does this all lead?

My major concerns are maintainability and software lifespan. Are the days of long lived application software gone? How do we manage software longevity when the underlying support systems and codebase are constantly in flux?

I haven’t got the answers and I’m pretty sure no one else does either – at least not yet.

As I said to my colleague – What are your thoughts?

It’s comforting to know that I’m not alone when it comes to tearing my hair out with web frameworks.

In a recent posting by Guido van Rossum the author of the Python programming language titled Please Teach me Web Frameworks for Python it would appear that I am in good company. The last time I looked there were 85 replies and another posting by Guido discussing his initial feelings and thoughts on all the responses he’s had so far has had another 16. All in all they make for an interesting read.

We are all apparently scratching the same itch looking for just the right mix of framework and library code that will make Web App development suck less.

From the responses to Guido’s article I started looking at Pylons which looks promising. At least it didn’t take too long to install and get it running. So I’ll spend the next couple of days fiddling with it.

A couple of articles recently posted on IBM DeveloperWorks covering XML, XUL and Ajax are a must read for anyone interested in the future of Web Application development.

• XML in Firefox 1.5, Part 1: Overview of XML features
• Ajax for Java developers: Build dynamic Java applications

Take a peak. I’m sure you’ll find them interesting.