No matter what car you drive , the chances are it was influenced by the Mini. Introduced in the UK in the 1960’s a whole generation of families was crammed into a car that popularized the notion of front wheel drive. While small , it was practical and drove so well it even starred in films such as The Italian Job. Recently, a more modern version was released with none of the parts but all of the spirit of the Original.
We’ll come back to the Mini, but if you build websites using Java, then at some point you have used Struts. The original Struts is proof that a framework / project / product doesn’t have to be the best to be the most widely accepted. It just has to be in the right place at the right time, and ‘do what is says on the tin’ - in this case a fairly useful implementation of the ‘Model-View-Controller’ design pattern.
So what’s the link? Seeing the original Mini from the outside may bring a smile to your face, but on the inside it’s cramped and unfortable. You may have happy memories of websites you built using the original Struts, but lately your thoughts have been straying to more modern frameworks, perhaps with Ajax and integration with Spring built in.
This is where Struts 2 comes in. Like the Mini, it has (almost) none of the parts , but all of the Spirit of the original. It’s based on Webwork which sounds scary, but most Struts Drivers will be able to climb in , find the Struts.xml file and get the engine running within minutes. Struts 2 is easier to drive (JavaBeans instead of Action Forms), more powerful (it can use Ajax and JSF) and comes with more optional extras (e.g. it’s integration with other frameworks like Webwork and Spring).
Best of all the Struts team have a clear migration path between the old and new Struts. You can use both side by side in your garage application, and change over the parts piece by piece. Spare parts for the original Struts will still be available for quite some time, both from the original team and the large dealer developer network that has built up around the framework.
What do you think? When Are you going to give Struts 2 a try?
Stripes is much better than Webwork/Struts 2. If you're considering using Struts 2, consider Stripes first.
Stripes (or any other web framework) may or may not be a better solution than Struts 2. Almost certainly it's a better solution than the original Struts (which the Struts team would admit , hence the major changes in the new version). For my own information , I would be interested in the reasons you consider Stripes better.
However 'better' does not mean 'most widely used', a fact that I should have emphasized more in the original blog post. The original Struts is proof of this - it was in the right place at the right time. Struts has a lot of people using it, and will continue to have massive mindshare for the foreseeable future.
I can think of two major advantages of Stripes over Webwork/Struts2. Before I say that, let me clarify this by saying that I have worked with Webwork, but only breifly read about Struts 2, but as far as I can tell so far, Struts 2 seems to be very similar to Webwork, so correct me if I'm wrong.
1. No External Configuration
Stripes uses annotations and conventions for configuration, rather than an external configuration file, like struts-config.xml or xwork.xml. You do have to put some configuration settings in the init params of certain filters in the web.xml, but once you have that setup, there are no incremental changes required for each new action.
2. Type Converters
Stripes has Type Converters. If Struts 2 has something similar to this, let me know. In Stripes, you can configure a Type Converter for a given object type, and then all of your actions will know how to convert a string into an instance of the given type.
For example, let's say for your app you decide all of your entities are going to extend from a BaseEntity class that defines a property called id of type Long. You could then write a type converter so that given a string "1", it knows how to use a service layer or dao layer object to load that object using that value.
The practical application of this is that if you have an action like this:
public class MyActionBean implements ActionBean {
private Thing thing;
private void setThing(Thing thing) { ... }
}
Then when you issue the request /My.action?thing=1, when Stripes does the binding, you will end up with the thing instance being correctly populated. This makes for the most elegant CRUD handling that I've seen in a web framework yet.
it's integration with other frameworks -->
its integration with other frameworks
There were a couple of features in stripes that I really liked such as the zero configuration / annotation driven design, and small footprint, but the main feature was that I was able to get developers productive in a very short amount of time even in a fairly large system. Webwork, while a very good framework, took much longer to get my developers up to speed and didn't provide any benefits functionally over what Stripes offered. The documentation for stripes is top notch and much more intuitive than the offerings from webwork / struts2. I felt comfortable enough to be highly productive in stripes after about 20 - 30 minutes. It took hours / days to get to the same level developing in webwork. I'm sure things are progressing and I see that struts2 is going to the zero config in the future, but in my opinion, its too little too late. I don't see anything being added to struts2 that would have me consider changing anytime in the future. In fact, given the current situation, I would pick stripes again in a side by side comparison. Stripes is just extremely intuitive, extremely simple, extremely powerful, and extremely lightweight. You can't ask for much more.
Just to follow up on what Nic said, I agree with all of that. Stripes is elegant, easy to learn, easy to understand, easy to use. I haven't heard of anyone yet that has used Stripes and then said, "This is nice, but no thanks, I'm going back to Webwork/Struts 2".
Most people who haven't used Stripes will, naturally, ask the same question you did, "What does Stripes have that Webwork/Struts 2 doesn't"? I think the best answer to that question is, rather than a list of features, is "Try stripes out for a couple of days, and then you'll be asking 'What does Struts 2 have that Stripes doesn't'"?
AFAIK, Stripes does not have a robust client-side validation solution. Then again, Struts 2's isn't that good either (IMO, of course).
What do you believe constitutes a robust client-side validation solution? Are there certain web frameworks or other technologies that tackle this issue well?
I got this article from stripes project website.
Stripes vs. Struts
1. Zero configuration
S2 is indeed going towards zero configuration (with regex support for action names, sensible defaults, annotations, etc..).
2. Type conversion
This has been in WW for a long time as well. Do a search for it in the WW/S2 wiki.
Don't forget, S2 also supports drop-in plugins, JSF, and lots of other nifty things you just find out when you need them. Work has started on the books, so in a couple of months, I'm convinced S2 is going to be a serious alternative for Stripes, which can only benefit both sides.
It does look like the Type Conversion framework of WW/S2 would allow you to do the same kind of thing as I put in my previous example. It will be interesting to see what happens when WW/S2 has "Zero Configuration" implemented, since there will still be the XML-based configuration. You'll see projects that have one or the other or a mix. Stripes configuration only by annotations seems cleaner, but I could be wrong, maybe some people like the XML Configuration. Although I can't see "allows for XML-based configuration" as a selling point.
I think what's going to happen is that you aren't going to see people switching from one to the other. If you are using Stripes now, I don't see anything in WW/S2 that is going to make you want to switch. If you are using WW or Struts and haven't upgraded to Stripes yet, you'll probably just go with WW/S2, since it has many of the same features as Stripes. Still, I stand by my original claim, Stripes is easier to learn and easier to use and if you are choosing between one or the other, go with Stripes.
What's the advantage of using Struts2 over WebWork?
I'm going to look at this from a Mercenary angle : why should I learn Stripes instead of Struts 2? While Stripes (or any other web framework you mention) may be better, will it be listed as one of the 'must have' criteria on the next job that I apply for?
Hi Paul Browne,
Just take a look at Struts Release plan and more specially "Special Issues" section. They are saying:
The Struts 2.0 release is following the Struts Ti Proposal. Struts 2.0 is Phase 1 of the proposal. A subsequent Struts release series (either Struts 2.1 or Struts 3.0) will address Phase 2 of the proposal.
The features mentioned in Struts Ti Phase 2 are a subset of the current snapshot of Stripes.
Not as popular as the framworks mentioned but mentawai have done great job at simplifying web development. Give it a try.
I know I'm being hard on Stripes here , but it could just as easily be any framework.
The two questions I ask before deciding to learn / use a (web) framework are:
a) Does it do something I need? - with Stripes the answer is yes , it appears to be an easier way of doing web front ends.
b) Will I be using again on another project? Here , I am not so convinced. This is nothing to do with the Stripes project , and everything to do with the fact that Struts has a very large installed based.
You know and I know that Struts 2 may be very different from Struts 'under the hood' , but from a branding perspective the sort of non-technie guy that will be hiring you will see them as one and the same!
S2/Webwork has many features that I use that I doubt Stripes has, lets give it a shot:
1) XML configuration allows me to create package subsets that are spread across multiple domains. That means my EAR file can have multiple logins (admin/user/group) and I can use a single configuration file for all
2) Ajax taglibs
3) Built in: FileUploading, Interceptor stack (anything you could think of), Best Taglibs in the Biz, Spring integration, Conversion, Easy sitemesh integration, Velocity views or JSP (Your choice!), easily change the Taglib look and feel (templating), international (what is that i18n...something)..
4) Testing my Action classes (they are POJOS) is as easy as populating a map with pretent request attributes and calling the method in your JUnit test. I can't tell you how handy that is
5) The Spring integration couldn't be easier or better.
6) The taglibs are the best in the business.
Like I said, I have NO Stripes experience, but I have a) built my own MVC framework b) Worked with other homegrown frameworks c) Worked with Struts. All in enterprizy environments.
Matt
If you have a lot of experience with Struts or any other framework, frankly, there is little reason to move on to another one. Almost all of the frameworks are usable and useful, and after some amount of experience you learn the techniques and idioms to work around whatever it is that may be lacking in the framework. That's simply the nature of the game.
So, given that, any experienced Struts person would find little reason to move to something like Stripes, and moving to Struts 2, may be a worthy upgrade as long as a majority of your original Struts experience isn't tossed out with the changeover. Otherwise you may as well pick any framework.
That said, however, Stripes has the simplicity to get you moving quickly as a novice, yet also the depth to keep you there once you've passed the initial bump on the learning curve.
It's particularly good with its binding framework, and most everything works as one would expect. But more importantly, most everything works as a novice would expect.
The other benefit of Stripes is that by being a recent development, most of its examples are very young. Whereas Struts has approaching 7 years of maturity, it's also got 7 years of "old examples" floating about the web.
Struts came before modern JSP, JSTL, EL, etc. Much of these modern technologies were directly inspired by Struts, and they're much better for it. But using Struts with code circa 2001 is simply not how one should code today.
No doubt Struts 2 example are more modern. But when searching for examples, aid, etc. on the net for Struts, much of the advice is old, and for the original frameworks. And for a novice, it makes finding information that much more difficult.
Stripes has a few Form tags and a simple layout manager. It also has some annotations for the action classes. But other than that, it's stock JSP, JSTL, and EL. It works very well in that environment, and that's how Stripes is presented. This makes for, again, fast pickup and quick results -- both for novice and experienced user alike.
I don't mean to dump on Struts 2, I have no experience with it. I was unhappy with my experience with original Struts and that's what led me to Stripes in the first place.
If you are already happy with Struts, there's really no need to look anywhere else (unless you want a component framework vs an action framework). But if you are new and considering Struts, then Stripes deserves a hard look I think.
In response to Matt's "things S2/Webwork has that Stripes doesn't"
1) In stripes, you configure in the web.xml which packages you want to have stripes look for actions in, and each class it finds that implements ActionBean, it automatically registers as an ActionBean. This seems better than having to create XML files with definitions for each action, but maybe I'm missing your original point.
2) No, stripes has no AJAX taglibs. I've never seen the need for them because prototype makes AJAX pretty simple, but I've only done some basic AJAX.
3) Wow, there was a lot in there for #3, so I'll break them down:
a. File Uploading - It's dead simple, it's in the How to's.
b. Interceptor Stack - Stripes has Interceptors, it's in the How-To's.
c. Not sure which part of the taglib that you are referring to, but I've found stripes form taglib to be easier to work with than webwork's.
d. Spring Integration is also simple and covered in the How to's. Annotate your setter with @SpringBean and it gets injected from spring.
e. Stripes provides a layout framework that is easy to use, but you can also use sitemesh if you wish.
f. Stripes can be integrated with freemarker, and I'm not sure about velocity. Stripes takes the approach that JSP has come along way, and with the help of some simple tags can be easy to use. When I first started using stripes, I though the same thing, I would rather use freemarker. But rather than swim upstream, I decided to go with the flow and use JSP, and I don't view that as a limitation. If you are dead set against JSP, I don't recommend stripes.
g. Does not have templated look and feel tags that will automatically wrap your HTML input fields in table cells. I never liked this about webwork, I would rather just have the tags generate the HTML input fields.
h. Stripes has first class, easy to use i18n support, well documented in the how to's.
4) Testing actions is easier in stripes than in webwork, IMHO. The reason is that stripes actions do not depend on any of the HttpServlet API, everything is abstracted away in the ActionContext, which can be easily mocked for testing.
5) see 3d.
6) I like stripes tags better than webwork
The first Java web MVC framework I used was Struts. I was never happy with struts. Then I used Spring MVC. I was pretty happy with this and used it for a while. I didn't really spend a lot of time looking at other frameworks because Spring MVC met my needs. Then one day I tried out webwork. I liked it better than Spring MVC. I liked the idea of one action instance per request, the way interfaces were used, it definitely seemed, as I remember someone put it, less "clunky" than Spring MVC. But there were still a few things about it that bothered me.
Then one day I tried Stripes and the annotation-based configuration had me hooked from the start. It seems to go along perfectly with hibernate annotations, and I liked the trend of moving most configuration from separate XML files to typed annotations. Everything else about stripes was just icing, and there were no features that webwork had that I felt stripes was missing.
I was using stripes 6 months ago, when S2/Webwork was just being talked about. I found it really hard to follow what was going on with S2/Webwork there for a while. Then it finally came out, and I started perusing the docs and read about struts.xml. I was shocked to see that, I thought for sure the S2/webwork team would have learned from Stripes, Hibernate and other framework and done away with unnecessary XML configuration in favor of annotations.
I know "zero configuration" is a feature in development for S2/webwork, but for me, this is a big feature, and Stripes had for at least 6 months, probably longer. At this point, I'm happy with stripes and I see no reason to switch back to S2/Webwork, even when they do get zero configuration implemented.
Where can I get an example application of Struts 2?
I downloaded Struts 2 but the blank, mailreader apps are not getting loaded.
Regarding Struts 2 Samples: Can you check that you downloaded the *full* Struts 2 package as there is a very comprehensive set of samples there, including Ajax , JSF, Validation and Integration with Spring.
What do you guys think about ww vs stripes regarding security?
I have only used webwork, and the way that the request parameters are automatically bound to the objects on the action causes me a security headache (any getter methods on the action are open to attack from the outside world).
I cant figure out an elegant workaround in webwork.
I see that stripes has considered this in their design, so I'm considering switching for my next project.
Any thoughts?
Struts 2 performance.. UGHH..
http://javajmc.blogspot.com/2006/10/webwork-and-stripes-simple-performance.html
Stripes is definately worth looking at, and for all the same reasons that Struts 1 was so successful: its a better screwdriver, it's fast, it's simple, it's flexible, and it's in the right place at the right time.
Struts 2 has a ways to go. I wouldn't touch it for another year or two.
If you're building webapps now, you should be using Stripes.
If you're making career decisions by speculating on which framework will win these wars, then you're wasting your time. Stick with Struts 1, they'll be plenty of work for you for quite some time.
asdfasdf
I see both Struts 2 & Stripes have its own advantages.
Definitely Struts 2 is much better than Struts 1 in terms of simplifying its configuration, using JavaBeans instead of ActionForm, providing its great interface to ajax, webwork or jsf if you want. In its core library, it provides dojo packages for easy & great interface to ajax. It's also very easy to interface with Spring and Hibernate. I have a CRUD demo at http://essay.andrewnguyen.net/
With Stripes, it's a lightweight framework for sure. It's using the advantage of Java5 with design annotation driven so the configuration is very simple, no need to do a lot of setup up-front like any other frameworks. However, when I cook it with Hibernate and Spring, it looks complex to me. I guess that's why Stripes wants to have Stripernate out there to help its framework light as it's.
One thing I notice is Stripes has less UI components than Struts 2. Things like dynamic tables (datalist) which I could do in JSF, Tapestry and Struts 2 but not in Stripes. Also, I would like to do more in ajax, when using Stripes it doesn't help me much apparently.
http:
//comunidadstruts2gratis.
blogspot.
com/
Hi,
thanks for information (article&forum), since now I am in the middle of choosing the rigth web framework Struct 1 or 2 or even something different.
Thanks again.
hor.ses.