I mean, seriously. For web-apps we have tens (maybe hundreds) of frameworks that abstract away the painful details for creating data-based applications, then get out of the way as you add custom behavior and so on.

I mean, using Django, you can whip-up some models, generate the appropriate database schema, play around in admin, maybe use databrowse, use nice html forms, add a dash of HTML+CSS and you get maybe 80% of the functionality. Then you add your custom views, report generation, a bit of AJAX --if necessary-- and you have a nice data-based web application ready for deployment.

Why am I ranting about this ? First, for a bit of personal history...

Ye not-so-olde days

I started out working as a software developer in a laboratory in University of Patras. We developed web applications using JSP and later Struts. For database access we used Borland's QueryDataSets that managed a bit of the complexity --- you still had to write your own SQL --just SELECTs, though--, but you defined some metadata in the columns that you could use later for display purposes. We had a lot of custom code that did introspection so we could easily display QDSs as tables. No need to say, it was messy, but it did the job.

The problem with that approach was, of course, duplication. Oh my God was there duplication. To add a field to a table, you had to:

1. Make the change in the DDL
2. Search the code for references to that table and...
3. Change SQL queries
4. Add the necessary QDS columns
5. Go to Struts' ActionForm classes and add the new field
6. Go the JSP template and write up the HTML that displays that field

That is not all. We had of course created utilities that acted as "ghetto" bindings. If the variables in an ActionForm had the same name with the columns in a QueryDataSet, you could populate the one from the other, and vice versa. The problem was, sometimes you had to do more than that, and it was tedious, boring, repetitive... an ideal bug generator.

Fast-forward

Anyway, despite all the above, I've learned a lot there, we were doing cool stuff, and, of course, being in academia we afforded to have terrible bugs that nowhere else would be acceptable. I'm sure that if we had time and went back to start again, we'd do things very differently.

So I tried, in a little project of mine, to do things correctly. I set out to create a "little" desktop application that would manage the patients for a dietician friend. I wanted to leverage as many third-party libraries as possible. I only knew Java well enough back then, and I used Eclipse extensively, so going with Eclipse-RCP was a bit of a no-brainer. A seemingly nice platform, using SWT (I wanted to have a native look), it had wizards, an update manager, background tasks, preference panels, toolbars etc. So far so good.

Whither ORM?

So I looked around for an ORM-like solution. The big thing around was Hibernate. I looked into that, but it seem very complex and an overkill for my needs. I've seen what Rails did with ActiveRecord, and I wanted something like that. To my despair, there was nothing that simple available for Java (at least, nothing I've found at the time). So I went with iBatis: it used plain SQL, which I knew well, and POJOs, which seemed simple enough.

That's where things started going downhill: I got lazy, and I wanted to find a tool that will introspect my database schema, and give me some nice JavaBeans I can use for CRUD operations. I eventually found Abator that generated all the crud for me...

Oh, the horror! For each table, Abator generated one huge xml descriptor file and two Java classes. Talk about duplication. It used the names from the database, too, so to change the POJO name, you had to change it everywhere, but if you changed the schema and regenerated from Abator, you had to do it again. I eventually wrote my own descriptors, so I was back to square one...

Databinding ? Let's see...

To my shocked surprise, there was no framework in Eclipse RCP for binding to forms. Actually, there was, but it was in alpha, you had to get it from CVS and deal with its bugs too. I was brave and did that, and had to update my code once or twice. Worked good enough, but I had to be very verbose about things.

To display the fields in the forms, I used Java annotations, like display_text, foreign_key, boolean_value etc. It was pretty good, but a bit tiresome to use, and of course since I wrote it myself it had a lot of rough edges.

CRUD - roll your own

Soooo, to come round to the introduction of this long rant: I had to roll my own CRUD solution, mostly from scratch. Add an object to the database, delete it, present all objects in a table, simple stuff like that. This took me a lot of time --- if this was a real client project, it would take me at least twice the time I estimated. Plus, it had a lot of bugs and lacked simple features.

The Django approach

Now, what Django has to do with this ? Well, I realised that I could now re-write all this using Django in about 2-3 weeks of 40 manhours. Really, it isn't anything complicated: CRUD with a twist (the forms are a bit more complicated, so I can't use the admin), a basic dashboard the presents information about each patient. I wrote most of the model definition in about 30 minutes. And I get all the metadata I had to implement myself before, plus a basic form creation framework that I can further customize...

Conclusion

To be honest, a lot of the mistakes of the past could be attributed to me: I was inexperienced, and a bit foolish to go reinvent the wheel. But, in defense, I couldn't find something to do what I wanted, so what's a poor coder to do ?

Or maybe the libraries 2 years ago weren't as mature. Or cool ORMs (like Rails' ActiveRecord and Django's Models) weren't widespread enough so people can see the bliss in working with them. Maybe Java developers were all drowned in uber-frameworks lice Eclipse RCP, Hibernate and Spring to see the simplicity. Perhaps I didn't know where to look.

But, one thing is for sure: For now on, it's Python and Django for me. You can install locally, create wrappers and who knows where this can lead. Or, mif you like that stuff, you can factor out the web-specific stuff of Django, and use IronPython or PyObjC to go to the desktop again --- if there is absolute need.

The only desktop client solution I've seen so far that looks promising is what Apple is doing with CoreData, Bindings etc. In fact, when Leopard comes out in October I'll get myself a MacBook and start to play around there. But the fact is, you can't develop data-based apps just for the Mac, unless you sell Mac minis to run your software as well --- it's all about market share. Though if the niche is viable, I'd love to start digging in.

Whew. That was a long rant. Comments welcome...