Technology choices

In the early stages of product development a major decision for us was what technology to use. There are many considerations such as distribution, how the product will be used and by whom. In my opinion it tends to come down to two things. Desktop vs web based. Obviously Desktop has many advantages when it comes to building a powerful application whereas Web based is easier to update and distribute. However those lines have become increasingly blurred. I was at a conference just a little over a year ago where I sat in on a presentation about an application implementation using Java Web Start. The argument the presenter was making, was that the browser was too limited and stagnant since the IE dominance, and that Microsoft’s goal was to limit the success of browsers in order to better promote its Web Forms. He went on to describe the glory of developing using Swing and Java Web Start.

I had an opportunity to pursue a solution, like the one above, using either Swing or SWT, but my team was primarily J2EE skilled and the client was interested in a browser based solution. We ended up implementing the application using Struts, but I always felt restricted by the browser. We were as creative as possible using Javascript to do some fun user interface solutions, such as using iframe’s to create a more dynamic feel. But all of this was more eye candy than it was a constant “rich” interface.

Now, faced once again with choosing a technology for our Requirements Management Tool it was clear we wanted the application to be web based for the ease of distribution, but it was equally important for the user interface to behave like a desktop application. We began looking into Ajax. However we were a bit scared of the overhead of implementing such a Javascript reliant application. After all, myself and the rest of the team were used to enterprise applications working with Java, .Net, Web services, Struts etc. We had all used Javascript but never to this extent. And to be honest we did not trust that JavaScript, on such a large scale, would be maintainable.

So we hesitated and dove into coding using Spring, Spring MVC and Hibernate. After all, there was still a lot to think about. We set up the build system to use Xdoclets to generate the Hibernate mapping files. We were much more familiar with Struts but were ready to move on and liked the looks of Spring and it’s MVC implementation. As well we plugged in Acegi as our security framework. All the usuals where there such as JUnit, Eclipse, Tomcat. We found a cool DHTML Tree for our requirements page, Canoo WebTest for our acceptance tests and CruiseControl for our build automation. All that was missing was a slick user interface. We applied some cool css but at the end of the day it was all still click-controller-refresh-view (transient). It wasn’t until we came across DWR that we began to realize the possibilities in accomplishing a sovereign application as described in Ajax in Action.

Next week; DWR and Dojo…

Derwyn

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*