Paul Barry

Stripes is the new Rails

July 11, 2006

I’ve have recently discovered Stripes, a Java web MVC framework. I know what you’re thinking, yet another Java web framework? Struts, Webwork, Tapestry, Wicket, RIFE, do we really need another framework? I think the answer is yes. From my experiences with the Stripes framework, it seems like it has the simplicity and flexibility of Rails, without the limitations. What are the limitations of rails you ask? There are two that I can think of off hand:

  1. Indexed Properties

    It is very difficult to work with index and nested properties in Rails. In simple terms what I mean by indexed and nested properties is being able to have a form field called bugs[0].watchers[3].name, which means you have a list of bugs, and each bug has a list of watchers, and each watcher has a name, and you want to get/set the name property of bug #1, watcher #4 (the indexed are zero-based, like arrays). Stripes makes this easy, it seems to be much more difficult in Rails.

  2. Dealing with non-AR model objects

    Rails lacks the concept of a data binder. In Java, Spring MVC, Webwork and Stripes all have this. In the Java frameworks, if your form contains a field called user.firstname, it assumes you must have an object called user that has a property called firstname that you want to bind that value to. You bind the values to Plain Old Java Objects (POJOs), and they you can do whatever you want with the object.

    In Rails, the controller stores the request parameters into a data structure that is a Hash of Hashes, so the request parameter user[firstname] becomes { "user" => { "firstname" => "whatever" } }. Then, the base ActiveRecord class has a constructor that takes that hash as a parameter and sets the properties of the object based on the hash. But there are two problems with that. First, if your model objects don't subclass ActiveRecord, then you don't have that functionality. Second, if you have nested objects, it can't create them as necessary, you have to do that.

The Stripes framework is very easy to pickup and I found the author of the framework to be very helpful on the mailing list. Stripes gains most of its simplicity by relying on Annotations and conventions to limit the amount of configuration necessary. You only add a few things to your web.xml and then everything else is handled by annotations, there is no stripes.xml or whatever, as almost all other frameworks have.

I think there are a lot of similarities between Webwork and Stripes and I’m sure there will be even more similarities between Stripes and Struts 2.0, once it is available.

Posted in Technology | Topics Struts, Stripes, Ruby, Java, Rails, WebWork

Struts is still on top

March 10, 2006

According to poll conducted by JBoss, Struts is still the number one web framework, and by a convincing margin at 59%. Second place is Java Server Faces at 35% and Spring MVC is at 26%. I’m surprised to see WebWork so low down at 5%. There seems to be a lot of discussion about WebWork, I would have thought it would be higher than Spring MVC. I thought no one uses Spring MVC. And I am also surprised to see Struts so high. I would have thought most people would have moved on from Struts by now.

My personal experience with MVC frameworks is pretty simple. I first start to learn the MVC pattern with Struts, which I think many other people did because it was the first mature MVC product to gain significant mindshare. Struts had some limitations, but was certainly better than building your own web framework. I developed a couple of apps using Struts, happily creating ActionForms and using a mix of the struts tags and JSTL (it was in 1.1 in those days) in my views.

Then I discovered Spring, which was more appealing simply from the standpoint that it addresses the whole stack of your application, not just the web part. When I first started using Spring, I stuck with Struts for the web framework, partially because the Spring MVC framework seemed confusing at first. But the more I studied the Spring MVC framework, I started to like the Data Binder and the way it treats GET versus POST requests. Also, the ability to easily plug in a different view layer technology, such as velocity, which seemed infinately cleaner than JSP to me, made me switch to Spring MVC.

At this point, I haven’t felt compelled to actually bother evaluating any of the other frameworks. Spring seems at least “good enough” at this point. WebWork, JSF, Tapestry, Wicket, maybe some of these frameworks have features that make them better. But it takes time to get up to speed on new frameworks, and it doesn’t seem like it would be worth the time for me to invest in it at this point.

And maybe that’s exactly why Struts is still on top. If you don’t take the time to really evaluate what else is out there, you’ll always think what you are using is good enough. Well my personal experience has been that Spring MVC has made me a more productive developer. So if you haven’t do so yet, check out another framework, because it can make you a better developer too. And I’ll make a pledge to myself to check out a few of the other web frameworks as well.

Posted in Technology | Topics Struts, Spring, Java, WebWork