I thought I’d expand on my previous point. It’s a simple one, but they’re always the trickiest.
Web apps are by their nature stateless. Stateless applications are a pain in the butt to build, because they are extremely complex (not just complicated). By stateless, what I really mean is that the client state and the server states are disconnected. This is due to the (truly) stateless nature of the HTTP protocol that underlies all web apps.
If you ignore this fundamental fact about web apps, you’ll end up building the proverbial useless piece of crap, like the one I just spent two weeks bandaging back into something resembling health.
One of the better ways (in theory) of dealing with this fact is the use of a stateful framework on top of the application. However, these are easier described than built. I’m not personally familiar with any decent ones; the bulk of my Java web app experience has been Struts based, and I haven’t had time to explore any of the newer crop yet (though I’ve heard good things about ). However, I’ve seen some bad ones.
What does a tool like this need to provide? Well, it really shouldn’t constrain the user too much. One problem I’ve seen with a lot of attempts at stateful architectures is forcing the user down a particular page flow… if you haven’t gone through Pages A, B, and C, then you can’t get to D, and there’s no way you can pop back to A from C to fix something there without having to revisit B, and so forth. These, I think, are too restrictive. One good model I’ve seen is the install program used for RedHat Linux, where you can jump around the various tabs happily in any order (though some won’t be enabled until data is filled in, and other tabs will be disabled when a choice has been committed to).
And no, I’m not proposing a solution. I use this blog as a tool to help formulate my own thoughts, and right now my thoughts are that I’m not happy with the solutions I’ve looked at in the past. I need time to sit down and work out a way that I find personally better.
One strong point, however: don’t expect this to be easy. Solid, robust, and functional web applications are significantly more complicated than a single tier application, and more complicated than a fully stateful n-tier app (with a rich client). The only reasons they’re popular are:
* They solve a truly horrendous deployment problem common in a lot of organisations
* For internet apps, they’re very lightweight for clients (especially in terms of bandwidth). The ubiquity of the browser also provides a (rather shitty) lowest common denominator as well.
* CIOs like web apps, despite (or because) not knowing the drawbacks to them.