Originally posted by Chris Daniel:
I have the usual 2 questions I ask all the authors
a) What is your motivation for writing a book.
b) Is it helpful for brining some one new upto speed to write their own custom tags.
a) I have more than one motivation for writing the book. The main one is that I like to write. The second one is that I'm an active member of a number of JCP "expert groups" (Servlet, JSP, JSTL and JSF) and writing about the technologies help me verify that the specifications make sense--I've found many specification issues when I've developed examples for my books and tried to explain how things work.
b) Yes, as I've mentioned in answers to other questions, my book targets people new to the technology that may not necessarily have a Java programming background (e.g., people with ASP or a PHP background) in Part I and II, as well as people with Java programming experience but new to servlets, beans and custom tag library development in Part III.
Originally posted by Nigel Browne:
I would like to know how the author sees JSP evolving in the future. Also I would like to know what the author recommends as the best way to unit test jsp.
As far as I'm concerned, JSP is more or less "done", but for some reason popular technologies seems to continue to evolve to the point where they have so many features they are impossible to learn. I hope it doesn't happen to JSP.
The only thing I'd really like to do with JSP at this point is breaking out the Expression Language (EL) to a separate specification. The EL is useful for many technologies besides JSP and should be allowed to evolve on its own, but it should of course still be used in JSP with tight integration in the JSP container. JavaServer Faces (JSF) is one technology that uses a more evolved version of the EL, so its EL API should be merged with the JSP EL API in the new version. Related to this, an extended EL could support variable type declarations (accessed through directives or standard action elements in JSP) to allow for better error detection during development.
JSF also use JSP as one techynology for wiring up a component tree, and JSF 1.0 clashes here and there with JSP because of overlapping features and limitations in the JSP API in terms of hooks and access to some of the internals. A future JSP version should be extended to allow for better integration with JSF, even though I think the best idea would be to define and endorse a separate "view specification" format for JSF components in addition to the JSP one.
Regarding unit testing for JSP, I know there are some test frameworks out there that can help you with that. Maybe someone else can point you to specific examples. To me, though, if you need to unit test your JSP pages with anything more complex than a simple program that makes requests and compares the returned response to a copy of the correct response, it's an indication that you've put too much logic in your JSP pages. For a complex application, you should use pure Java classes in the form of beans, custom tag handlers, data abstraction classes, business logic classes, etc. rather than in the pages themselves, and you can use test frameworks like JUnit to test those classes independently of the View layer.