I'd like to make a couple of points about this discussion:
1) I think it is purist to want to totally separate the HTML and Java
coding. The real world however often calls for conditional coding within
your JSP in response to data in your bean, if for no other reason than
because the user interface requires it and is improved by it. As nice as
the total JSP solution is, working with servlets to produce data beans for
JSPs is a much more scalable approach. The servlet is the business layer,
and the JSP the presentation layer.
2) Craig's example below begs for a feature that is lacking right now: the
ability to "re-target" a page. Craig talks about the common need to
conditionally display a page. Well I develop pages that use frames, and
often find that the target of my next page might need adjusting depending on
what happens server side. However a page's target is determined at the time
a server side call is made, and cannot be adjusted after the fact. I've
sent SUN a request for the ability to change target at redirect or callpage
time. I certainly hope it makes it into JSP 1.0. That's assuming it can
even be done.
Dan
--
Daniel Kirkdorffer
Sr. Consultant, Syllogistics LLC
Web: http://www.syllogistics.com/
Email: [EMAIL PROTECTED]
> ----------
> From: Craig R. McClanahan[SMTP:[EMAIL PROTECTED]]
> Reply To: Craig McClanahan
> Sent: Friday, March 05, 1999 8:21 AM
> To: [EMAIL PROTECTED]
> Subject: Re: My view on JSP
>
> 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".
>
===========================================================================
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".
