Since 'request' and 'response' are implicit objects in your JSP 1.0 page, can't
you simply insert:
<% mybean.processRequest(request, response); %>
and get the equivalent functionality? Admittedly, it is a scriptlet, but it's
only one line and you have more control over exactly when the method is
called rather than having it done "invisibly" at the end of the USEBEAN
element.
John Langley wrote:
> and a 'use case' in the form of "guarded pages"
> a.k.a. required login.
>
> I noticed in the 1.0 preliminary spec. that the "processRequest
> machinery" is listed under the heading of "Postponed for Evaluation
> in Future Releases". I would like to voice a strong positive statement
> in favor of including the processRequest() machinery (as soon as
> possible). Here's why...
>
> We are developing a web based application using JSP and naturally
> that means having users login. In order to make sure that
> application pages are delivered only after the user has logged in
> we needed to develop a "guarded page" system.
>
> Now there are many ways to do this. In fact we've tried three,
> the most recent incorporates a technique that Christopher Cobb
> described just a couple of days ago in a message with the
> misleading subject of "Re: Subclassing JSP servlet?" This third
> technique, allowed us to keep the "guarded page" implementation
> limited to JUST .jsp pages and jsp beans, no servlets, no
> page redirects! This is a huge win! It yields by far the
> simplest system and most elegantly partitioned. Here's how
> it works, we've implemented Christopher's system with minor
> changes (he gets the credit for coming up with it, we just
> access the db w/out a servlet).
>
> 1. Make a login form.
> 2. Make a loginChecker bean with properties that match the "name"s of
> <INPUT> tags in your guard form. E.g. loginName and password.
> Include a processRequest() method that determines whether the
> loginName and password are valid and update the loggedIn attribute.
> 3. In our case we <!-- include file... --> the .jsp fragment
> file that contains both a <USEBEAN> of the loginChecker bean
> and the login <form> contained w/in an
> <excludeif property="loginChecker:loggedIn" value="true">
> </excludeif>
> pair (see the loginPage.jsp in the attached .jar file).
> 4. Finally, include the contents of your guarded page in a
> <includeif property="login:loggedIn" value="true">
> </includeif>
> pair.
>
> That's it your done. If that ~seems~ like a lot of work,
> it isn't. Please email me, and I'll forward you a .jar
> file with all the necessary .jsp and .java files. It's
> simple!
>
> Benefits:
> 1) Html coders can hack up the loginPage.jsp to be beaautiful;
> ie. you get separation of logic and presentation.
> 2) You can have multiple logins w/in your application customized
> to your need w/out having to fool with servlet properties,
> multiple url paths to the same files, etc.
> 3) There are no scriptlets (and heinous redirects) just
> <includeif> and <excludeif> tags.
>
> Now you could argue that we could move "login logic"
> into the getLoggedIn() method... but that would remove some of
> the power of the processRequest() technique. Remember, this
> example is just a 'use case' there are other cool things you
> can do with processRequest() that enable the bean to change
> it's state depending on parameters coming in on the request.
>
> As I see it, the processRequest() is an 'event notification' that
> the bean may want to change state based on the incoming
> request... and THAT is a very powerful mechanism, too powerful
> in fact to have disregarded as "obscure" or "arcane". Perhaps it just
> needs a name change to make it more obvious that it's an
> event notification to the bean. Either way, PLEASE "Mr. & Mrs.
> Jsp Spec. Meisters", make sure you include the processRequest()
> machinery in any upcoming specs. and implementations! Oh yeah,
> Thanks for the fine work you've already done!
>
> Langley.
>
> P.S. NICE JOB Christopher! This is a great login technique that
> I hope we can all continue to benefit from. Thank You!!!
>
> ===========================================================================
> 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".
--
Regards,
Rus Duderstadt [EMAIL PROTECTED]
AXTIVE Software http://www.axtive.com
===========================================================================
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".
