• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Devaka Cooray
  • Knute Snortum
  • Paul Clapham
  • Tim Cooke
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Bear Bibeault
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Ron McLeod
  • Piet Souris
  • Frits Walraven
  • Ganesh Patekar
  • Tim Holloway
  • salvin francis

Pro Jakarta Struts Book  RSS feed

Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
Posts: 93
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi James,

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

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
(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.

Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi John,

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.

[ July 28, 2004: Message edited by: Vali GB ]
Die Fledermaus does not fear such a tiny ad:
how do I do my own kindle-like thing - without amazon
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!