I had heard complaints from other developers that of the few Struts books available, more than one was just a rehash of the online documentation. You said in another post that wasn't your intent. What makes your book different and do you get into design considerations like pro's and con's of using the 3 different forms of validation with Struts?
I know the feeling. That is one of my frustrations when buying books. I think with my book there a couple of things that help it stand-out.
1. The premise of the book starts with a discussion of common web development anti-patterns. I try to identify these anti-patterns and talk about how web development frameworks can help resolve these issues.
In terms of Struts specific issues, I try to talk about some of the specific design issues (i.e. putting to much business logic in the Action class) that I and other people I have talked to have run into when putting together Struts-based applications.
2. I try to bring a discussion about design patterns and Struts into the book. One of the most common problems I see with new developers to Struts is that they don't realize using Struts does not mitigate their responsibility in "architecting" an application.
Struts is a presentation-tier framework and you still need to think carefully about how you are going to build an application before diving into Struts. Otherwise, you can find too much of your application logic tied into the Struts framework.
Good design is often about simple principles applied at the right time and place. These are all topics I address in the book.
3. I do spent a great deal of talking about the different type of ActionForm (Standard ActionForms, DynaActionForms and HashMap ActionForms) and validation mechanisms that are available in Struts. I talk about using the Validator framework and specifically when and how you should write your own validation rules. Chapter 7 of the book deals with a great deal.
I will admit that I do not dive into the full detail of the Validator framework, but I try to provide enough information for the developer or tech lead to make their own decision about what is going to work for them.
Really what I wanted to do with my book is try to articulate my own experiences with Struts. When I say I do not want to re-hash the manual, what I am really getting at is I don't want pages upon pages of API specifications. (And I am not targeting any one specific Struts book in general).
I want to see the author's personal experiences. That is where a lot of the real fun in understanding.
Hope that answers your questions.
John Carnell - Senior Engineer, Genesys PureCloud Division
Author of Spring Microservices in Action
I have used struts for a long time (yet i'm a beginner .. ) and I consider it great. Though, there are some things that always bother me when working with it. One example, even for a small or small to medium application, the number of classes forms and actions that I have to write increases dramatically and it is more and more difficult to keep track of them. Also, I found quite annoyng at times when I try to use a form as a holderbean for my objects, and I realise that due to one thing or another I can't actually use the formbean and have to create a new "plain" javabean in order to hold/carry my data. This comes with name collision, another class added to the already bunch of classes, etc. Maybe it seems that a little extra discipline/work will do but even like that it's not the elegant way in my opinion.
By any chance do you address these "issues" in your book? Moreover, as I couldn't find a good book/tutorial on struts+ejb do you touch this architecture in your book? If so, I'd be very interested to hear some advice regarding when/how do do it effectively.