Struts Kick Start
What is Struts?
Struts is a framework for developing web applications. It is a distilation of the current set of known best practices into a working code set that can be extended to meet almost any web application requirements. It part of the Jakarta Project at the Apache Software Foundation.
What do I know about Struts? I have been developing web applications, using Java, for four years and using struts for over a year, and am a regular participant on the Struts mailing list. I was also a technical reviewer for one of the other Struts Books released this fall and was recently invited to speak at the University of Wisconsin, Eau Claire on the use of Struts.
What's good about this book? There are many excellent things that I could point to. I particularly like the obvious depth of research that accompanies this book. There is a very interesting history of the development of the MVC design pattern and they even name the inventor. Do you know who invented MVC? If you want to know, buy the book! The chapters cover everything that you will need to know, in the order you are most likely to need to know it. There's even a chapter explaining the "struts-config.xml" file's DTD! (You may want to skip that on the first few readings :-)
There is good coverage of the Struts taglibs. I see a lot of questions about these on the mailing lists, so this information is very timely and it looks very well explained.
I like the coverage of other open source tools that work well with Struts. This is an important point because Struts does not do everything for you (by design), so there will be areas that will benefit from other tools. I'm looking forward to trying out some of their recommendations and easing my own Struts development lifecycles.
What's not so good? Just one niggle, and it's more of a programming style issue, but in their example code they have references to their business objects. They explain that it is important to separate out business logic from action logic, which it is, but then proceed to use their business object within the action.
Now, I realise that example code is not the same thing as robust, production-ready code, but when people are first learning a language or framework, they tend to copy exactly what they see in the book they are learning from. Even though example code should be light on error checking, it should be heavy on correctness and good style.
Should you rush out and buy it? If you are about to use Struts on a project, are new to Struts and need dead tree documentation for those RTFM moments or are evaluating Struts for future projects, then you absolutely need this book.
If you are an intermediate Struts user, then this book would still be very useful to you and I can certainly recommend it.
If you are an experienced Struts user, then you've almost certainly exchanged emails with James or Kevin, on the Struts mailing list, so you can make your own mind up!
Table of Contents
- Struts in Context
- The Model-View-Controller Design Pattern
- Hello World!
- HTTP Protocol
- JSP, Taglibs and JSTL
- The Sample Application
- View Components
- The Controller
- Model Components
- The struts-config.xml File
- How the Struts Tag Libraries Work
- Struts HTML Tags
- Struts Bean Tags
- Struts Logic Tags
- The Nested and Template Struts Tag Libraries
- The Struts Tiles Tag Library
- DynaForms and the Validator
- Using Struts with Enterprise Java Beans
- Using Struts with Web Services
- Building, Deploying and Testing Struts Applications
You can purchase Struts Kick Start from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
What is Struts?
Struts is a framework for developing web applications. It is a distilation of the current set of known best practices into a working code set that can be extended to meet almost any web application requirements. It part of the Jakarta Project at the Apache Software Foundation.
Struts is a Java/J2EE based framework. Although you could change it to use with other languages, it has taglibs and other features that are pretty much Java only.
Why such an influx of Struts books? Its becoming quite the standard in the Java/JSP+servlet world. J2EE developers are still being hired (hear that unemployed CS people?), and have been strong through the IT drought, and Struts experience is an even bigger plus.
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
I still have NO IDEA what struts does. the struts website is not helpful in a brief overview. Saying it helps develop web applications is a joke. What does it replace because I can develop web apps without struts.
Should I be using it? Im too unknowledgeable to even know what question to ask. I use EJB, and I have a webapp. I'm just baffled.
I've been working on a reasonably sized project for some time now (still undercover, so can't go into details)... I'd been looking for a good framework to use, and Struts looked like it fitted the bill.
Until I started dealing with the display (view) side of things.
Getting to grips with the Action and ActionForm stuff is simple, and I think that anyone could do it. However, because they expect you to use all the usual standard stuff (taglibs, etc), building new taglibs and dealing with that was going to be a nightmare.
Also, the HTML taglib, when told to output XHTML only, doesn't work. tags like the BASE tag aren't closed properly.
Fortunately, I'd been looking at using Tea earlier on (Jason Hunter uses it at servlets.com). Someone on the tea mailing list posted a link to a very useful article on using Struts for the backend of a web app and Tea for the front end. You can find it here:
http://www-106.ibm.com/developerworks/library/wa-
http://www-106.ibm.com/developerworks/library/wa-
hehe . . .
Not sure if this is a troll, or intended to be funny . . . but it works on both levels I suppose.
Anyhow, I've been using Struts for about a month refactoring a largish internal Oracle PL/SQL web app, and the MVC separation that's enforced by the Struts framework is really just what the doctor ordered. I'm getting similar functionality in roughly 20% of the comparable lines of code; and this is early enough in the project to where code reuse hasn't even come into play much. I'd imagine it'll end up at about 15% - i.e., 150K LOC using struts as opposed to about a million LOC using PL/SQL.
I know Lines of Code isn't necessarily a good measure of just about anything - but the real benefit is maintainability and ease of expansion (which is what brought on this refactoring to begin with).
Struts is really worth a long hard look - gets you away from using the technologies above and into a real enterprise-class web application structure.
JSF could replace Struts one day, but not for a few years at the least. JSF is still in the early phases, whereas Struts has had several years to mature. I would definately keep an eye on JSF, but wouldn't recommend using it on non-experimental sites for a while.
...or is it that Struts, JavaServer Faces and MVC methodologies merely enforce good coding techniques/styles that one should be using anyway? Regardless of if you are using PHP, Perl, etc.
Or is there something more here?
Sometimes I think Java, OO and other development technologies are like grammer school teachers hovering over our heads saying, "Now, we *know* you are going to be sloppy if left on your own, so are going box you in so that you CAN'T do those sloppy things."
Except that you still can. VERY easy to understand and maintain applications can be coding procedual languages. VERY difficult to understand and maintain applications can be written in OO languages.
But I digress... by nature.
I swear by MacOS X. Although I use to swear *at* MacOS 9...
Hm. I'm not quite sure I follow you here. I haven't read the book, only your review, and I'm a bit puzzled by your statement regarding business objects in actions.
Is it so that the example code for the actions contain business logic directly, or do they use business objects without wrapping them in controllers (like a session bean)
If they're using session beans or controllers in the actions, I can perfectly understand that. You have to use the business logic somewhere.
On my current project, we have a (yuck) flash-client (using macromedia's Flash Remoting MX, btw. nice thing, saves a lot of time usually spent on devicing your own xml-based protocol to communicate with the flash client) . The flash client accesses a standard java class/bean. This bean contains code to massage the output from a session bean to simple data structures more suitable for a flash client (and programmer. Ok, low blow.
The session bean acts as an facade to all the functionality required by/provided to the client (authentication, fetching and updating data etc.) The system has about 10 session beans and quite a few entities.
We've used this approach before, and when we had to add some new types of clients, we only have to add a bean convert to/from client requests and the controller (session bean).
(At first, we only developed a Flash client. Later, we added a SMS client and a web client.)
Not true at all. I've been following Struts for a *long* time and depending on the project it can make a huge difference. Sure, you can code page to page, embed the logic wherever and move on your merry way. But adverse things will definitely start to happen when:
1. you are no longer 'the man' and the mgmt rolls in the html guy(s)/gal(s). most html people can deal with <xml style markup> than <%java scriptlet%> stlye <%blocks%> (i won't even get into logic flow in scriptlet blocks). separation of presentation logic from biz logic; speaks for itself. and it's possible with scripting languages, but tough.
2. you want to extend the app. 'oh, but marketing want's to have their server also come in on that url that you did last year'. true, you could accomplish extension well with scripting language, but the delegation with struts/MVC us much cleaner and more maintainable.
3. you want to debug/qa. struts is tested and kid approved. i'm going thru something right now where our system has bugs and no one really knows cuz different people have worked on each others code and did everything differently. and even on a huge project in the past i had done, it was still hard for me to figure out flows and such when they were scripted from page to page. a unified framework helps resolve those differences in coding and thusly, easier to debug.
And I'm sure there's even more things that I haven't listed. One issue to really consider is do you want a page to page thing - which is good for proof of concept, quick and dirty. Or do you want something you can live with for the next year or so? Using a framework like struts will make your long term much easier.
For the biggest project I worked on, a major airline portal, we rolled our own MVC framework. This was prior to struts and yet in the end, the code was very similar. Their system runs on over 100 Sun CPUs and has been cranking away since they launched a few years back, without a major crash or anything.
This stuff does work and the bigger the project, the better. It's a little tough to get in the beginning, but after you implement it, you start to see that it makes sense. I feel tho, it's definitely more of an 'enterprise' thing than a small 20 page site; altho, u could use it for a small site if you wanted, no problem.
As you get going, there becomes a more elegant technique to using teh language. Tools like struts fill the need.
Learn what you can now and don't worry about it, the usefullness of struts will become evident as you progress.
Computer Science is Applied Philosophy
Well of course it's going to be faster and easier (for you) to just put all of the code in scriptlets. But I sure wouldn't want to have to maintain your code. You don't separate your business logic from your display code because it's faster to develop it; you separate your code to make it easier to maintain, and more robust. Writing maintainable code is always going to be a bit more work in the short term, but it pays off over the long term.
My future's determined by Thieves, thugs, and vermin -- The Offspring