[EMAIL PROTECTED] wrote:
> Hi,
>
> .92 doesn't provide access to the HttpServletResponse from within a bean.
> First, I'm wondering why it wasn't included. The reason I want it is so that
> I can check the session to determine if a person has logged in. If they
> haven't I need to redirect them to a log in page. I don't believe there is a
> feasible way to do redirect that using JSP .92 beans.
>
> On a similar note, why not have JSP beans look more like servlets and
> include service, doGet, doPost, etc? Why make developers learn how to create
> beans and servlets? Just make a servlet a bean.
>
> Thanks for any help
>
Doing this kind of thing is feasible technically, but it encourages a mixing of
logic and presentation in the same JSP file, which IMHO is not the best
approach.
In your first scenario, consider the "Model 2" application design approach that
is discussed in the 0.92 specification. The control flow would go something
like this:
* A form is presented to the user (static, JSP generated, or
servlet generated)
* The form submit goes to a *real* servlet, not a JSP page
* The servlet checks in the session variables, and does
one of the following things:
* If the user has logged in, go ahead
and process the request, stash any
required results in beans in the session,
and then forward control to a JSP
page that displays the next screen of
the application.
* If the user has not logged in, forward
control to the login page. (This login
page itself would submit to a servlet
that validates the username/password,
and either forwards back to the login
page again on an error, or to the main
menu on success.)
The "forwarding" is done by using the ResourceDispatcher.forward() method (in
the 0.92 reference implementation). When released under the 2.1 servlet API,
this call will become RequestDispatcher.forward() instead, but it accomplishs
the same purpose. It acts a little like a redirect, except there is no extra
round trip to the browser and thus no performance impact.
Taking this approach lets you do "logic" type things in a real servlet, and
"presentation" type things in a JSP page. In particular for your scenario, the
servlet can check the session variables, choose what logical tasks to perform,
and choose what the next page to be displayed should be. Otherwise, you're
trying to mix control flow with presentation by sticking it in <% %> scriptlet
tags, and you end up with an unreadable mess for applications of significant
size.
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".
