I have to heavily agree with this message.  My company is designing an
application which __really__ needs processRequest() so that one JSP page
can use another one.

On Wed, 5 May 1999, 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".
>

===========================================================================
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".

Reply via email to