Neal Ford

Originally posted by Dmitry Danilov:
Are JSP 2.0 / Servlet 2.4 covered?

No, neither was out at the time of the writing. It covers JSP 1.2 and Servlet 2.3.

Originally posted by David Yutzy:
Are there any on-line demo sites that use Tapestry that you could reference? How does this product differentiate itself from Struts? I've been to the site, but it sounds very similiar...

They are not at all similar. Besides the basic premise of Model 2, they are vastly different. Tapestry encapsulates the entire web request/response cycle into the framework. Writing Tapestry applications is more like writing traditional desktop applications. There is no request, response, session, etc. that you are accustomed to in web development. Instead, there are components, event handlers, etc. Tapestry also doesn't use JSP, but instead uses template-based component substitution. For example, building a table in Tapestry has you build a Table Model, similar to Swing.
If you want to get a good idea of what Tapestry is about, you can read the Tapestry chapter in my book! Or, you can look at the tutorial at the tapestry web site

Q1) compile time checking?

If you use ActionForms, you have distinct types associated with each ActionForm property. That means when Struts populates the ActionForm, it handles conversions for you. IOW, the framework does type conversions based on the underlying types of the properties (there are well defined rules within Struts to determine how that happens). This is what I referred to as "compile time checking", although that term is a little misleading here -- it's a leftover term from a previous, similar problem.
When you use maps, everything goes into the map as a String, meaning that:

All values come back to you as a String, and you have to write your own conversions

It is possible to mis-type the name of a property, and thus the framework won't populate the form correctly

In some situations, you don't know all the properties up front, so you have to use dynamic properties. Struts also has a mechanism called "DynaForms" which offers some of the advantages of both the above approaches.

Q2) What are the business rules interfaces? Please elaborate. Are they something that Struts provide or your customized interfaces?

This is a de-coupling technique that is widely used by Struts developers. Instead of having your entities directly sub-class ActionForms (bad practice because you are mixing Framework code with your model (the entities)), you create interfaces that include all the properties of the entity (called Business Rules Interfaces). Then, your actual entity classes and the ActionForm both implement the interface, and the ActionForm encapsulates one of your entity classes. The interface creates a contract between the business rules and the ActionForm, and the ActionForm proxies the property values to the encapsulated entity.
This is a relatively advanced use of ActionForms, but it offers some great advantages from a design standpoint because the entities are

completely decoupled from the framework

the interface ensures that both the ActionForm and the entity agree on what information is needed

Hope that helps.

Which framework best lends itself to this architecture.

Tapestry has an amazingly robust tabbed dialog component. While not automatically supporting your design, it would be easy to get it to handle it. Tapestry hides much of the request/response nature of the web from the developer, making it more like writing a desktop application. One of the samples that ships with Tapesty (and referred to in my book) uses a complex tabbed dialog-style interface.

So does it mean that those who are totally new to Struts can use your book as an introduction to Struts? Even though I'm not new to Struts, I might have chance to refer about your book to the Struts newbies...

Yes, my book is an introduction Struts, along with the reasons that Struts (and the other frameworks) are useful to busy developers.

Is it also mean that your book is introduction to several frameworks mentioned on the cover of the book? Poeple who wants to try those frameworks specified on the cover, the book is for them... Isn't it?

Yes, I compare and contrast the frameworks, but I don't assume that the reader knows anthing about them up front. It's a good way to learn the flavor of all these competing frameworks. I also supply evaluation criteria to assist the reader in choosing the framework most suitable for them.

Thanks a lot for being here answering a lot of questions, even though some are not directly related to your book..

You are quite welcome. I've enjoyed the week here.

Originally posted by Nicholas Cheung:
Hi Neal,
Thus, Tiles can make use of JSTL as well? Since Tiles is the template of the display...
Thanks
Nick.

Absolutely. Tiles in no way restricts the kinds of tags and/or syntax you can use on the page. In fact, we liberally mix JSTL and Struts tags within our tiles.

Originally posted by Gian Franco Casula:
Dear Mr.Ford,
How would you tackle the implementation of a 'unit test
suite' that would be appropriate project wide, bearing
in mind that there are different frameworks in the picture.
Can this be solved elegantly in a single fashion, or is it
better to implement a unit test for each framework used?

If you are careful to create your models (both boundaries and entites) as framework-agnostic, then a single suite of unit tests can cover all of them. Yet another benefit of clean separation of responsibilities!
For the framework specific pieces (workflow, UI), you will have to create a specific suite of tests.

In your opinion, will the Struts completely replace the traditional MVC model someday or will they co-exist for awhile?

They aren't really competing ideas -- Struts is heavily (I would say "infused") with the Model 2 variant of MVC. Even for small projects, Struts offers good, basic plumbing that every Model 2 application needs. It's mostly stuff you would have to write yourself if you weren't using Struts. Of course, Struts has a bunch of additional features (like i18n, declarative validations, etc), but you don't have to use them.
I think that Struts, JSTL and it's expression language, and JSF are going to have to find a way to cooperate. And, I think they will -- for example, Struts already optionally supports JSTL's EL.

It's out yet?

Yes, indeed. Here it is on Amazon.com

I cover Struts, Tapestry, WebWork, Velocity, InternetBeans Express, and Cocoon.

- the depth of the discussion of each framework

I cover architecture and design of each framework and implement the same sample application in each framework, so that they can be compared on an equal basis. I do not go into the level of detail on each framework that an entire book dedicated to the framework would.

- what is the level of understanding the reader is supposed to have to understand each one

If you understand the basics of Java web development (servlets and JSP), you will be fine. The book covers the evolution of development from servlets through JSP and custom tags and introduces Model 2 before I discuss the frameworks.

- if the book covers any helper tools, IDEs, etc

I also cover helper libraries (like JUnit, Axis, Jakarta Commons) and also some coverage of IDE's, particularly for debugging and performance tuning.

- if all XML deployment and configuration files required by the frameworks are covered

I do not offer an exhaustive treatment of them. However, I certainly show enough of them to get the sample application to deploy correctly. In other words, I don't use any "And the a miracle occurs" sections where I hide details required to get the framework to function correctly.

- and more importantly: does the book have any real-world exemple of use of any of the frameworks discussed, or has design tips, or real-world situations where whould be great to use XXX framework for exemple...

There is an entire chapter comparing and contrasting the frameworks, which highlights the situations where a particular framework is useful. The third part of the book provides best practices, in a real world setting, using Model 2 web applications to show how to handle common user interface requirements, performance tuning, resource management, debugging, testing, etc.
Hope that answers your questions.

Originally posted by Brandon George:
Hello All!
I was wondering what is the best book to learn Struts, and mostly dealing with Web design, and JSP!?
I am not new to java, I have been doing a good bit of Desktop Java development and some servlet development, but I am new to STRUTS. So any help on this would be great!

My book covers a bit about Struts (along with 5 other frameworks), but covers a great deal about web design and best practices. It is a good introduction to Struts and the rationale behind the implementation of Struts.

Originally posted by Jacky Chow:
I think ActionForm in Struts is not good, it makes the form data objects bind to Struts, I think it should use general JavaBean classes that do not extend ActionForm, any opinion?

There are several approaches to avoid coupling the Struts ActionForm into your entity classes. I cover a couple in my book, and Husted's book covers 6 in all. It boils down to a question of convenience vs. architectural purity. It is more convenient to directly sub-class ActionForm, but there are better ways that aren't quite so convenient.

We have this testing automation tool from parasoft (the Junit guys). Do you have an opinion to offer on this tool? we are finding the learning curve to be too steep and time spent on solving issues with this tool negating the benefits of automating our test cases ( On an average about 20 times the time spent on running a test case is being spent on automating a test case including training and other overheads). What alternatives do we have for automation of testing process?

We have cooked up our own automation process in my office, based on Continuous Integration. I haven't used webking. However, I highly recommend that you automate as much of the test-running process as possible. Like many things in the open source world, you frequently spin your wheels getting everything set up just right, then it just works.
Note that you can cut down on the time it takes to write tests by using fixtures and base classes intelligently. My book shows examples of this, using JUnit.

We have this testing automation tool from parasoft (the Junit guys). Do you have an opinion to offer on this tool? we are finding the learning curve to be too steep and time spent on solving issues with this tool negating the benefits of automating our test cases ( On an average about 20 times the time spent on running a test case is being spent on automating a test case including training and other overheads). What alternatives do we have for automation of testing process?

We have cooked up our own automation process in my office, based on Continuous Integration. I haven't used webking. However, I highly recommend that you automate as much of the test-running process as possible. Like many things in the open source world, you frequently spin your wheels getting everything set up just right, then it just works.
Note that you can cut down on the time it takes to write tests by using fixtures and base classes intelligently. My book shows examples of this, using JUnit.

are there any sample chapters of your book on the internet?

Yes, look at my publishers site: www.Manning.com
There are a couple of sample chapters you can download.