You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by "Frank W. Zammetti" <fz...@omnytex.com> on 2004/10/01 01:01:32 UTC
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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Opening it up for debate...
Posted by Joe Germuska <Jo...@Germuska.com>.
At 7:01 PM -0400 9/30/04, Frank W. Zammetti wrote:
>I came across something yesterday that might be good fodder for a debate...
Another approach which I have used is to consider an authorization
failure a "business exception" and throw an
"UnauthorizedUserException" which can then be mapped using Struts
declarative exception handling to look up the appropriate message
(based on the exception handler config's "key" property) and deliver
a usable message to an Error JSP.
But now that you know about "saveErrors" (and don't forget
"saveMessages"), you probably don't need yet another solution!
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn
back; I'll know I'm in the wrong place."
- Carlos Santana
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Opening it up for debate...
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
I actually have to plead ignorance on that... In all honesty, I haven't
looked over the sample apps as much as I probably should... I'm one of
those people that prefers to just jump in, start coding something and
figure it out as I go. Plus, I don't generally like looking at other
people's code, it usually winds up taking more time and effort to figure
it out than just working out the solution myself.
Here however is a situation where looking at the samples would have been
very beneficial, and saved a little bit of traffic on the list. Simply
put, my bad :)
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
Craig McClanahan wrote:
> On Thu, 30 Sep 2004 20:08:36 -0400, Frank W. Zammetti
> <fz...@omnytex.com> wrote:
>
>>Ah, I didn't know about the saveErrors method. That completely
>>invalidates my entire concern. Thank you! I figured I was either on to
>>something or was about to learn something, and I kinda figured it would
>>be the later :)
>
>
> BTW, this is also the approach that the standard Struts example
> application (struts-example) uses to deal with this scenario.
>
> Craig
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Opening it up for debate...
Posted by Craig McClanahan <cr...@gmail.com>.
On Thu, 30 Sep 2004 20:08:36 -0400, Frank W. Zammetti
<fz...@omnytex.com> wrote:
> Ah, I didn't know about the saveErrors method. That completely
> invalidates my entire concern. Thank you! I figured I was either on to
> something or was about to learn something, and I kinda figured it would
> be the later :)
BTW, this is also the approach that the standard Struts example
application (struts-example) uses to deal with this scenario.
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Opening it up for debate...
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Ah, I didn't know about the saveErrors method. That completely
invalidates my entire concern. Thank you! I figured I was either on to
something or was about to learn something, and I kinda figured it would
be the later :)
Niall Pemberton wrote:
> 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" <fz...@omnytex.com>
> To: "Struts Developer" <de...@struts.apache.org>
> 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: dev-unsubscribe@struts.apache.org
>>For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
>
>
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Opening it up for debate...
Posted by Niall Pemberton <ni...@blueyonder.co.uk>.
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" <fz...@omnytex.com>
To: "Struts Developer" <de...@struts.apache.org>
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: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org