Slashdot Mirror
Manning's Struts in Action
What's Needed So it is generally acknowledged that using the MVC pattern is the proper way to build web applications, but with the large number of technologies and frameworks it can be a long road to figure what is the best solution for your application. What we need is a book that covers the best practices of web application design and development from both a technology/architecture perspective, and is written by a few folks who have deep understanding of the underlying problems of building robust web applications.
That's what I love the most about this book, it doesn't just talk about how to configure and develop with Struts. It's a web application manifesto. Anyone can write a book about how to use Struts to build a web application. That's not the point. This book is ~8 people-years worth of first-hend developer knowledge (4 authors x ~2 years of working on the Struts project) condensed down into 630 pages. It doesn't just teach you how to use Struts (and Velocity and Taglibs and Tiles), but why you should use them. That's the most important thing this book has to offer. If your project is looking at using Struts & other Jakarta technologies, you need this book. If your project is currently using Struts & other Jakarta technologies, you need this book.
What's Bad?The Velocity coverage is pretty light. If you are more comfortable building logic with a quasi-shell script language instead of using markup tags, then you should look to the project's documentation for further reference before embarking on a prototype. The Jakarta Lucene project, is touched on in the sample application they build, but are left as an exercise for the reader to investigate. While it's good to bring in related technologies to flesh out your sample apps, you have to be careful not to get sidetracked from the primary topic. You could easily write several books about the other components developed by the Jakarta project.
What's Good?The best part is that the 4 authors are all Struts authorities (one Jakarta project manager, 2 Struts committers, one principal consultant), so they know Struts and the other Jakarta web frameworks inside and out. More than that, these guys have been solving the problems involved with web applications for several years now. They have deep experience in the patterns and best practices of building robust and flexible web applications, and this book passes on their experiences to the reader.
So What's In It For Me?With this book and a little bit of effort on your part, you will be a competent Java web application developer. With a little bit more effort, you will become a Java web application architect. It's worth the extra effort. This is a tremendous book that will set the standard for web application references and will continue to be useful for years to come. It reminds me of the first Manning book I read, Neward's Server-Based Java Programming in terms of it's scope. approach and usefulness.
You can purchase Struts in Action from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
MVC is about design, its about knowing that your application will be maintained by other people. Its about seperating the various elements so multiple people can work on your project. Its about ensuring that elements are re-used effectively so testing effort is used more effectively.
MVC is about projects that work well. So to all those people who just "hack it together on my own", please remember that there are some people out there who do this for a living on sites and system that will still be maintained in 5, 10, 15 years or even longer. That is why you choose MVC, because you realise that Go-Live is only a small part of TCO.
MVC is great, and MDA is even better because it uses similar patterns at an even higher level.
Design is good, design works, patterns work. Just because you can "write 1,000 lines in a day" doesn't mean that in 6 months time even YOU will be able to maintain it. Don't knock it until you've been on a project with 10 people where they all thought they could do it their own way.
Be an engineer, not a script kiddie.
An Eye for an Eye will make the whole world blind - Gandhi
Random MVC joke. Saw a cartoon in a Java mag once where a project manager is saying to his engineers, "For this part of the user interface we can either go with a Swing applet, or ActiveX control." Engineers all chant "Swing!Swing!Swing!" Project manager says, "If we go with Swing, it will require substantial work with JTree." Engineers all chant "ActiveX! ActiveX! ActiveX!"
:) Duane
www.HearMySoulSpeak.com
FYI - Struts is quickly becoming the framework of choice for all J2EE coding houses. Having struts experience is a huge plus on your resume. The other Java tech to watch out for is portals (ie - jakarta's portal engine, or WebSphere's portal engine).
I digress, but I've used struts and the MVC pattern plenty at my job, and it just makes life so easy when adding in new functionality, fixing bugs quickly, and overall maintainability.
Those that say "its good in theory, not in practice" haven't used it correctly in practice.
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
IS MVC really the best way to build web applications? It seems to me that for 95% of the web sites in operation, by the time you finish building the MVC app in Java using Struts you could have coded it 3 times in PHP or Perl?
Does Slashdot use an MVC pattern? MSN? Yahoo?
"For a successful technology, honesty must take precedence over public relations for nature cannot be fooled." -Feynman
I have this book, and JSTL In Action and both of them are truly excellent books. The 11/10 rating is quite appropriate. I have been attempting to convince myself to buy the Manning Ant book as well - just for the documentation on all of the Ant extensions that it includes.
Additinally, Manning Press has experimented with releasing PDF versions of books (in read only if you use acroread or windows, but not otherwise) and this was how I first met their books. (The books were hosted over at The Server Side). Anyway, this was my first intro to Manning Press. I now look over their books before any other.
The think I like most about Manning books is that they are written for smart people who have clues. Many tech books feel the need to explain basic concepts of programming in every single one, Manning doesn't bother - they stick to the topic on hand, they write as if the audience has a clue, is intelligent, and has real work to get done.
IMHO using Struts (and web applications in general) you cannot build true MVC based applications.
The MVC model defines more communication options and knowledge between objects that Struts is able to provide. MVC is event driven, a Struts application is driven by actions (post or get).
The Structs framework, as I understand it, in general works like this:
- A http request is sent to some dispatch. This dispatch converts the request into an 'action'.
- The action is executed and returns a new request, either for a JSP or some other Template to be rendered or a new action.
Using MVC a view contains components that have corresponding controllers. The view is usually a predefined API to a collection of widgets (like AWT, Swing, etc.). The controller is built of events bound to the widgets.
Struts calls the jsp's the view, the actions the controller and the back-end or business logic you define the model.
However MVC allows the model to interact with the view, and there is no way you can be sure you will be able to do so with a web page, because HTTP only supports polling and not pushing if you want to keep things browser independant.
Well that's why I would not dare to say Struts implements MVC for web applications, but I must admit it provides a very nice framework.
giel.y contains 2 shift/reduce conflicts
I really like the O'Reilly book that just came out. Most of the chapters of this book went through public review, if I remember correctly. The book is very solid.
The real advantage of struts for me comes from its ability to handle forms. Regular expression checking of input is a great way to make sure you don't take in bad data. Not having to write this code, and code to handle and repost the page when errors occur, takes away a lot of the tedium of development.
What I don't like about struts is all the abstractions. New developers should start with the basics and work up. But no one has the time for that. So figuring out what is going on under the covers is hard to do. The O'Reilly book is pretty good at trying to explain some of this stuff. But there's no substitute for actually doing it.
And is it just me, or has 'real' coding started to go away? I spend half my time messing with xml config files anymore. I get more done, but it isn't as much fun.
I don't think anyone will claim you have to use third party applications to create an MVC-based web app. In fact, if you look at the core of Struts, it's rather simple (which IMHO is what makes it so nice). Any decent java developer could write something similiar and many have.
I think the point is, why go it alone? When you can have hundreds of developers all working on and testing the same framework you end up with a lot more features and much more stable code. Sure I could write my own controler servlet (which is what Struts mostly is), but personally, I don't really want to have to write up the validation scheme, the internationalization features, the tag libs that make it easier to work with, and so on. With Struts, it's all there to begin with and it works. Additionally, when I hand over a Struts project to another developer or team, I can just say, "Oh, it's Struts based" and immediately they have access to host of documentation and an entire user community for support. I don't have to sit down and teach them how my special MVC magic works.
I could go on, but I really find using a popular stable project like Struts has a lot of advantages. And yes, Struts is not perfect. There are lot of other good frameworks out there. It just so happens that Struts is very close to how I and my coworkers developed web apps to begin with, so the convertion factor was minimal and the gain was incredible.
Who said Freedom was Fair?
You're right that simple MVC webapps are easy, but the easiest approach is actually the one described in this article by Govind Seshadri.
:)
...and the methods are automatically called depending on the value of 'f'. Like you said, "Of course some actions can be used for more than one thing if you code smartly.", and in this case the smartly was done for you ;)
What your approach misses that you get from Struts:
- validation of form submissions (to java types, regexps, whatever)
- automatic population of form beans, which leads to...
- automagic prepopulation of forms from beans used earlier in the session (with struts custom tags)
- tool support for designing complex sites (there are lots of GUIs for struts these days)
- you don't need to write or maintain any of the framework
Every framework brings with it some constraints in how you work, but pays off in spades if you use all the features. Struts is no exception. If all you're doing is the stuff you describe, Govind's article might improve your life a little. If you build complex sites, Struts will simplify your life a lot.
Just a quick concrete example: in struts, the equivalent of the IndexServlet you describe is the DispatchAction. You'd configure like so:
Then you can write:
package funky;
class IndexAction extends org.apache.struts.actions.DispatchAction {
public ActionForward login(...);
public ActionForward mainmenu(...);
public ActionForward saveform(...);
public ActionForward etc(...);
}
-Baz
It seems to me that for 95% of the web sites in operation, by the time you finish building the MVC app in Java using Struts you could have coded it 3 times in PHP or Perl?
This comes up from time to time and I think it's a good question. There was an good discussion about this on the jakarta-general mailing list. It's a long thread, but if you'd like you can start reading at this point. The best part of it I think is this response by Jon Scott Stevens:
Java is not the fastest technology to develop in, however, it produces the best code for the long term.
PHP is the fastest technology to develop in, however, it produces the crappiest code for the long term.
I develop Scarab in Java because it is going to live far longer than I do and needs a solid base to work from.
I develop my bar's website in PHP because I just needed to get the job done quickly and was not concerned with code quality.
Remember, PHP originally stood for Personal Homepage Parser. Java's web application technology was designed from the start to be a solution for a large "enterprise" class web site. You can do more with Java but you definitely take a hit in initial development time. Personally I feel that in the end, Java is easier to maintain and extend (but you may disagree).
By the way, Yahoo! didn't go with Java because of the Java threads implementation on FreeBSD. It didn't have anything to do with the merits of the java language. (See Why not JSP, Servlets, or J2EE?)
Who said Freedom was Fair?
you still have a big pile of servlets that does everything from database access to presentation.
If you end up with a big pile of servlets like this then you aren't using the framework properly. No framework is going to save stupid developers with a bad design. It can try to save them from themselves, but ultimately, the developers have to have a clue about how to code and how to properly design an application.
Who said Freedom was Fair?