My blog has moved here. Perhaps I'll actually write in it this time around.

We’re about to move an app in to production that uses a fairly large amount of Ajax goodness within it, and I’ve found the reaction of our test users fairly interesting. The simple fact is that there was essentially no reaction (other than an occasional “this doesn’t look like a normal pop-up window” when a DHTML div showed up instead of a browser window). Users coming from the fat client world simply expect their apps to work like this. Instead of fielding the usual complaints about the traditional problems with web-based apps, users can just get their work done in a more efficient manner than they could have before, which ends up making things easier for everyone involved.

Last night I spent a while putting entries into a reporting web application. The application allowed the user to add new data entry lines using some Javascript magic by clicking an "add line" button. Of course, when I finally clicked the save button, after an hour or so of putting entries into the system, I was greeted with the Login screen, as my session had timed out.

So I got to spend another hour doing the report over, this time saving frequently as I went, and I spent the time thinking about how things should have been implemented to prevent this. The lesson learned is that if you're going to give your users the illusion that your webapp is keeping state internally, you damn well better be doing something about it. It probably would have taken the developers all of an hour to add an XmlHttpRequest call to ping the session to keep it alive each time a row is added, or better yet, save the entire form automatically. That simple change would have solved the problem, and if the form was saved automatically each time, it would have also prevented people who lose their internet connection in the midst of doing the report from losing all of their work. We have to remember as we build our newfangled interactive webapps, with what I’m now calling the Illusion of Interactivity, that the web is still a stateless beast. If we forget that we’re sure to screw our users in the long run.

We moved an app into production a couple of weeks ago based upon Nanocontainer and Nanowar and everything has been going extremely well. The separation of containers in Nanowar is an awesome concept. It allowed us to have a Hibernate session start up exactly at the beginning each request and end exactly at the end of each request, with no extra effort on our part. This made all of our persistence work extremely easy, as I didn’t have to worry about any lifecycle issues. In fact, I didn’t have to worry about any lifecycle issues at all. If I wanted something to live for the life of the application, I put it in the application level container, if I wanted it to live for the life of a session, I put it in the session container, and if I just needed it for the life of a request, I put it in the request container. Nanowar took care of building all of the trees of containers for me. We're ramping up on another project now, and I'm definitely going with Nanowar again. It's one of the few frameworks I've worked with lately that actually makes complicated things massively easier to do.

Thank god jt pointed out this incredibly useful barchart. Without it I'm not sure I would have understood what 100x faster really means.

I've been checking out a bunch of containers lately and I'm not sure which one to use. I've checked out Plexus, Loom, PicoContainer, and others, but I don't really see a clear advantage of using one of them over any of the others. My code is already well-tested and basically riding on my homegrown container to lace all of the components together, but I would like to standardize the way that I configure and integrate things. I get the feeling that I'm just going to end up writing wrappers for a few different containers and seeing what works best. Anybody have any killer reasons to justify chosing the container they use before I just dive into trying them all out?