Nicolas Pujol wrote:
> This is an attempt to raise design and higher level questions on the use of
> JSP pages and JavaBeans.
>
> I keep seeing people on this mailing list using all kind of convoluted
> coding with their JSP pages, particularly in the context of holding session.
> I would like to make a point. As far as I am concerned the beauty of JSP
> rests almost exclusively in the BEAN tag or more recently the USEBEAN tag.
> Apart from the that JSP is nothing more than a regular scripting language
> like ASP or Javascript and LiveConnect.
>
I agree with you ... I've experimented with several design patterns using JSP,
and the one that is the easiest to write (and to read later on) has essentially
no Java code embedded in the JSP pages ... only references to bean properties.
>
> I believe that as Java programmers we have to support the virtues of
> OOP/OOD. The Bean tag should be used over extensive scripting within the
> JSP. Using beans allows for easy maintenance of a page and more generally of
> a site. In addition, it allows for Web development teams to delegate more
> clearly their work into JavaBeans programmers (business logic) and Web
> Designers (web presentation). It is important to note that the two have to
> come together at some point. It is this "point of convergence" that needs to
> be analyzed and studied extensively by Web architects.
>
There are at least a couple of strong motivations to separate the business
logic from the presentation logic:
* The skillsets needed to do the business logic (in Java) and
the presentation (in HTML) do not always reside in the same
person -- keeping things separated lets you work in parallel.
* It is quite common to give the visual appearnance of a web site
a facelift every so often. Less common but also of interest is
improving the functionality of your back end processing. If the
logic and presentation are combined in one file you have to worry
about both at the same time on every change, instead of being
able to deal with them independently.
>
> Interestingly enough it appears that JSP and JavaBeans can work solely
> without the need for servlets. In short, servlets as such are really
> marginalized by JSP's. On the other hand, JSP pages are pre-servlets and are
> compiled to servlets by the JSP engine after all. In my mind JSPs simply
> facilitate the use and the coding of servlets.
>
You can do this, but I have found that using the "Model 2" approach from the
0.92 spec (JSP page posts to servlet, which stores data in a session bean and
forwards to the next JSP page) is particularly useful in the scenario where the
"next" JSP page depends on the processing results.
For example, let's say you have a form that enters an order. It is done in a
JSP page so that you can pre-fill-in any information you already know from bean
properties. You've got some client side validations, but you can't check
everything until the order is submitted.
The submission is to a "real" servlet that accepts the entry form and does the
server-side validation checks that are necessary before storing the order in
the database (perhaps checking the customer's credit limit against the order
total, for example). Then, the servlet does one of two things depending on the
success of this checking:
* If the checks are OK, store the order in the database
and use a ResourceDispatcher.forward() call to send
control to the "menu" page (or whatever is appropriate
in your application).
* If the checks are not OK, use ResourceDispatcher.forward()
to send control back to the order entry form, with a special
property set that will create an error message. The form will
still be filled out from the bean properties, so the user does not
have to fill them in again.
The key is that you don't know ahead of time which "next" page should be
displayed. With a servlet, you get to choose the URI path that you pass to
your ResourceDispatcher (note -- this becomes RequestDispatcher in the 2.1
servlet API). If you are already in the JSP page that received the form
parameters, the only way to do this would be conditional logic -- and that's
going to get REALLY messy.
>
> Please send me your remarks.
>
> Nicolas Pujol
> Waterstone Consulting
>
Craig McClanahan
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JSP-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
