I have to admit that your approach (storing the submitted form bean in
session context, then using a different bean to handle the login before
restoring the old one and continuing) is probably an improvement since it
avoids the possibility of namespace collisions between login (and other
potential interceptive activities, like user registration). On the other
hand, using the same bean to do double-duty makes its use nearly foolproof
and effortless as long as care is taken to avoid namespace collisions
between the base bean vars (username, password, etc.) and the
situation-specific bean vars.
Confession: I have a major, MAJOR prejudice and dislike of Javascript. I
used to be enthusiastic about it, but the abomination known as Netscape
Navigator 4.x and the impossibly quixotic task of trying to write javascript
code that didn't die horribly on one or more versions of it in late '97 led
me to hate it with a passion. I have mellowed out a bit over the past year
(recent versions of IE have had lots of cool toys to play with that nobody
seems to know about, like tabbed forms, dynamic database display, painless
expanding trees, etc), but I still try to avoid using Javascript to do
things I can accomplish just as easily, and more reliably, with server-side
apps (like reading the request URI and using it as a form's action
parameter).
To answer your questions...
> 1. Does every action require the form to be in session scope?
"I guess so" :-)
Up to now, I've just gone with Struts' default scope for form beans, which
apparently is "session", and haven't really questioned it or seriously
explored alternatives.
> 2. If any form element names a the same as the login page, wouldn't
> it overwrite them?
Yep. This doesn't really bother me too much, though, since I'm not likely to
use formvars named "username", "password", and "doLogin" elsewhere. If I
wanted to be REALLY safe/paranoid, I could adopt a naming convention to
guarantee that it would never happen (like "loginUsername", "loginPassword",
"loginDoLogin", etc.). If I were to implement user registration at the
passive interception level in addition to logins, I'd definitely give the
registration formvars names that would be guaranteed to not clash with
formvars from elsewhere in the site ("registerUsername", "registerPassword",
"registerPassverify", etc.).
> 3. When you get the originally called action by doing
HttpServletRequest.getRequestURI(),
> how does using <html:base/> in the original form affect what is returned?
That's a very good question. I don't have an answer, because I've never used
<html:base/>. As far as I know, getRequestURI() looks at the request purely
from the server's perspective... "to what URI was the request submitted",
and neither knows nor cares what the browser thinks it was after the fact. I
must confess that I've historically bent over backwards to avoid anything
resembling a relative URI, and (ab)used Apache's mod_rewrite when I simply
HAD to use them with cgi/mod_perl/servlet webapps.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
