RE: Opening it up for debate...
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();
}
Surely you meant:
new ActionMessage(authenticate.error); // ;-)
Anyway, does it make sense to have something like this:
saveError(request, errorsKey, messageKey)
I usually end up adding that to a BaseAction in each project, but
maybe it doesn't belong in Action, per se.
While I'm at it, other common methods that don't necessarily belong to
Action, but are common enough to be in Struts somewhere: (IMO,
obviously)
getInt(request, attributeName);
// and other common types, Date, Integer, Long ...
Interesting that Struts lacks probably the first Servlet utility ever.
Or am I missing something?
getInteger(form, property);
// handle all ActionForm and DynaActionForm
These are fairly common I would think, but perhaps not common enough to
go into Action.
- Dave
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Opening it up for debate...
While I'm at it, other common methods that don't necessarily belong to Action, but are common enough to be in Struts somewhere: (IMO, obviously) getInt(request, attributeName); // and other common types, Date, Integer, Long ... Let me add that this method often contains third parameter, defaultValue. I realize that this might be a 'primitive' technique for working with the request. Still, surely it's a quite common one, especially for newbies. - Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Opening it up for debate...
While I'm at it, other common methods that don't necessarily belong to Action, but are common enough to be in Struts somewhere: (IMO, obviously) getInt(request, attributeName); // and other common types, Date, Integer, Long ... Interesting that Struts lacks probably the first Servlet utility ever. Or am I missing something? getInteger(form, property); // handle all ActionForm and DynaActionForm I think various resources in commons-lang and commons-beanutils support these kinds of operations, and putting direct support for them in Struts is more like clutter than value. I'll admit that I'm writing little methods like this (my most common is isEmpty(...) which combines a null check with a standard emptiness check (string length, collection size, etc)) The problem is that everyone has their own favorites and it would be a mess to figure out exactly which ones and which peculiar variations on similar things are in or out -- simpler just to leave 'em all out. Anyway, does it make sense to have something like this: saveError(request, errorsKey, messageKey) I usually end up adding that to a BaseAction in each project, but maybe it doesn't belong in Action, per se. On the other hand, this to me is more central to Struts itself, and so might be worthy of inclusion. Here's an alternate approach we use: first, we have an ActionContext which carries the ActionForm, ActionMapping, HttpServletRequest and HttpServletResponse around, rather than passing all four independently. This ActionContext then has some utility methods that are based on how Struts deals with those -- for example, it has properties for two ActionMessages objects, one representing errors and one representing messages. Then actions can call context.addError(errorsKey, messageKey) as a convenience like what you describe above, except that the context already has the request. (Of course, there's a addMessage(...) method also, and versions which accept ActionMessage objects for cases when you have a replacement value array to pass in also). The problem is that even these things are fairly idiomatic, and what we find convenient here might be fairly contentious among the wider world of developers. (Let's see if any sparks fly here :^) Joe -- Joe Germuska [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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]
Re: Opening it up for debate...
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]
Re: Opening it up for debate...
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 [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]
--
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]
Re: Opening it up for debate...
On Thu, 30 Sep 2004 20:08:36 -0400, Frank W. Zammetti [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Opening it up for debate...
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Opening it up for debate...
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
