Porting an existing Java Web application to a new framework can be tedious to say the least - the process of converting things like tags, internationalization systems and validation is enough to discourage developers from the move. But sometimes the benefits of a new framework outweigh the cost of porting. As Rick Smith's Struts applications grew, he found himself facing cumbersome configuration and separation of forms processes. For him, a migration made sense - but most of the frameworks he considered had their own issues that discouraged Smith from porting. That is, until he found Stripes. In a recent article, Smith chronicled his journey from Struts to Stripes.

Like many in the Java community, I had been following the Ruby on Rails (RoR) phenomenon. For me, Stripes was the closest of the Java MVC frameworks to the RoR philosophy: simple, elegant, and requiring minimal configuration. In addition to its simplicity, Stripes looked familiar to a Struts veteran like me. The application flow and many of the naming conventions were similar. Stripes' ActionBeans were like Strut's Actions, and ForwardResolutions looked a lot like ActionForwards. With this framework, I would not have to throw away all of my hard-earned Struts knowledge.

Another deciding factor was that Smith estimated that he could reduce the total lines of code in the action, configuration and validation areas of his application by half. According to Smith, the migration from Struts to Stripes was generally painless, due to several factors. Stripes, for instance, has a similar tag library to Struts. Also, Smith was able to replace all of his Struts message tags with JSTL format tags using universal replace. And he could get rid of his extensive Struts Action Forms for Stripes form handling, which allows using the domain object as a form. Where validation is concerned, with no user configuration, Stripes returns HTML forms to the user when they enter the wrong value type - and beyond that, Smith describes, "automatically with a user-friendly message and the offending field highlighted."

Converting the control flow of my Struts application was probably the one place that required a break from the Struts way of thinking. In Struts, control flow—the binding of URL requests, actions, and the resulting view—is rendered in XML markup and centralized in the struts-config.xml file. This rendering outside the action layer makes Struts bindings flexible. They are not hard-coded inside the action layer and a single action can easily be coupled with different input URLs and forwards. The downside of this approach is that Struts configurations can quickly grow large and cumbersome. The separation of control flow from the action layer can also make debugging all the way through the request cycle difficult. Stripes offers three different ways to map requests to the action layer: 1. Explicitly bind an ActionBean to a URL using annotations 2. Allow Stripes during startup to guess the binding of its ActionBeans based on the similarity between the ActionBean class path and the application URLs 3. Bind a JSP to any ActionBean, or call any method of a Java class in the application class path, using the Stripes useBean tag While the first two approaches seem somewhat hard-coded compared with Struts configuration, the useBean tag provides a lot of flexibility. With it, JSPs can access multiple ActionBeans or classes to get just what they need.

When considering porting to a new framework, ease of migration, Smith admits, should not be a deciding factor. But in the case of Struts to Stripes, Smith says it was nice that he could maintain some of his investment after a fairly simple porting process. What are your experiences with porting? What framework is most beneficial to you - and what qualities would make a new framework worth a migration?

From the article: --- I threw away all of the form handling in Struts Actions, including initial configuration, casting the form to the appropriate class, and copying and converting that data to and from the domain object—about 30 percent of the code in most action classes I've seen. It was not needed in Stripes. --- it is NOT needed in Struts as well. Plese see my slides http://sandbox.sourcelabs.com/kosta/sashstarter-2.0/docs/presentation/html/img19.html

Well, from your own slides: http://sandbox.sourcelabs.com/kosta/sashstarter-2.0/docs/presentation/html/img21.html So right, using Struts you can certainly bind directly to BOs through the form. But if you want to redisplay the user's incorrect input after a type conversion (they typed an alpha into an integer field)... as you say, the developer needs to make "buffer fields" or otherwise store the input and redisplay it. Definitely ugly, and why there are countless posts from the struts team over the years expressing why in struts the general practice is to flatten everything out into the form, then copy back and forth.

...as you say, the developer needs to make "buffer fields" or otherwise store the input and redisplay it....

Are you saying that Stripes will take care of displaying errorneous alpha input for a numeric field? What if the field belongs to a nested complex object of the current BO but the object is null now? Lets say 'order' has 'customer' that has numeric field 'age'. And currently 'customer' is null in the current 'order' BO. What will Stripes do if user specifies 'infant' as value of 'age' form field?

Are you saying that Stripes will take care of displaying errorneous alpha input for a numeric field?

Yes.

What if the field belongs to a nested complex object of the current BO but the object is null now?

If the input cannot be converted to the correct type, it will display the erroneous value verbatim just as if it were a non-nested property. If it's a valid value Stripes will instantiate the intermediate BO, connect it up, and then set the value.

Lets say 'order' has 'customer' that has numeric field 'age'. And currently 'customer' is null in the current 'order' BO. What will Stripes do if user specifies 'infant' as value of 'age' form field?

It will determine that 'infant' is not a valid Integer/Short/int/short or whatever type the age property of the Customer class is, and redisplay the input verbatim to the user to correct. This is all pretty bread-and-butter stuff for Stripes. -Tim Fennell Stripes: Because web development should just be easier

Are you saying that Stripes will take care of displaying errorneous alpha input for a numeric field?

Yes.

What if the field belongs to a nested complex object of the current BO but the object is null now?

If the input cannot be converted to the correct type, it will display the erroneous value verbatim just as if it were a non-nested property. If it's a valid value Stripes will instantiate the intermediate BO, connect it up, and then set the value.

Lets say 'order' has 'customer' that has numeric field 'age'. And currently 'customer' is null in the current 'order' BO. What will Stripes do if user specifies 'infant' as value of 'age' form field?

It will determine that 'infant' is not a valid Integer/Short/int/short or whatever type the age property of the Customer class is, and redisplay the input verbatim to the user to correct.

This is all pretty bread-and-butter stuff for Stripes.

-Tim Fennell
Stripes: Because web development should just be easier

FWIW WebWork has done this for several years, and Struts 2 (based on WebWork) does it too, including all of the object creation for intermediate objects in the expression path travelling down the object graph.

FWIW WebWork has done this for several years, and Struts 2 (based on WebWork) does it too, including all of the object creation for intermediate objects in the expression path travelling down the object graph.

Exactly - why it's such a suprise that a framework can do this automatically for developers eludes me :p As I've said in prior posts around here, developers need to have higher expectations of the frameworks they use! -Tim Fennell Stripes: Because web development should just be easier.

If it's a valid value Stripes will instantiate the intermediate BO, connect it up, and then set the value.

If he does it by default, it can be quite dangerous. The user can blind-guess child members of your object and set tem according to his will. This problem arrives with first-level properties also, but all developers know it. Which child members, developers who do not expect this value to be set might get a big surprise during runtime.

If he does it by default, it can be quite dangerous. The user can blind-guess child members of your object and set tem according to his will.

Not really : a few @Validate annotations and your ActionBean is bullet-proof (you have the same validations than you'd have in form fields). And btw, is this related to automatic instanciation ? As far as I see, the problem you're pointing out can arise only when the object *is* instanciated... who calls the contructor doesn't really matter, does it ?! Anyway, IMHO, this auto-creation stuff is not that good when you work directly with the domain objects... Actually in my case, domain objects are often abstracted by interfaces (contract-based), and the UI tier never knows the implementation class... so Stripes (or WW) can't help : I have to manage instanciation myself anyway ! Have fun, Remi

If I am a new and young java developer, which ones shoulg I start ? www.j2concept.cjb.net

RE: IQ Not much difference between genius and normal, but it's a long way from normal to idiot?

I have had a quick look at Stripes... Comparing it to struts is a No-brainer... But i would like to think we have moved on since then... I would like to see Stripes compared to Spring MVC. Spring MVC handles binding translation through standard JavaBean properties editors and validation plugin. Then ofcourse there is spring webflow.. From a QUICK look at the docs. So by no means have i done any indepth comparisons... These are the things that i am not to keen on... You have Tags for generating HTML (form elements)... This means this HTML is hidden from HTML designers.. They have problems styling it... eg: In spring mvc you would do this: and they have also added in spring 2.0 a form tag... But i don't like this as it has the same problem as yours. Spring MVC also abstracts out the the View... So i don't have to use JSP. I could use freemaker or velocity or xlst etc. I see in the quick start guide you have: return new ForwardResolution("/quickstart/index.jsp"); Is this just a quick example of getting to the view or do you abstract it out.. So the controller does not know the view... Eg could i put return new ForwardResolution("index"); and that is resolved to /quickstart/index.jsp. If NOT that is a coupling that is not good and is worse than struts. The configuration seems to heavily dependent on JDK1.5. Not such a bad thing but limiting.. Seems a lot of effort to work in JDK1.4

Comparing it to struts is a No-brainer... But i would like to think we have moved on since then...

I would like to see Stripes compared to Spring MVC.

I agree this would be nice. I've used Struts a lot, which is why I was happy to write that comparison. I've played with Spring-MVC and found quite a lot that I /personally/ didn't like. But I haven't used it in depth enough to write a good comparison - so I'll have to leave that to someone else.

These are the things that i am not to keen on...

You have Tags for generating HTML (form elements)... This means this HTML is hidden from HTML designers.. They have problems styling it...

eg:



In spring mvc you would do this:


name="${status.expression}" value="${status.value}" />

Well, the bind tags was something that I really didn't like in Spring-MVC. It just so verbose! In Stripes, although custom tags are used, they mirror HTML tags in every respect. All attributes are the same as the HTML equivelants. So if you're template designers have a tool that can preview your templates, the tags should all be very familiar. And if not, your template designers can use pure HTML and you can run a quick search replace for to . And given that in reality developers do a lot of template writing/maintenance, this is a simpler syntax for them.

Spring MVC also abstracts out the the View... So i don't have to use JSP. I could use freemaker or velocity or xlst etc.

Stripes doesn't have any dependency on JSP. It supports JSP and FreeMarker well. You could use Velocity or XLST if you want - you just won't get the benefit of the tag library.

I see in the quick start guide you have:

return new ForwardResolution("/quickstart/index.jsp");

Is this just a quick example of getting to the view or do you abstract it out.. So the controller does not know the view... Eg could i put

return new ForwardResolution("index");

and that is resolved to /quickstart/index.jsp. If NOT that is a coupling that is not good and is worse than struts.

This is a longer discussion. The main difference here is that Stripes returns concrete Resolution objects, whereas Spring-MVC prefers symbolic strings. My personal opinion is that "abstracting" the name of the view out of the controller class is effort, and people condescendingly refer to it as a best-practice when in reality the benefit is questionable. Returning the Resolution as the Stripes examples show just means you're spreading information around less (no external config files full of action/result/page mappings). This approach also makes it hugely more straight-forward to stream information back to the client in the case of AJAX downloads as you can just construct a Resolution and hand it back to Stripes to execute. When dealing with symbolic results you have to jury-rig a way of passing the extra information (the File or Stream, content type etc.) BUT, it should be pointed out that having concrete Resolutions doesn't in any way prohibit symbolic results. It'd be about 20 minutes work to write a SymbolicResolution that uses a symbolic name to look up a the page and whether to forward/redirect etc.

The configuration seems to heavily dependent on JDK1.5. Not such a bad thing but limiting.. Seems a lot of effort to work in JDK1.4

Stripes states pretty clearly that it is designed for JDK 1.5. This is a purposeful decision. It allows it to use annotations everywhere it needs, and not have to deal with externalized config or clunkier mechanisms. Similarly it can use generics information to the fullest to work with Lists and Maps etc. And in reality, the kind of developer/team that is willing to try a relatively new (compared to Struts/WW/Spring-MVC) framework is usually the kind of team that's already using JDK 1.5. -Tim Fennell Stripes: Because web development should just be easier

And in reality, the kind of developer/team that is willing to try a relatively new (compared to Struts/WW/Spring-MVC) framework is usually the kind of team that's already using JDK 1.5.

Good point. There is no reason for a boutique framework to impose legacy limits on itself. ______________ George Coller DevilElephant

My personal opinion is that "abstracting" the name of the view out of the controller class is effort, and people condescendingly refer to it as a best-practice when in reality the benefit is questionable.

Yup, I completely agree with this. Now, perhaps it's different in S-MVC, but in Struts, you were pretty much inevitably hard coding the page URLs in the XML file rather than in the Java code. But, in fact, they didn't really offer that much overall abstraction. The abstraction is there, if you reuse an Action class across different URLs and change the ActionForwards. But, for most webapps, that kind of re-use ends up being the exception, and not the rule. But, as a rule, you need to jump through this kind of hoop for all of the simple cases. Granted, you simply write your code in Struts to return "new ActionForward("/hard/coded/File.jsp")", but, of course, that's not advocated -- so folks don't. They jump through the extra complexity and configuration hoop. The Resolution aspect of Stripes gives solid default behavior for the 80-90% case, and a nicely factorable tidbit that you can use (and, most imporant, re-use) for the special cases. In Stuts, you only have easy control over the URL (via the ActionForward), whereas with a Resolution, you have control over the entire response mechanism. Rather than burying that in the framework, its exposed and re-used everywhere. The beauty of Stripes is it makes the simple cases simple, and learning the simple case is easy as well.

...as you say, the developer needs to make "buffer fields" or otherwise store the input and redisplay it....

Are you saying that Stripes will take care of displaying errorneous alpha input for a numeric field? What if the field belongs to a nested complex object of the current BO but the object is null now?

Lets say 'order' has 'customer' that has numeric field 'age'. And currently 'customer' is null in the current 'order' BO. What will Stripes do if user specifies 'infant' as value of 'age' form field?

If you display customer-related fields to create a customer, a customer should be created, I don't see a problem here. If you display customer-related fields in "update a customer" form and a customer is null, that this is a bug, the application will blow up when you submit, so it would display an exception instead of a form. By the way, OGNL can create new nested objects, JSTL will not create them but it will not throw an exception trying to read from a null nested object, so you will get null on reload. If the customer object is valid, than specifying "Infant" for an numeric "age" field should trigger an error, but the value should remain as "Infant" after the roundtrip. I hope Stripes does keep it. P.S. "Infant" as a value for age is cute. I suggest using "genius", "normal", "debil", "imbecile", and "idiot" as values for IQ.

Well, from your own slides:
http://sandbox.sourcelabs.com/kosta/sashstarter-2.0/docs/presentation/html/img21.html

So right, using Struts you can certainly bind directly to BOs through the form. But if you want to redisplay the user's incorrect input after a type conversion (they typed an alpha into an integer field)... as you say, the developer needs to make "buffer fields" or otherwise store the input and redisplay it. Definitely ugly, and why there are countless posts from the struts team over the years expressing why in struts the general practice is to flatten everything out into the form, then copy back and forth.

Exactly. Struts is not good with type conversion and I/O values' buffering, so there are two choices: * Use a nested BO inside an ActionForm. Nested BO should be able to accept and store stringified value, as well as to convert and validate the value. You can see a proof of concept here; a lot of code for just two properties, but the code size can be reduced by creating more generic classes supporting this paradigm. * Another option is to use ActionForm as an I/O buffer and copy/convert data from it to an actual business object using third-party tools like FormDef. While many Struts committers think that having value-add tools as third-party libraries is better because it offloads support and maintenance to developers of the tools and allows to keep Struts core smaller, I believe that a regular Struts user will more likely use a technology built into the core of the framework instead of using a third-party tool.

For those who are interested in reading more about Stripes, the main website and documentation is located at: http://stripes.mc4j.org -Tim Fennell Stripes: Because web development should just be easier.

Excellent documentation... It is thorough, clean and simple. I wish other open source projects would give their documentation this much love and attention. Lack of baggage... Annotations provided a new approach to solving problems that were previously complex. Stripes was written targeting this new capability in a way that older frameworks just can't reproduce without major refactoring. A quick comparison of feature counts and lines of code / interfaces in the framework shows the advantage. It is as complex as it needs to be and no more. Btw, the concept of having external projects provide things like validation to keep the core framework simple just sucks. It's what causes me to need to edit two xml files in three places and four+ classes when I add a field to my business object on my struts project.

Thanks for mentioning formdef. I am also one of these guys doing still Struts1 development because of my usage of CommonControls (JSP Tag library and Struts1 addon framework). I never looked for something like formdef but i definitely hate my FormToDomainObject Helper classes pretty much. @Jason nice to hear that webwork/struts A2 will solve this but what would be really interessting is some kind of predicted release date for Struts A2 :) Its very silent about Struts2 these days. Marc Logemann http://www.logemann.org

formdef is really nice, i used it in several projects. but, you should read about nested beans before you adopt it here http://www.rabago.net/struts/formdef/nested.htm

formdef is really nice, i used it in several projects. but, you should read about nested beans before you adopt it here http://www.rabago.net/struts/formdef/nested.htm

Will I for one am a stripes convert. I had a lot of old code written using the struts framework. We had a lot of new development coming down the pipe and decided to re-evaluate technologies and frameworks. The struts code we had was huge and unwieldy and quickly becoming unmaintainable. I dug through jsf, spring web, rife, webwork, seam, maverick, and a few others. After much research, we had decided to go with webwork. Then I ran across this site talking about Stripes. I hadn't heard of it and didn't give it much thought but figured I'd look at it since I had looked at so many already. What I found amazed me. Stripes handles all the little things that are so annoying to developers such as validation and binding to domain objects. The actions are simple and straight forward and I liked the fact that the actions and the models were tied together. There were a couple of features other frameworks had that stripes didn't, but most of them were features I didn't really need anyway. The more I used it, the more I liked it. The thing that really made it great was the fact that it was so easy to extend to do what you want with little or no effort. I wasn't a fan of annotations until I started using Stripes and now I love them. The docs were great. I was fully up to speed on Stripes and using it in under 1 hour. The nice thing is we can bring in developers and have them up to speed in a very short time as well. While there are good frameworks out there, Webwork and Seam being two of my favorites, none can really compete with what Stripes provides as a whole package. I did convert everything from struts to stripes in a short amount of time and reduced my code base by almost 2/3. All this work isn't in some little shop. I can't say where its at, but it is a Fortune 100 company and things need to be solid. Just thought I'd throw a plug for the best framework currently out there in my opinion. Nic Holbrook

+1 ! I've also been amazed by how everything is simple with Stripes ! As a matter of fact, frameworks are generally hard to grasp. Stripes is not : it's probably the simplest MVC out here, but still it has an answer to most of regular web developement's issues. Things inside are well designed and fully extensible/customizable, and last but not least, docs & support are very good. Bravo Tim for this, and keep on the good work, we appreciate ! Have fun, Remi

After some troubles at the beginning I really started to love the struts framework. Then I tried out Stripes and it looked great from the beginning. When I tried it out, I was completely surprised that both frameworks even work great together. This is what I always liked in struts, you're not forced to use it because you can always mix it with simple jsp files and servlets. The same applies to Stripes. Both framework work wonderfully together. Both have their pros and cons, but to be able to use them both together is just great.