Luc Saint-Elie wrote:
> Craig,
>
> I usually really love your answers that are by far the must useful and
> comprehensives ones.
> But in this case I really don't agree.
>
> I read the J2EE docs and I'm still unable to answer to simple questions like
>
> - in this case use JSP
> - in this case use JSP + bean
> - in this case use JSP + servlets
> - in this case use Servlets
>
> for a pure web application
>
For the specific questions about beans, the JSP tutorials on the JSP pages
(http://java.sun.com/products/jsp) are also useful, but they really don't go far
enough past "Hello, world" to help you design applications.
I found that Chapter 6 of the Application Programming Model (APM) document
contained quite a lot of useful information on what these things are for, and the
example application is invaluable because it illustrates what a non-trivial system
looks like. This is not at the beginning Java programmer level -- it assumes an
understanding of some basic object oriented design concepts -- but it's really
important to understand what the "big picture" looks like, and how to use all these
building blocks together.
Basically, JavaBeans (as opposed to EJBs) should be used to encapsulate information
that needs to be shared between components (JSP pages and servlets). If you don't
have more than one such component, you don't need beans -- otherwise you do. The
next question is the lifetime of the information (per request, per user session, or
per application), which determines the particular technique you use to store and
retrieve components in a servlet (request attributes, session values, or context
attributes) and the "scope" argument you use in a JSP. I, and others, have
articulated how to choose between these mechanisms *many* times on the servlet and
JSP mailing lists.
On the fundamental application design choice (pure JSP, pure servlet, or a
combination), you will find that there is no one answer that satisfies everyone.
The advocates of each position can get very fanatical about why their own suggested
style is the best. For the record, I am of the "combination" persuasion -- I
design my web applications using an MVC mindset:
* Model = JavaBean representation of the data
from the underlying database (or whatever)
and the associated business logic.
which could also be delegated to EJBs if needed
* View = JSP pages that contain only presentation
related stuff.
* Controller = servlets that dispatch processing
appropriately based on received inputs, but do
no HTML output of their own.
If you look inside my apps, you'll see the following design pattern all over the
place:
* JSP page contains an input form. The values
are pre-filled-in from a session bean that contains
application default values the first time through,
or the most recent inputs after a validation error
(see below for more info).
* Form submit goes to a servlet (I tend to
use a single servlet per app, others like
a servlet per input form).
* Servlet dispatches to the business logic
responsible for processing this form.
* The most recent set of form inputs are
saved in the session bean (used in the first
step) in case a validation error is detected.
* If the business logic detects a validation
error, it stores an error message bean and
forwards control back to the original JSP page
containing the form. The form can then be
redisplayed with the previous inputs in it,
along with the error message. The user
only needs to modify what needs fixing rather
than starting from scratch.
* If the validation checks all pass, the business
logic performs the required function, stores any
results in session beans, and forwards control
to the next JSP page to display the results.
Advocates of the "pure servlet" and "pure JSP" camps are welcome to make their own
cases.
Craig McClanahan
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
FAQs on JSP can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
