Slashdot Mirror
Struts Survival Guide
Wilson Fereira writes "The Jakarta Struts framework is undoubtedly the most popular MVC framework for developing web applications in J2EE. A lot of books have emerged to satisfy the appetite of avid Struts reader including the two famous books from O'Reilly and Manning Publications. Struts Survival Guide: Basics to Best Practices (SSG) is a new addition to the already growing list of Struts books. SSG is from a new comer in the publishing business - ObjectSource Publications." Read on for the rest of Fereira's review.
Struts Survival Guide: Basics to Best Practices
author
Srikanth Shenoy, Nithin Mallya
pages
224
publisher
ObjectSource Publications
rating
8
reviewer
Wilson Fereira
ISBN
0974848808
summary
A short but valuable guide to the Jakarta Struts framework.
The fun starts from Chapter 4 onwards. Chapter 4 covers advanced Struts concepts and presents some interesting ideas about Struts Action design. Of particular interest are the coverage of how to protect your JSPs from direct access, using SwitchAction to navigate between multiple Struts modules. The different mechanisms of Action chaining and scenarios where Action chaining is not recommended is also an enlightening read. One of the controversial points in the book is that author discourages you from using XDoclet and explains why XDoclet is not a great idea with Struts.
Chapter 5 covers the validation in Struts. It is the shortest write up on Validation I have ever read and yet it beautifully explains the Commons Validator and its integration with Struts. In the context of validation, the author also explains when to use DynaActionForm and its derivatives and when not to.
Chapter 6 deals with Struts Tags. Reading this chapter was such a refresher. Other books on Struts have bored me with details of each attribute of each tag in Struts. I find this approach non-intuitive since that information is supposed to be a cross-reference and available on Struts web site anyway. Not so with this book. This book takes the approach of explaining the basic tags by example. In chapter 6, the author dives straight into practical aspects of building web applications with Struts. One of the very first illustration is why and how to modify BaseTag (the one that renders ) to suit the real life deployment scenarios. Next the chapter takes up one of the serious issues with check boxes regarding their state and provides a solution. The chapter provides technique for seamlessly integrating JavaScript validations with Struts validation. A lot of Struts web application that we develop do not use plain buttons. Instead image buttons are used. Perhaps the author was very aware of this fact and the lack of support for image based form submissions in Struts. That is why the chapter and the book has frequent references and solutions for dealing with Image buttons. It all starts in this chapter with a great introduction and some classes that make the form submission on the JSP transparent to the Action classes.
The Chapter 6 provides little details on the Struts Bean tag library except for dealing with multiple resource bundles and some design tips. Perhaps the reason is that the bean tags are so straight forward and covered well in the Struts web site. Another highlight of the chapter is a short yet great coverage of JSTL as a background for Struts-EL. The JSTL is introduced in the context of Struts Logic tags as a solution to deal with convoluted and and confusing nested tags. The section on Struts-EL is really short and could have been more.
The creme la creme of Chapter 6 is the section on dealing with List Forms. Sometimes you often have to deal with Forms with collection, edit the collection or delete the collection. Developers are confused on this topic as is evident from the postings in Struts mailing lists. The author does a great job of resolving the mystery surrounding editable collections in Forms. The author also does a great job of integrating the Pager Taglib from JSPTags.com with Struts and how a high performance page traversal mechanism can be set up based on the ValueListIterator pattern (Core J2EE Pattern) and database specific mechanisms.
Chapter 7 is a very decent way to learn Tiles. Tiles can be very confusing due to its capability to achieve the same thing in numerous ways. The author sticks to just one approach of using Tiles with Struts and defends why that is the best approach. The pros of this approach are there are confusions and the learning curve with Tiles is flattened. Coverage of Tiles Controller is missing and is desirable.
Chapter 9 on Exception handling in Struts deserves some mention. It is one of the best exception handling chapters I have ever read. Most other books on Struts limit their exception chapter to explaining differences between Checked v/s Unchecked exceptions and telling how the tags work in the struts-config.xml. The coverage of Exception handling in this book alone is worth the price of the book. It provides a solid framework to handle Exceptions in Struts, log them in a centralized manner and report and alert in a production environment.
Chapter 10 is for folks who want to customize Struts and reap its benefits in design and development of production systems. It presents four examples of how Struts can be effectively customized. The best among them was how to how to handle duplicate form submissions in a generic manner. We all have to deal with duplicate form submissions in daily life and handle them on use case basis by using the Synchronizer tokens. The technique illustrated here no doubt relies on the Sync token but uses it a very ingenious manner, presents a generic Action class. I liked this technique. Other techniques I liked are that the chapter provides a Dispatch Action like functionality for Image based form submission. The DispatchAction in Struts is great, unfortunately I can use it only under certain restrictions. One of them is that the all of the buttons have to have the same name. This technique removes that restriction and opens a world of possibilities for designing cleaner applications while providing enhanced user experience.
If there is a feature in Struts which is not the best way to attack a problem, this book tells you that. The chapters are also interspersed with design tips for designing your Struts application better. In summary, this is a pragmatic Struts book and a highly recommended read for developers and architects already familiar with Struts. You will certainly pick up quite a bit of Struts tricks that will help you design better Struts applications. If you architect, design and develop Struts based applications for your living, do yourself a favor - Go buy this book. Even if you don't know Struts, you can learn it fast with this book. The only requirement is that you should already know the basics of how to develop J2EE web applications.
Even before I started reading the book, the fact that stood out most was its pricing. The book costs $14.95, and is great buy for everybody and especially students. The book is light -- just 224 pages -- and is an easy read. The authors' style is neither dry nor humorous, but very convincing and developer friendly. Bottom line: It does not put you to sleep.
There are two aspects to any framework: the first aspect is the features of the framework itself; the second aspect is how easy it is to use them effectively. This book does justice to both aspects of Struts. It covers enough framework features to justify its title, starting from bare bones and then slowly guiding you to more advanced topics. In addition, there are chapters dedicated to dealing with variety of scenarios in web applications where Struts can be used to solve the problems effectively. This is the area where the book shines.
Chapter-wise reviews The book starts off with an excellent introduction to MVC and how Struts fits into MVC. It then explains the basics of Struts very well and develops a hands-on application in Struts in the first three chapters.
The fun starts from Chapter 4 onwards. Chapter 4 covers advanced Struts concepts and presents some interesting ideas about Struts Action design. Of particular interest are the coverage of how to protect your JSPs from direct access, using SwitchAction to navigate between multiple Struts modules. The different mechanisms of Action chaining and scenarios where Action chaining is not recommended is also an enlightening read. One of the controversial points in the book is that author discourages you from using XDoclet and explains why XDoclet is not a great idea with Struts.
Chapter 5 covers the validation in Struts. It is the shortest write up on Validation I have ever read and yet it beautifully explains the Commons Validator and its integration with Struts. In the context of validation, the author also explains when to use DynaActionForm and its derivatives and when not to.
Chapter 6 deals with Struts Tags. Reading this chapter was such a refresher. Other books on Struts have bored me with details of each attribute of each tag in Struts. I find this approach non-intuitive since that information is supposed to be a cross-reference and available on Struts web site anyway. Not so with this book. This book takes the approach of explaining the basic tags by example. In chapter 6, the author dives straight into practical aspects of building web applications with Struts. One of the very first illustration is why and how to modify BaseTag (the one that renders ) to suit the real life deployment scenarios. Next the chapter takes up one of the serious issues with check boxes regarding their state and provides a solution. The chapter provides technique for seamlessly integrating JavaScript validations with Struts validation. A lot of Struts web application that we develop do not use plain buttons. Instead image buttons are used. Perhaps the author was very aware of this fact and the lack of support for image based form submissions in Struts. That is why the chapter and the book has frequent references and solutions for dealing with Image buttons. It all starts in this chapter with a great introduction and some classes that make the form submission on the JSP transparent to the Action classes.
The Chapter 6 provides little details on the Struts Bean tag library except for dealing with multiple resource bundles and some design tips. Perhaps the reason is that the bean tags are so straight forward and covered well in the Struts web site. Another highlight of the chapter is a short yet great coverage of JSTL as a background for Struts-EL. The JSTL is introduced in the context of Struts Logic tags as a solution to deal with convoluted and and confusing nested tags. The section on Struts-EL is really short and could have been more.
The creme la creme of Chapter 6 is the section on dealing with List Forms. Sometimes you often have to deal with Forms with collection, edit the collection or delete the collection. Developers are confused on this topic as is evident from the postings in Struts mailing lists. The author does a great job of resolving the mystery surrounding editable collections in Forms. The author also does a great job of integrating the Pager Taglib from JSPTags.com with Struts and how a high performance page traversal mechanism can be set up based on the ValueListIterator pattern (Core J2EE Pattern) and database specific mechanisms.
Chapter 7 is a very decent way to learn Tiles. Tiles can be very confusing due to its capability to achieve the same thing in numerous ways. The author sticks to just one approach of using Tiles with Struts and defends why that is the best approach. The pros of this approach are there are confusions and the learning curve with Tiles is flattened. Coverage of Tiles Controller is missing and is desirable.
Chapter 9 on Exception handling in Struts deserves some mention. It is one of the best exception handling chapters I have ever read. Most other books on Struts limit their exception chapter to explaining differences between Checked v/s Unchecked exceptions and telling how the tags work in the struts-config.xml. The coverage of Exception handling in this book alone is worth the price of the book. It provides a solid framework to handle Exceptions in Struts, log them in a centralized manner and report and alert in a production environment.
Chapter 10 is for folks who want to customize Struts and reap its benefits in design and development of production systems. It presents four examples of how Struts can be effectively customized. The best among them was how to how to handle duplicate form submissions in a generic manner. We all have to deal with duplicate form submissions in daily life and handle them on use case basis by using the Synchronizer tokens. The technique illustrated here no doubt relies on the Sync token but uses it a very ingenious manner, presents a generic Action class. I liked this technique. Other techniques I liked are that the chapter provides a Dispatch Action like functionality for Image based form submission. The DispatchAction in Struts is great, unfortunately I can use it only under certain restrictions. One of them is that the all of the buttons have to have the same name. This technique removes that restriction and opens a world of possibilities for designing cleaner applications while providing enhanced user experience.
If there is a feature in Struts which is not the best way to attack a problem, this book tells you that. The chapters are also interspersed with design tips for designing your Struts application better. In summary, this is a pragmatic Struts book and a highly recommended read for developers and architects already familiar with Struts. You will certainly pick up quite a bit of Struts tricks that will help you design better Struts applications. If you architect, design and develop Struts based applications for your living, do yourself a favor - Go buy this book. Even if you don't know Struts, you can learn it fast with this book. The only requirement is that you should already know the basics of how to develop J2EE web applications.
You can purchase Struts Survival Guide: Basics to Best Practices from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Here's a better struts survival guide:) (Sorry for the flamebait, I've been having another frustrating day developing a struts application...)
Flamebait? There is a point where class creation is a form of redundancy (just the file naming creates redundancy). There is a point where you can go overboard with OO and struts is it.
love is just extroverted narcissism
Then I found this book. I devoured this book in its entirety in a week. Now, I not only know the basics of Struts, but also understand best practices and Strategies in Struts. Lucid presentation, Easy read and great stuff. A very practical book. I already find myself using the code from this book in my current project. And my co-workers think I am a smart Struts geek !
I'd say: variable creation is a form of redundancy as well. Numeric value pointing to a memory location should be enough for most of the people.
One thing that I'd be sure to look for in a Struts book is a section on how to correctly use the word Struts in a sentence of English language.
The issue here is that in some respects, 'Struts' is a singular noun referring to a framework - yet it ends with an 's' tricking many English-As-A-Second-Language-IT-Professionals into thinking that they need to apply rules of plural nouns. In extreme cases, I've heard people take the liberty of removing the 's' completely! as in:
"We will update the Action class of the Strut."
MVC development is convoluted and confusing, therefore it is slow and memory hoggish.
Yeah, right.
Jakarta is in Indonesia. Asscork.
I would be interested in seeing an exposition on server.xml for Tomcat. JNDI and JOCL are two FLAAs (Four Letter Array Acronyms) that strangely, systematically, even mysteriously, undocumented on the broader internet. Smells like...business model
Which is fine; great that they're making a buck somewhere. Please inform my professor so that maybe next semester he won't be giving death march assignments.
I can't complain about the collateral learning going on, though; it really is neat stuff.
He has a point - this is the number one complaint I hear from developers using Struts where I work. Minor modifications often result in a ridiculous amount of changes in other files.
How do JavaServer Faces compare? Anyone use them for a web application yet?
Don't call me a cowboy, and don't tell me to slow down!
I'll stake karma on what you said:
"Struts is such a big over-engineered pile of shit."
Anyone know how Struts compares to Maypole, a Perl-based MVC? I just started reading up on MVCs, and Maypole claims decent functionality can be achieved with as little as 10-20 lines of coding.
Also, while I'm thinking of it, does anyone know of a decent Python-based MVC?
Come one people, feed the troll, feed the troll!
Have you ever made a large scale J2EE Webapp? If you can back up your statements, I'd love to hear it, otherwise your flamebait rating was warranted.
You have a few approaches you can do in these webapps. You can stick to JSP and Servlets. JSP's biggest downside: mixing Java code and markup together is messy and difficult to maintain. For a small scale site, this works out just fine.
One other option: Struts + Velocity. I opted for this approach in a large scale app I just wrote. It's not any slower than JSP, and the code is amazingly maintainable. The learning curve for new developers is kind of steep, but once they get used to it, they love it. xdoclet makes the job of maintaining the struts-config.xml pretty painless. Even if you don't want to use xdoclet, it's a pretty simple xml file.
There are other options also, TurboM2, Cocoon, etc. Struts just happened to fit what I was doing best.
who out of the corner of their eye, read :
Sluts Survival Guide
PC moderators can suck my White pierced, tattooed dick. If you think pride == hate, s/dick/Aryan meat mallet/g.
It usually takes less time to develop you own framework than to learn Struts, J2EE, etc...
Here a quick tip for a simple cluster. Use JMS or another queued message pool. Start as many servers as you need, and let each message be handled by whichever server is available. I was doing this in java in '97 and I still haven't seen a framework that beats it in performance, ease of use, or versatility.
Complicated problems require complicated solutions. Simple problems require php, asp, or coldfusion. Most problems are simple. Use the right tool for the job, but don't complain if the right tool is hard to use. It's hard to use because it does something.
[This sig left intentionally blank.]
Java code and markup together is messy and difficult to maintain
That's why you create/use taglibs! You should never ever ever have java code exposed in a modern JSP page.
"Struts is such a big over-engineered pile of shit."
I was going to mod this Insightful, but then thought, nah. You see, it doesn't go quite far enough. I've used Struts, once, and that was once too many. Repeat after me, children:
Struts is the festering soiled nappy of the bastard spawn of Satan.
Ugh. Now wash your mouths out with soap.
Compared to what? Pure JSP? Maybe if you have like two pages total, but if you have any more than that you'll discover that:
If you set out to solve these problems, you'll inevitably end up at struts. It may do other things (don't know; I haven't ventured in that deeply), but it does these in about as simple a way as anyone could.
I challenge you to find any significant amount of redundant code in a project of mine that uses struts: mb. Description here, browse the code here. There's not a lot of code there, and struts is largely responsible.
Internally, struts may be hugely overengineered...but I, as a user, don't care. It helps me keep my applications more terse and well-organized. (Much more maintainable than what I wrote before.)
Why is mixing Java-code and markup a downside?
... you can just add an offset in the loop and pass it in the url or something like that.... It's done in 15 minutes...try that with your struts and tapestry stuff......
When using struts you have some kind of XML-document in which you cannot see the difference between controll-statements (logic) and markup because it's all in the same format.
That's unreadable and unmaintainable.
The problem with stuff like struts, velocity, cocoon, tapestry etc. is that you have to change stuff in multiple files to change simple behavior.
For instance;
If you have a page with a table of 34983 rows, and you want to split them ("go to next 100 results") in chunks and you created your page with all those fancy framework you have to change stuff in different-files, you have to create a new 'tag' and perhaps you have to "deploy" or what-ever....It's just not maintainable.
In a simple JSP with a for-loop (just java-code) and an iteration which prints a
:wq!
How do JavaServer Faces compare? Anyone use them for a web application yet?
Haven't built anything with them yet, but I've been throwing around the buzzword for a few weeks now.
$30 Off All Plans: Use code TRIPLESAWBUCK
I used struts for a short while on a previous project, it seems to have gotten a little bloated recently though.
A framework I am working with currently is spring.
Spring is a superb framework for Java development and includes a pretty impressive MVC web toolkit as well as many other tools and features. The AOP stuff is very nice and the whole inversion of control/dependancy injection implementation simplifies code drastically.
Ive used quite a few different frameworks, but so far... this one is my favourite.
If you are starting on a new java web app i'd recommend picking up one of the next-generation mvc frameworks be it Webwork2, Tapestry, Spring-MVC, Maverick or JPublish, these are all much better than Struts
Agreed that Struts sucks.
However, try this:
Create your table as you explained.
Now create your table using a tag library.
Now do it on 25 different pages in your website.
1. The inclusion of a tag that does this (like JSTL for loops) is more readable, and easier to understand for presentation people that don't know Java.
2. The code is in one place (the tag library) and doesn't need to be copy-pasted 25 different places, and become a mainenance nightmare if something changes...
Raw Java code in JSP pages should be avoided, as it sucks.
Struts sucks too - too many configuration files. Way too complicated for what it is. JSF looks like it may be a step in the right direction... but not enough.
For instance;
If you have a page with a table of 34983 rows, and you want to split them ("go to next 100 results") in chunks and you created your page with all those fancy framework you have to change stuff in different-files, you have to create a new 'tag' and perhaps you have to "deploy" or what-ever....It's just not maintainable.
But say you wanted to do that several times over different tables with different size results. If you embed a java for loop in your JSP to accomplish this, you have to basically copy and paste your code where ever you want to repeat this behavior.
Tags allow reuse. Copy-and-paste is not reuse.
The problem with scriptlets is that they are so easy to use. They are great for prototyping but, as is often the case in software, prototypes soon become production applications.
I'll say one good thing about struts: the validator kicks ass.
I looked at your code. It looked good. But what kind of real-world Struts stuff have you done, instead of just FOSS messageboards that you put together in your spare time? When you're dealing with real-world constraints like time, money, and requirements from non-technical users, Struts works against you at every turn.
Poor Man's WebObjects.
MVC for J2EE via WOF is what you want, but if you want Linux than one can see the popularity of Struts and other MVC frameworks on none Apple supported platforms.
Apache Cocoon2 Frameworks are much more interesting than Struts, personally.
I know that most of you won't agree with me, but after developing applications in both environments it is clear that asp.net is better than struts in many ways. Of course, it should be seeing as how MS pretty much ripped it off and added to it. The people who make the struts framework have some catch up to do to be on par with what is coming from MS in their next version.
is one config file that hard? or 2 if you include web.xml.
i maintain a very large struts application and struts has made everything maintainable.
PHP is the solution of choice for relaying mysql errors to web users.
We have four mid-size/large apps developed with Struts and this framework saved us a lot of grief. There are plenty of books devoted to Struts, not sure if this one is the best (I personally like one by Chuck Cavaness) but it's good to see that Struts gets the attention it deserves.
I work on a huge internal application, we use struts everywhere.
a well written struts app is very easy to find your way around, especially if you use a good ide.
PHP is the solution of choice for relaying mysql errors to web users.
Yeah right.... So, in your opinion I have to create a tag instead of a simple for-loop (that anyone can read) because I may not copy-paste a for-loop. Every structured program contains loops and stuff (Dijkstra), so why should we add another custom abstraction layer, and (and that's the other downside) a new scope?
:wq!
I agree with you that Velocity is the way to go for Java web applications. We use Velocity instead of JSP for the web presentation layer.
Velocity also excels at being a general purpose templating language - sure, JSP Expression Language gives you some of what Velocity does, but you can use Velocity to process any text, anywhere in a Java application.
Tips and Tricks for Mozilla
There is really only one solution, "Fireant".
Yes i have. But judging by the number of posts on this book review most other people agree with me too.
love is just extroverted narcissism
.. once I discovered echo and echopoint
I haven't looked back since.
To sum echo up:
Write web applications using a swing like API.
-- MartinG To mail me: echo kewyjlcxyzvjfxbqwh | tr bcefhjklqvwxyz
Anyone read both this one and Struts in Action?
If so how do the two compare - is either one better than the other?
Compared to what?
Any basic Model 2 architecture implementation with some custom tags (e.g. from JSTL) and a template set.
If you want "event driven" it should be built-in from the start, like with ASP.Net's "code behind" logic.
(Short summary of Model 2 architecture: A "front controller" servlet which dispatches to JSPs based on state. Preferrably via a template that does includes for the selected content. All JSPs are "hidden" under WEB-INF to prohibit direct access from the outside. Optinal: Lower layers (data access, EJBs, CORBA, SOAP) isolated via the BusinessDelegate pattern and value objects.
Fundamentally, Struts is a refactoring of the basic servlet API, but is still intrinsically operation-based (as are pure servlets).
WebObjects, and it's thematic successor Tapestry are component based approaches, an entirely different mindset. I created Tapestry and I have about two years of Struts experience ... Struts is a straight-jacket. Component frameworks offer incredible advantages in terms of clarity and developer productivity. Struts offers very, very little except a slew of books that have the daunting task of explaining in detail something that should be (was intended to be) very simple.
Howard M. Lewis Ship -- Independent J2EE / Open-Source Java Consultant -- Creator, Apache Tapestry and HiveMind
Thank you. :)
But what kind of real-world Struts stuff have you done, instead of just FOSS messageboards that you put together in your spare time? When you're dealing with real-world constraints like time, money, and requirements from non-technical users, Struts works against you at every turn.
Never used struts at work. But it sounds like what you're really saying is that struts forces you to design a little, rather than just pumping out X lines of code/hour to meet a deadline. A lot of people get forced into pumping out code at work, and I don't think it leads to anything good, regardless of the tools you use. I'm lucky enough to have a boss that stands behind me when I think I need to spend a bit more time doing something the right way. Given that, I'd feel confident about using struts in commercially.
How is struts not that? I tend to use it as something that does just what you've described, plus the validator bit for the HTML forms. There may be additional parts of it that do other things, but they're clearly not necessary because I'm not using them.
Could you give me a specific example of another Model 2 architecture and how it is simpler than struts?
The inventor of Struts has moved on and has been working with Sun to produce a new and more versatile framework called Java Server Faces:
http://java.sun.com/j2ee/javaserverfaces/
This is the framework that is being adopted by all major java IDE designers: NetBeans, Borland, Oracle etc. Fortunately, its not difficult to integrate struts and JSF, but for newer projects, JSF makes sense. It has an advantage in that the GUI doesn't have to be web pages - you will be able to 'plug in' WAP, Swing etc.
I have been using Struts for over a year now, and although I'm over the steep learning curve, I can't help but think there's something simpler.
Some have mentionned Spring, and I'd love it if anyone here could tell me how that compares to Struts, especially if they tried OpenSymphony's XWork or Webwork.
Any recommendations?
Information: "I want to be anthropomorphized"
I have built a successful ($450K subscription revenue in 6 months) production app using Struts. Struts has a steep learning curve, but once you get over the hump, the payoffs are enormous.
I am now embarking on a second app built on the technology of the first one. I spent the last 2 months rewriting much of the JSP side of things, having finally learned how to do things the right way.
I feel the biggest hole to fill in the literature is the tag libraries. I nearly killed myself learning how to properly extend and implement a tag library. The community needs a whole book just covering the usage and customization of Struts tags.
Having survived that ordeal, I now have nearly 100% scriptlet-free JSP. Scriptlets in JSP is like cancer. You don't realize how badly it is infected until you try to remove it. I have dubbed the term "page global variables", in reference to the usage of variables defined in one JSP and then used by included JSP fragments. They are as insidious as good old-fashioned C globals.
"No matter where you go, there you are." -- Buckaroo Banzai
What did struts help you out with?
....) { .... myForm.getAttributeX();
There's lots of MVC jibba jabba from Struts foo's, but you don't need Struts for MVC, and using Struts means you have to put up with its many questionable design choices:
1. Singleton Actions.
I've read that this was due to performance, but that seems rather silly. If instantiating a form bean and populating it via reflection is acceptable, why is creating an instance of an Action a problem?
2. Decoupling Actions and Form beans.
Frankly, the seperation of Action (behavior) and Form (data) seems anti-OO. Doesn't anyone else cringe when they see the following standard struts idiom?
public ActionForward doStuff(ActionMapping m, ActionForm form,
MyFormType myForm = (MyFormType) myForm;
}
3. Reflective population of form beans, no mechanism for describing how to create a form in a valid state.
Bad idea. No compile-time checking, nothing resembling pre-condition declarations, and consequently code that is very sloppy and difficult to test (how many possible states does a form bean have?). Also, potentially insecure, particularly when a Form bean is used for only some of its attributes by an Action. What happens if someone builds a "hostile" http request?
4. XML config.
I could never understand this. What's the value of defining the action forwards and dyna action forms in another language (ie the config XML) that is not programmatically accessible from the Java code? Its not like you can change struts config without changing the corresponding Java.
Taglibs are a (cumbersome and overly verbose) syntactic sugar for scriptlets.
There are very good environments (Eclipse and others) that provide excellent tools for writing and debugging java classes. I am unaware of tools that do the same for JSPs - which, frankly, are a supremely overated technology.
All this worry about mixing html and code... what, are you guys writing pages using Slashdot-style HTML 3.2 from 5 years ago?
If you really want to seperate presentation from content, design your pages using CSS and XHTML 1.0 Strict. Your markup will be so simple that you can generate it from your servlet.
I frankly wasn't all that excited about struts. ... so even if the idea itself wasn't bad to begin with, it will turn to crap once
What pisses me off is that whenever
the apache project approves an idea,
no matter how crappy, it gets a TON
of attention
it becomes part of the apache project
don't get me wrong, the apache project has tons of great software, I just don't think struts is one of them
In this case, you are not tagging the for loop. You are tagging a specific browsing behavior(view N things at a time). And even if it were a simple for loop, using tags instead of scriptlets exposes iteration variables that other tags might want to use whereas you cannot easily get at local scriptlet variables.
My point is tags are a good thing and should be used when possible. Scriptlets are the main reason people say "JSP sucks cause you can still embed Java in your HTML". Tags encourage reuse. Scriptlets encourage haters
Using tags is the same as indirectly embedding java in your HTML. The only difference is that you have to open more files (an XML-configuration, a java-class) to see what it's behavior is. When using just java embedded in your HTML you have everything in just one file.
:) And when using tags you also
Be honest, moving a so called scriptlet to a class, writing a descriptor-file and add some
new syntax (a new tag) to the mark-up-language
is a lot of work. A simple piece of java-code is easier to maintain than all this framework-stuff,
just because it's less code.
Adding some simple functionality is a lot of
work.
And what 's the difference between:
<%=this.is.my.Tag.getHTML()%>
and some fancy XML-syntax!?
Isn't <%xyzzy%> xml-compliant?
When re-use is an issue, you can always use jsp-includes
copy/paste the calls to the tags.
Do PHP-taglibs including XML-config exist?
:wq!
Heh. For the project I'm developing now with Struts I already replaced JSP with Velocity. Much more readable, much easier to write. Also I don't need a fancy web-server (read- caucho resin) to run it fast, Tomcat does the job quite well.
And as for other projects, well, i have my own framework that's WAY better than struts (also using Velocity), and I use it whenever I work with a smaller team that isn't afraid to learn something new. I hope to open source it one day, but well, now it is too far from being in the state where I could put it on sourceforge.
--Coder
Heh, 2 years ago we rewrote a major web application of our company (www.cv.lt) from scrach. We've been happy after that. It was written in coldfusion (on mysql), and it was crap. Way too many problems with no way to fix them, problems with coldfusion server crashing under linux under high loads and so on and so on. Now it's written with java/struts/postgresql.
--Coder
3. Reflective population of form beans, no mechanism for describing how to create a form in a valid state. Bad idea. No compile-time checking, nothing resembling pre-condition declarations, and consequently code that is very sloppy and difficult to test (how many possible states does a form bean have?). Also, potentially insecure, particularly when a Form bean is used for only some of its attributes by an Action. What happens if someone builds a "hostile" http request?
Hmm. Yes, validation & population of Struts forms is one of the parts of Struts that do bug me. But I'd like to hear how you suggest to solve this problem, or see some links to frameworks that do this the 'right' way.
I'm writing my own framework, and I solved this problem a bit differently (with a collection of Parser objects that parse 1 form input element each, and check for errors). Results are stored in a HashMap type structure. But it is gives even less compile time checking. I wonder if it is possible do compile time checking at all- what would you compile, HTML page with the form input elements on it? I kind-of solved this problem by creating composite objects that BOTH output the HTML code, and create the Parser objects, but i'm open to suggestions how it is possible to do it better.
--Coder
I don't usually try and post the same thing a second time to try and get modded up, but the 'Informative' parent post is simply factually incorrect. I am not confused at all. The situation is very clear: JSF is a full replacement for struts at all levels, Model, View and Controller. You are confusing the presentation tags of JSF with JSF as a whole.
A direct quote from the author of struts:
"JSF provides functionality that overlaps that
of Struts (my misconception was that JSF was strictly a UI component tag library)."
You have the same misconception.
I see your point, and good design is essential, but in my experience, good design is as rare as an executive that cares about his/her employees.
The problem is when management hears "Struts" and thinks "oooh, shiny" and then they make you use it without giving you time to use it right. Even though that's the wrong way to do it, that's reality. You rarely ever have enough time to do something right in the professional world, so anything that requires even more time is counterproductive.
I've read that this was due to performance, but that seems rather silly. If instantiating a form bean and populating it via reflection is acceptable, why is creating an instance of an Action a problem?
Let me ask that the other way: what benefit would there be to a different structure? I have not heard those performance arguments (and they do sound suspect), but I don't see any reason to change.
2. Decoupling Actions and Form beans.
Frankly, the seperation of Action (behavior) and Form (data) seems anti-OO.
Well, the important thing about the form is that it's a self-contained entity that knows how it is validated. That's a very OO concept and is useful when you have forms shared between actions. In my case, I don't have any shared forms, so I use DynaActionForms and validate them from the Actions. But it's nice to know I have a way to move that logic out if it becomes a problem later.
3. Reflective population of form beans, no mechanism for describing how to create a form in a valid state.
Bad idea. No compile-time checking, nothing resembling pre-condition declarations, and consequently code that is very sloppy and difficult to test (how many possible states does a form bean have?). Also, potentially insecure, particularly when a Form bean is used for only some of its attributes by an Action. What happens if someone builds a "hostile" http request?
I'm not sure what you mean here:
4. XML config.
I could never understand this. What's the value of defining the action forwards and dyna action forms in another language (ie the config XML) that is not programmatically accessible from the Java code? Its not like you can change struts config without changing the corresponding Java.
So you'd just have a method somewhere that builds an object structure? Interesting. That would save them some work parsing. But I don't know that it'd save me any work as an application developer.
unreadable because it looks like a mark-up tag.
<%for (int i=0;i<234984;i++){%>
<tr> blahblah </tr>
<%}%>
Is more readable. The separators are there to alarm the web-design people; "please do not touch this".
2. bullshit; as I said before. When using a plain for-loop you "copy-paste" a decent flow construction. That's no reason; it implies that almost any program is copy-paste-bloatware. When using some kind of tag-lib you copy-paste a flow construction which looks like a markup-tag PLUS you use YAFEFBS (yet another fancy enterprise framework business solution). A web-designer can fuck it up easily by accident. When a programmer needs to change the behavior, he has to dive into the configuration, edit a java-class, compile it and even deploy it, restart an application-server.
And about the 25 different pages; you just should not create 25 different pages if they all contain the same the stuff...
You state that struts sucks because of too many configuration files. You also state that 'raw java' should be avoided, because it sucks. Is that a reason? Why does that suck? I gave a good reason why it does not suck: you can easily distinguish flow control and logic from markup.
The whole problem is the browser. It was never meant for interactive applications. People just started to miss-use HTML: table-tags for doing layout, forms for emulation of normal GUI's etc.
Stuff like all MVC-frameworks just simulate a normal way of programming, but at the end you just have to spit out some HTML which is static and then you do not have control anymore and the simulation ends.
Customers always want fancy interactive applications running in a browser (don't ask me why) so you always have to hack stuff with java-script, pass parameters in the URL to get things working etc...etc... With a framework like struts, JSF or tapestry in between, it's a whole lot of work to just add some simple stuff:
Customer: "I want a help-button in the table-header on screen 1,4,25?"
struts-evangelist: "Err...Hm...I have to add a new parameter to my tag, update the descriptor-XML....hm...I need to compile and deploy the whole stuff....let me think...that's 3 hours work."
nerd: "Ah ok, let's give it a try..." [...]
3 minutes later....
nerd: "something like this?"
Customer: "Yeah! thanks! put it in production, please"
nerd does:All those fancy frameworks just don't work in the real world. Is ebay running struts? is amazon using JSF? is hotmail using tapestry? (And what about slashdot? is it running cocoon and xsl-transformations?
No way....popular, user-friendly, fast and fancy applications are just handcrafted using more flexible tools.
:wq!