Slashdot Log In
Manning's Struts in Action
from the truss-and-beam dept.
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.
Who still uses structs? Tapestry the way to go :) (Score:3, Informative)
People considering using structs might want to take a look (as you always should) at alternate technologies... The one I might suggest would be Tapestry [sourceforge.net] with IDE integration with Eclipse through Spindle [sourceforge.net].
Re:Who still uses structs? Tapestry the way to go (Score:3, Informative)
If you come from a Swing background, Tapestry is way more intuitive than Struts. You have components in both, and building your gui involves putting components in components, and finally into a frame (Swing) or a page (Tapestry). You don't have to care about how the JTable (Swing) or Table (Tapestry) components are implemented, you just follow the API and use them. I really don't see the similarity between this and JSP or Struts.
I think Tapestry is the only free Java framework out there that actually allows you to really build components rather than pages (as it is in most of the rest). You can build a component to edit the user preferences, for example, and it really does not matter which page or another component you put it in, how you put it in, and what the layout is. It IS Swing for the web.
It also has a lot of other things that are worth using, but for those check the Tapestry home page [sf.net].
Re:Who still uses structs? Tapestry the way to go (Score:3, Interesting)
Web application security papers (Score:2, Informative)
www.cgisecurity.com/lib [cgisecurity.com]
MVC to all who say "I just write..." (Score:5, Insightful)
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.
Re:MVC to all who say "I just write..." (Score:3, Interesting)
I'm sick of children that say "Hell, I coulda done that in like a week, not 3 months!" This is the difference between coding all hours of the night and true professional development.
This is, unfortunately, an issue with several open source projects. Someone just starts slapping code together, and more and more people jump in and have coding binges over the weekend. What do you end up with? A bowl of spaghetti code that only the original writers can understand.
If major design was implemented from the start, a lot of open source projects would be easier to help out (I hate to say this, cause it will sound like a troll, but slashcode really needs rewritten from scratch with a better design than what it currently has. Honestly, if it was well written, I think a lot more people would be willing to pitch in and help out.)
Re:MVC to all who say "I just write..." (Score:4, Interesting)
You may mean PHP, I guess? I agrre, it's complete mess of spaghetti.
But in a defence of open source project (especially based on something else than on proprietary java) I would address you to Zope [zope.org]. You'll find a very good technology design without all that EJBish overbloating.
When you run Zope, please check you memory. Compare it to what you have with Struts/JBoss on an equal load and equal functions (and equal dev time). In my case the difference was 10 MB vs 100 MB for a mid size applications.
After that compare you code just to enjoy that your application code in Zope is even more readable and better mainanable than in Struts.
I began to hate EJB specifically and Java generally when I've been introduced to Zope and Python.
Parent
Re:MVC to all who say "I just write..." (Score:3, Interesting)
I have found that I have made the Python round-trip.
I haven't used Zope, but for general programming..I have found my programs to build up quicker using python.. but , even when push comes to shove.. my java apps are more maintainable. Agreed that JAVA is a bit of a pig, but it's a VERY structured language. Having soft-types in Python seems to be what kills me in the long run, my programs tend to be more 'brittle'.
Also, using tools like ANT and now my new golden-child of IDE's , Eclipse.. I find JAVA wasn't as bad as I thought..
I can also use Jython anywher ein my java apps if desired.
Agree 100% (Score:2)
I still call myself a programmer, though, not an "engineer". Engineers build bridges, I just write programs.
Re:MVC to all who say "I just write..." (Score:3, Insightful)
Fie on MVC (Score:2)
The M is fine, the V I have no problem with. It's the "C". Frankly I haven't seen a decent tutorial treatment of the awful mess that is the "controller". Is it business rules? Is it input events? Is it update events? Is it a mediator? Is it just everything that doesn't seem to fit in the other two categories? Everywhere I look to read up on MVC, I see a lot of handwaving about how it's God's Own Architecture, but aside from basic "duh factor" things like "decouple the view of the data from its underlying representation", I really have yet to see anything that gives a clean design for this mysterious "controller".
Doesn't help that MVC for widget sets has been abandoned for Morphic in Smalltalk, at least the research variant of it that Smalltalk's founders still follow.
The thing about MVC (Score:4, Insightful)
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
Why use struts? Just do it yourself. (Score:3, Interesting)
Basically I have a master url such as: http://mywebsite/servlet/IndexServlet (lets just say).
The master servlet always takes in an "f" parameter to determine state. f=login , f=mainmenu, f=saveform, etc...
It uses that f parameter to pull out the proper "Action Object" (or control) from a stored hashtable that is initialized once. Then it executes that ActionObject (or whatever you choose to call it) which handles the other parameters (other than f), does what it needs to, and pushes out the proper JSP "view" of your choosing.
This could be simply displaying a form, saving a form to database and displaying a success page, yadda yadda yadda. Of course some actions can be used for more than one thing if you code smartly.
I have saved eons of time doing this this way, making my "ActionObjects" as reusable as possible.
All along security is maintained via sessions.
It's easy, and you don't need third party libs to do it.
Commentary and questions are welcome of course. I expect half of you have come up with some flaws
--Zuchini
If you _want_ to do it youself that is... (Score:4, Insightful)
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.
Parent
Re:Why use struts? Just do it yourself. (Score:3, Interesting)
First, what you've described is only about one quarter of what struts does. A very important quarter, of course; the core of a common web application pattern. As to all the other stuff that struts does, there doesn't seem much point in listing it here. Check the site.
Second, look at what you're saying. You're saying, "I can write code that does what struts does". Sure, by why write code when a good third party library is already there. I could summarize the code required for a simple web server in a few paragraphs, but that doesn't mean that it's a good idea to write one for every new project.
Re:Why use struts? Just do it yourself. (Score:2, Interesting)
You also don't need libraries like log4j for logging. Logging is easy, right? (That's what I thought until I started using log4j. Holy cow, the things my logging can do now...)
But struts has many add ons for form processing, db connection handling, controller options, dynamic form object creation, dynamic validation, error handling, internationalization, page layout, etc. And it makes it easy to make your own add-ons.
So now I can work 1 or 2 days a week, and get everything done that I used to do during the whole week. The rest of the time I can spend playing around with other stuff.
Right now I'm trying to figure out if Java Data Objects are worth while. Right now it makes my code slightly smaller, but adds lots of xml. And I'm suspicious it is slow. But these were some of my same unfounded complaints against struts when I started.
Re:Why use struts? Just do it yourself. (Score:4, Informative)
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
Parent
Re:Why use struts? Just do it yourself. (Score:3, Informative)
<action path="/indexAction" type="funky.IndexAction" name="indexForm" scope="request" input="/index.jsp" parameter="f">
What is Struts? (Score:2, Redundant)
Re:What is Struts? (Score:2, Informative)
Re:What is Struts? (Score:2)
Nothing the stuff in struts is revolutionary, and there really isn't anything there that we have done before Struts came along. However, a good thing abotu Struts is that it is both open and becoming an industry standard. That way, if you come into a new development shop and have Struts experience and they use Struts, you have less to learn about how their application is modelled. If you don't know Struts, then you learn it knowing that the knowledge is applicable at other jobs. I'd say that is it's only, but a very strong, advantange.
Struts is... (Score:3, Interesting)
...the soiled nappy of the bastard spawn of Satan.
Sure, the custom tags make your JSPs look sweet. But what a mess underneath. I think it was something like five or six hops from one file to the next for every request, coming back to the main struts-config.xml file at least twice. That file quickly becomes unmanageable in anything other than the Greatest XML Editor Ever (i.e., not JBuilder!), and I spent around half of my time scrolling through thousands of lines of near-identical XML looking for the bit I had to change.
There might come a point at which all this unnecessary complexity actually starts to make life easier - but it'd have to be one huge project.
Saw it, tried it, hated it, ran away.
More info on Struts in Action (Score:2, Informative)
Also, one of the authours (Ted Husted) will be on-line to answer questions. Note that you need to register - No Anonymous Cowards!
Struts (Score:5, Interesting)
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.
Re:Struts (Score:4, Interesting)
Sun is calling it JavaServer Faces [sun.com]. Principal Struts developer Craig McClanahan is on the committee.
Parent
Can we have a consensus here? (Score:4, Interesting)
Does Slashdot use an MVC pattern? MSN? Yahoo?
Step 1: define your requirements (Score:2)
That's where MVC comes in. It forces to you think about your implementation instead of blindly charging forward. That's overkill for some projects, but IMHO it's absolutely necessary for others (i.e. any project where more than about 2 people need to touch the code). Otherwise you wind up spending more and more time on maintenance/adding features.
FWIW, Slashdot uses more of the spaghetti pattern than anything else...
This is actually a valid question (Score:4, Insightful)
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 [mail-archive.com] 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? [yahoo.com])
Parent
Re:Can we have a consensus here? (Score:3, Interesting)
You can implement MVC in any language. I've built one using PHP that has made development of complex web apps many times faster and easier to maintain than some random collection of pages with SQL embedded all throughout them. One page takes the request, makes the appropriate calls for whatever action is being taken (just a collection of included files, really), and they rely on a series of objects to do the actual heavy lifting - manipulate data, interact with the database, etc. Designers can change the look of the site without ever touching a line of PHP, coders can change the way the backend works without ever seeing any HTML. And once the framework is in place, you never need to worry about it again.
For a simple one-off mailing form or some such, there's no point in the more complex architecture. But if you need to perform many different operations, aren't sure what the client's going to ask for next, and want to be able to change how things look or work without poring through miles of unrelated cruft, it's a godsend.
To a large extent MVC is about injecting a big load of discipline into your work so you only need to worry about the relevant portion of your app instead of the whole spaghetti mess of it. In the short term, you can probably pull something together "that works" faster just by sitting down and coding, but the long term benefits more than make up for it.
Manning Press (Score:4, Informative)
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 [theserverside.com]). 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.
Struts and MVC (Score:5, Insightful)
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.
Re:Struts and MVC (Score:2)
By allowing the model and view to interact you've broken the whole reason for using MVC in the first place. You don't want coupling between the model and the view and that coupling is the point for using MVC.
Re:Struts and MVC (Score:3, Interesting)
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).
By your definition, then, MVC is impossible to achieve over HTTP. You go on to say:
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.
First off I'm not sure you're comparing apples to apples here. MVC in the desktop sense has both different connotations and expectations than MVC in the web sense. Using simple session management (either through cookies or URL rewriting) you can have a de facto state-ful application over HTTP wherein the view is affected by the model.
You seem to be maintaining a rather purist definition of "MVC."
Struts and O'Reilly (Score:4, Informative)
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.
MVC, Xerox, proprietary? trade secret??? (Score:2)
Well, the fourth was supposed to describe the Model-View-Controller paradigm. IIRC the covers of the earlier volumes listed it as being fourth in the series, but it mysteriously just never appeared.
I heard that it had actually been suppressed by Xerox, which felt it was too proprietary to disclose, or something.
It's a pity, because all the descriptions of MVC I've seen have been sorta loosey-goosey and I've never seen a real technical description of MVC as the Xerox PARC envisioned and implemented it.
Anyone know anything more about this? Was the book ever published?
(Has anything about MVC been patented? THAT could get interesting... It's certainly a lot more worthy of patent protection than a lot of software patents...)
"Just write it yourself" and "Perl! Perl! Perl!" (Score:3, Informative)
Velocity is a Java-based template engine. It permits anyone to use the simple yet powerful template language to reference objects defined in Java code.
When Velocity is used for web development, Web designers can work in parallel with Java programmers to develop web sites according to the Model-View-Controller (MVC) model, meaning that web page designers can focus solely on creating a site that looks good, and programmers can focus solely on writing top-notch code. Velocity separates Java code from the web pages, making the web site more maintainable over the long run and providing a viable alternative to Java Server Pages (JSPs) or PHP.
Velocity's capabilities reach well beyond the realm of web sites; for example, it can generate SQL and PostScript and XML (see Anakia for more information on XML transformations) from templates. It can be used either as a standalone utility for generating source code and reports, or as an integrated component of other systems. Velocity also provides template services for the Turbine web application framework. Velocity+Turbine provides a template service that allows web applications to be developed according to a true MVC model.
---------------------
Velocity is dead simple to use, as it is not some kind of entire 'framework' that wants to manage your DB connections, life, etc. It makes using JSP look like masochism. If you really feel like recreating the wheel though, and are convinced that you know better, etc. then feel free to waste your time. I pity the fool who has to maintain your cruft though.
(Would like to be posting more thoroughly on this, but it ain't happening this morning...)
Re:"Just write it yourself" and "Perl! Perl! Perl! (Score:3, Informative)
You obviously don't know what struts is.
Struts is a set of server side components for implementing the MVC pattern, that come with some JSP tag libs as a convenience.
Struts can be used with Velocity. Velocity can only replace JSP, not struts.
FWIW, I love velocity as well. I use it in stand alone applications as well as web applications.
Re:"Just write it yourself" and "Perl! Perl! Perl! (Score:2)
What about the bigger picture? (Score:3, Insightful)
If you're building an enterprise app, however, basing your app on Struts (or any other "web application" technology) isn't a good idea. Why? You wind up mixing your app's functionality with its implementation. Using an MVC framework like Struts alleviates this problem to a great deal, but when it comes down to it you still have a big pile of servlets that does everything from database access to presentation.
That approach isn't scalable, it's not adaptable to different technologies (there's a new webapp framework every week, it seems), it's not easy to integrate with other applications, and so on.
What's really needed is a way to define an application independently of the implementation details. Once you've defined the application, you can generate whatever interfaces it needs - like a Struts UI, an EJB persistence engine, etc. This is where my shameless plug begins: check out the Sandboss [sandboss.org] project for a way to define your enterprise app without being chained to a particular implementation detail like Struts or EJB.
While the techniques used in Sandboss are designed for the enterprise world, they're useful for web apps, too. I think it makes much more sense to over-engineer an application than it does to under-engineer it; overengineering takes more time up front but saves you 10x as much or more once development starts, since the well-don overengineered solution is more flexible and capable of responding to marketing's feature of the week. By picking Sandboss you get the best of both worlds - a robust framework where someone else has already done the engineering. You just define your app, and bam! Persistence, communication, control, the UI are all done for you.</shameless plug>
Re:What about the bigger picture? (Score:4, Interesting)
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.
Parent
Re:What about the bigger picture? (Score:2)
...which is why we need to keep building better frameworks. Struts attempts to point you in the right direction, but it's still fairly easy to abuse. Unfortunately, only a handful of the developers I've seen/heard/worked with actually have a clue on these things; most of them just want to get something built. Design is never a question in their mind - the only important thing is "what's easiest/what's fastest."
By choosing a more powerful framework, the consequences of such an approach can be mitigated. The key piece of a good framework IMHO is that the best way of doing things is also the easiest way of doing things. That way people looking to take the easy way out will wind up producing a better module than they would otherwise. Struts solves many of these problems, but it's still too easy to mush your application's functionality together with its implementation. The Struts doc even says something to the effect of "the obvious way is the easy way, but we don't recommend it." To me, that means the framework needs some help.
MVC on steroids: twisted.web.woven (Score:2)
Get Twisted. [twistedmatrix.com]
Some relevant links (Score:3, Informative)
Struts vs WebObjects (Score:2)
Re:Struts vs WebObjects (Score:3, Informative)
MVC Pros and Cons (Score:2)
Most programmers at least combine the View and Controller--Java supports this rather effectively--and some distinguish between domain and applications models (Visual Proxy pattern).
CGI::Application (Score:2, Informative)
eBook availibility (Score:2)
Dead tree ver. from publisher: $44.95 +s/h
eBook version from publisher: $22.47
Dead tree ver. from B.A.M. $33.49
Publisher site is here [manning.com].
Re:What a big ball of complexity (Score:2)
Re:What a big ball of complexity (Score:2)