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