I’m wondering now that this blog post is several months old if you are still using Stripes or considering other frameworks again? I’ve been using both Stripes and Spring and find that Stripes is a better match for my environment mainly because of its osimplicity and use of convention over configuration. My main concern with it is that I don’t see any wide scale adoption of it.

Thanks.

Thanks for the thoughtful response. I think that there are different scenarios when it comes to binding in most web applications. We have some case where we bind into rich graphs of javabean-style objects (quite rare though) and on the other end of the spectrum we have our single parameter controllers. There are some in-between cases, where a few parameters capture what is needed to handle the request, and no object yet exists to capture them (and creating one may seem like overkill). In this scenario I prefer how it’s dealt with in Stripes than in Spring MVC. I didn’t mean to imply that all Spring controllers _must_ have many annotations. From my experience however, we’ve ended up with a number of such handler methods over the course of a project. Reviewing section 13.11 of the Spring Reference Guide reveals a number of method-parameter annotations in what seem like very simple examples.

I want to be clear that I view this mostly as a conversation about aesthetics. You might prefer to create simple javabeans to bind into where I prefer letting the action be that bean. I personally have a fairly strong dislike for method parameter annotations. Getting that out of the way, I’ll answer your other questions and try to clarify why it is that I prefer the aesthetics of the Stripes approach.

I like keeping my Actions simple. Multiple handlers are okay, but when the parameters or model differ too much between handlers, it becomes difficult to maintain for exactly the reasons you mentioned. In this case it’s an easy refactor to split an action into two or more simpler actions. I would describe Stripes Actions as pretty small and granular. A single page with dynamic asynchronous behavior would likely be backed by multiple Actions (and likely a single @Controller if I were using Spring). I wouldn’t map a single Stripes Action to a single Spring Controller in most cases.

While I’m not religious about it, I have been moving away from binding straight into domain objects for a variety of reasons: invariant enforcing, protecting state, immutable value objects, etc. This is a huge topic that I plan on writing more about soon. An Action happens to be a great place to bind a collection of values before doing something with them, like instantiating a value object or updating a small subset of the state on an entity. Sure, I could create a simple javabean that collects these fields, but I’m pretty happy with letting the action be that for me.

I very much like the stateless approach for my services, repositories, and many other collaborators beneath the view layer. And it was quite interesting to me when I started feeling like the Stripes model was a better fit for how I think about the view layer.

Another small perk: with the action as the root of the model, using the <jsp:useBean …/> declaration (see above) allows for modern IDEs to give great feedback about what is available to the view. It small, but nice and I don’t know how to get the same when the model is backed by generic map.

Given all of this, the fact that Stripes offers CleanURLs for RESTy URLs and binding, <s:url …/> and <s:param …/>to help with DRY, and fantastic convention over configuration, I think it’s a great framework and it turned out to be a good choice for our project. Don’t get me wrong, I love the work that SpringSource has done and I’m excited to check out all of the new stuff that’s coming up in 3.0. While Spring MVC may no longer be my first choice for the web tier (it was since 2004), the rest of the Spring stack is likely to be part of my Java toolbox for as long as I’m using Java.

Regarding Spring MVC’s singleton Controller model: if you bind request parameters to a @Controller handler method argument that is a JavaBean, which is the most common technique, there is no annotation required. @RequestParam is also optional when binding single parameter values. Most @Controller handler methods I write use no annotations other than @RequestMapping, which is concise and improves code readability. What lots of annotations do you end up writing in your Spring MVC handler methods?

I personally find it more natural to author stateless @Controllers with independent handler methods that process requests to the same logical resource. What I like about this is everything related to processing a request is local to a handler method. With the Stateful approach, model state is shared across all handler methods–what do you do when the model differs between these methods? Don’t you end up with a lot of null instance variables, and resulting confusion over what exactly the view can access? Or do you prevent this by introducing additional Action beans? Do you ever feel doing that impacts your Controller design in a unnatural way? I’m curious your thoughts on this.

Other than that it works great. We use the interceptors for certain things too. The biggest benefit though is the low configuration and auto discovery of things. Combined with the UrlRewrite library and you have a great combination.

Thanks for the IntelliStripes mention

Mario Arias

Very nice article! Thank you for your detailed analysis, it is interesting to read.

Cheers,
Freddy

The support of the mailing-list for stripes and the ease of setting it up boost productivity by a magnitude.

It’s simple, it can’t do everything, but leave the advanced stuff for later and start being productive today. – Choose Stripes.

I just finished w/ Freddy Daoud’s great book and am working on my 1st app. I’ve got something up and running within two days–remember I’ve not touched coding in 5 years!

Your point about keeping your Actions clean is well taken. Right now, all my persistence is taking place in my actions and things are getting too busy. I’ll read the article you referenced: “simple Stripes Interceptor which injects dependencies into Actions”–thanks for that as well.