First I have to say, that I use container managed security for logon -
rather rolling my own with an Action.
Having said that I don't really see what the issue is - just use the same
error mechanism that the validate() method uses - create an
ActionMessages/ActionErrors object, stick the key to the authentication
error in it, save the errors under the standard key and return to the input
forward.
In Struts 1.1 it would be something like the following in the Action's
execute method...
// do authentication
boolean authentic = authenticate();
if (!authentic) {
ActionErrors errors = new ActionErrors();
errors.add("logon", new ActionError("authenticate.error");
saveErrors(request, errors);
return getInputForward();
}
In Struts 1.2.4 it slightly simpler...
// do authentication
boolean authentic = authenticate();
if (!authentic) {
getErrors(request).add("logon", new
ActionError("authenticate.error");
return getInputForward();
}
Niall
----- Original Message -----
From: "Frank W. Zammetti" <[EMAIL PROTECTED]>
To: "Struts Developer" <[EMAIL PROTECTED]>
Sent: Friday, October 01, 2004 12:01 AM
Subject: Opening it up for debate...
> I came across something yesterday that might be good fodder for a
debate...
>
> Consider a simple login page. You submit the typical form with a userID
> and password. Your ActionForm performs a validation to be sure they
> filled in both fields and returns errors if any validation fails.
> Simple enough. You do the usual <html:errors/> to display the errors.
>
> Now... Presumably most of us would now do the AUTHENTICATION from an
> Action (well, delegated of course), as opposed to doing it from the
> validate() method (I wouldn't view that as "correct" myself). Let's say
> the user is not authenticated (bad password perhaps)... So you forward
> to a "failure" forward, but what about displaying an error message to
> the user?
>
> I imagine the typical thought is to put a message in a request attribute
> and do a <bean:write> to display it (with ignore="true" probably), or
> maybe more properly set some attribute of the form.
>
> So, here's my point... We have in the JSP an <html:errors/> tag to
> display VALIDATION errors, but we also have a <bean:write/> to display
> the AUTHENTICATION errors. Is that optimal? Why can't we do it with
> one line (or can we? I don't mind learning something new!)
>
> My thought is that maybe it would be appropriate to handle BOTH these
> situations by returning an ActionErrors collection. Ok, fine, we can
> insert it into request in the Action manually, but that's not a good
> idea because the attribute name might change down the road.
> High-coupling and all that jazz.
>
> What to do? Well, the first question is, does anyone agree that it
> makes some sense to handle both situations with ActionErrors, and
> thereby only have a single line in the JSP to display both types of
> errors? If not, ignore the rest of this.
>
> If you agree with that though, here's my suggestion... What if execute()
> in the Action returned an Object, and the object either implements an
> empty ActionForwardResult interface or an ActionErrorsResult interface
> (I just made those up of course), and that can be determined, the object
> casted and acted upon either as the usual ActionForward or the same way
> an ActionErrors is treated from validate() in the form.
>
> What does everyone think? Am I making a big deal out of the arguably
> minor inelegance of two error display lines in the JSP, or is this
> possibly a real issue to deal with? Even if you don't view it as a
> problem, might this change result in a bit more flexibility that might
> be good, or would it be breaking some architectural rules (I'm a bit
> mixed on that last point frankly). Thanks all!
>
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
