Re: LookupDispatchAction default
Well, I tried overriding unspecified and I still get the following (mind
you that I didn't change the parameter name yet) when I hit
/admin/list.do:
Error 500: Request[/admin/list] does not contain handler parameter
named submit
My unspecified method I simply overrode from DispatchAction to call my
normal refresh list method:
protected ActionForward unspecified(
ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response
) {
return this.refreshList(mapping, form, request, response);
}
While the JavaDocs do imply this should work, when I looked in the Struts
1.1 source, the execute method of LookupDispatchAction generates the erorr
message I see as soon as request.getParameter(parameterName) returns null.
In fact, I can find no reference to 'unspecified' anywhere in
LookupDispatchAction.
So I think there is a disconnect. Maybe LookupDispatchAction is broken
and should be fixed to also use 'unspecified', or maybe its JavaDocs
should explicitly state that it does not utilize the 'unspecified'
behavior of its parent class. Or, maybe I missed something and didn't
implement correctly?
Regards,
Brian.
Mark Lowe [EMAIL PROTECTED]
03/24/2004 09:21 AM
Please respond to Struts Users Mailing List
To: Struts Users Mailing List [EMAIL PROTECTED]
cc:
Subject:Re: LookupDispatchAction default
unspecified() is the method you want look at the javadoc.
you do need the method name though
/admin/list.do?method
I saw that using submit as the parameter name causes problems so i
wouldn't use that.
On 24 Mar 2004, at 15:16, Brian Sayatovic/AMIG wrote:
I'd like to be able to have someone hit my action, /admin/list.do,
without
having to specify a submit paramater. However, the action is a
subclass
of LookupDispatchAction whci requires that the request parameter be
supplied. Looking in the struts source code, it would be nice if the
LookupDispatchAction could fall back to a default or not consider
'null'
to be a bad value and just use 'null' as a key to the lookup Map. For
now, any link or redirect to the page must specify what I consider to
be
the default action -- refresh -- on the URL:
/admin/list/do?submit=Refresh.
Is there another way to do this? Is it worth suggesting that
LookupDispatchAction support a default or null mapping?
Regards,
Brian.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: LookupDispatchAction default
Look at the sourc for LookupDispatchAction snippet below:
public ActionForward execute(
ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws Exception {
// Identify the request parameter containing the method name
String parameter = mapping.getParameter();
if (parameter == null) {
String message = messages.getMessage(dispatch.handler,
mapping.getPath());
throw new ServletException(message);
}
// Identify the string to lookup
String name = request.getParameter(parameter);
if (name == null) {
String message =
messages.getMessage(dispatch.parameter,
mapping.getPath(), parameter);
throw new ServletException(message);
}
It looks for the parameter's value and throws if the name is null so it
never gets a chance to get to unspecified in Dispatch action.
mas
Brian Sayatovic/AMIG wrote:
Well, I tried overriding unspecified and I still get the following (mind
you that I didn't change the parameter name yet) when I hit
/admin/list.do:
Error 500: Request[/admin/list] does not contain handler parameter
named submit
My unspecified method I simply overrode from DispatchAction to call my
normal refresh list method:
protected ActionForward unspecified(
ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response
) {
return this.refreshList(mapping, form, request, response);
}
While the JavaDocs do imply this should work, when I looked in the Struts
1.1 source, the execute method of LookupDispatchAction generates the erorr
message I see as soon as request.getParameter(parameterName) returns null.
In fact, I can find no reference to 'unspecified' anywhere in
LookupDispatchAction.
So I think there is a disconnect. Maybe LookupDispatchAction is broken
and should be fixed to also use 'unspecified', or maybe its JavaDocs
should explicitly state that it does not utilize the 'unspecified'
behavior of its parent class. Or, maybe I missed something and didn't
implement correctly?
Regards,
Brian.
Mark Lowe [EMAIL PROTECTED]
03/24/2004 09:21 AM
Please respond to Struts Users Mailing List
To: Struts Users Mailing List [EMAIL PROTECTED]
cc:
Subject:Re: LookupDispatchAction default
unspecified() is the method you want look at the javadoc.
you do need the method name though
/admin/list.do?method
I saw that using submit as the parameter name causes problems so i
wouldn't use that.
On 24 Mar 2004, at 15:16, Brian Sayatovic/AMIG wrote:
I'd like to be able to have someone hit my action, /admin/list.do,
without
having to specify a submit paramater. However, the action is a
subclass
of LookupDispatchAction whci requires that the request parameter be
supplied. Looking in the struts source code, it would be nice if the
LookupDispatchAction could fall back to a default or not consider
'null'
to be a bad value and just use 'null' as a key to the lookup Map. For
now, any link or redirect to the page must specify what I consider to
be
the default action -- refresh -- on the URL:
/admin/list/do?submit=Refresh.
Is there another way to do this? Is it worth suggesting that
LookupDispatchAction support a default or null mapping?
Regards,
Brian.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Mark Shifman MD. Ph.D.
Yale Center for Medical Informatics
Phone (203)737-5219
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: LookupDispatchAction default
That's exactly my point.
If there is no submit=xxx parameter/value to the action, then it throws
a NullPointerException. So my action works like this:
/admin/list.do?submit=Refresh
But not like this:
/admin/list.do
In the second case, there is no submit parameter. For now, anything I
want to go to the list for the firs titme, I have it going to the first
representation. But what I really want is for it to have a default
behavior when no submit value is present so I can use the second form of
the URL instead. That was why I originally posted. The initial wave of
replies suggested I could use 'unspecified', but that didn't work.
So, is the answer:
(a) I should never use the second form because it is evil
(b) I could use the second form but its broken in LookupDispatchAction
(c) something else?
Regards,
Brian.
Mark Shifman [EMAIL PROTECTED]
03/25/2004 08:51 AM
Please respond to Struts Users Mailing List
To: Struts Users Mailing List [EMAIL PROTECTED]
cc:
Subject:Re: LookupDispatchAction default
Look at the sourc for LookupDispatchAction snippet below:
public ActionForward execute(
ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws Exception {
// Identify the request parameter containing the method name
String parameter = mapping.getParameter();
if (parameter == null) {
String message = messages.getMessage(dispatch.handler,
mapping.getPath());
throw new ServletException(message);
}
// Identify the string to lookup
String name = request.getParameter(parameter);
if (name == null) {
String message =
messages.getMessage(dispatch.parameter,
mapping.getPath(), parameter);
throw new ServletException(message);
}
It looks for the parameter's value and throws if the name is null so it
never gets a chance to get to unspecified in Dispatch action.
mas
Brian Sayatovic/AMIG wrote:
Well, I tried overriding unspecified and I still get the following (mind
you that I didn't change the parameter name yet) when I hit
/admin/list.do:
Error 500: Request[/admin/list] does not contain handler
parameter
named submit
My unspecified method I simply overrode from DispatchAction to call my
normal refresh list method:
protected ActionForward unspecified(
ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response
) {
return this.refreshList(mapping, form, request,
response);
}
While the JavaDocs do imply this should work, when I looked in the Struts
1.1 source, the execute method of LookupDispatchAction generates the
erorr
message I see as soon as request.getParameter(parameterName) returns
null.
In fact, I can find no reference to 'unspecified' anywhere in
LookupDispatchAction.
So I think there is a disconnect. Maybe LookupDispatchAction is broken
and should be fixed to also use 'unspecified', or maybe its JavaDocs
should explicitly state that it does not utilize the 'unspecified'
behavior of its parent class. Or, maybe I missed something and didn't
implement correctly?
Regards,
Brian.
Mark Lowe [EMAIL PROTECTED]
03/24/2004 09:21 AM
Please respond to Struts Users Mailing List
To: Struts Users Mailing List
[EMAIL PROTECTED]
cc:
Subject:Re: LookupDispatchAction default
unspecified() is the method you want look at the javadoc.
you do need the method name though
/admin/list.do?method
I saw that using submit as the parameter name causes problems so i
wouldn't use that.
On 24 Mar 2004, at 15:16, Brian Sayatovic/AMIG wrote:
I'd like to be able to have someone hit my action, /admin/list.do,
without
having to specify a submit paramater. However, the action is a
subclass
of LookupDispatchAction whci requires that the request parameter be
supplied. Looking in the struts source code, it would be nice if the
LookupDispatchAction could fall back to a default or not consider
'null'
to be a bad value and just use 'null' as a key to the lookup Map. For
now, any link or redirect to the page must specify what I consider to
be
the default action -- refresh -- on the URL:
/admin/list/do?submit=Refresh.
Is there another way to do this? Is it worth suggesting that
LookupDispatchAction support a default or null mapping?
Regards,
Brian.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Mark Shifman MD. Ph.D.
Yale Center for Medical Informatics
Phone (203)737-5219
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL
Re: LookupDispatchAction default
/admin/list.do?method
On 25 Mar 2004, at 14:02, Brian Sayatovic/AMIG wrote:
Well, I tried overriding unspecified and I still get the following
(mind
you that I didn't change the parameter name yet) when I hit
/admin/list.do:
Error 500: Request[/admin/list] does not contain handler
parameter
named submit
My unspecified method I simply overrode from DispatchAction to call my
normal refresh list method:
protected ActionForward unspecified(
ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response
) {
return this.refreshList(mapping, form, request,
response);
}
While the JavaDocs do imply this should work, when I looked in the
Struts
1.1 source, the execute method of LookupDispatchAction generates the
erorr
message I see as soon as request.getParameter(parameterName) returns
null.
In fact, I can find no reference to 'unspecified' anywhere in
LookupDispatchAction.
So I think there is a disconnect. Maybe LookupDispatchAction is broken
and should be fixed to also use 'unspecified', or maybe its JavaDocs
should explicitly state that it does not utilize the 'unspecified'
behavior of its parent class. Or, maybe I missed something and didn't
implement correctly?
Regards,
Brian.
Mark Lowe [EMAIL PROTECTED]
03/24/2004 09:21 AM
Please respond to Struts Users Mailing List
To: Struts Users Mailing List
[EMAIL PROTECTED]
cc:
Subject:Re: LookupDispatchAction default
unspecified() is the method you want look at the javadoc.
you do need the method name though
/admin/list.do?method
I saw that using submit as the parameter name causes problems so i
wouldn't use that.
On 24 Mar 2004, at 15:16, Brian Sayatovic/AMIG wrote:
I'd like to be able to have someone hit my action, /admin/list.do,
without
having to specify a submit paramater. However, the action is a
subclass
of LookupDispatchAction whci requires that the request parameter be
supplied. Looking in the struts source code, it would be nice if the
LookupDispatchAction could fall back to a default or not consider
'null'
to be a bad value and just use 'null' as a key to the lookup Map. For
now, any link or redirect to the page must specify what I consider to
be
the default action -- refresh -- on the URL:
/admin/list/do?submit=Refresh.
Is there another way to do this? Is it worth suggesting that
LookupDispatchAction support a default or null mapping?
Regards,
Brian.
-
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: LookupDispatchAction default
From: Brian Sayatovic/AMIG [mailto:[EMAIL PROTECTED]
That's exactly my point.
If there is no submit=xxx parameter/value to the action,
then it throws
a NullPointerException. So my action works like this:
/admin/list.do?submit=Refresh
But not like this:
/admin/list.do
So, is the answer:
(a) I should never use the second form because it is evil
(b) I could use the second form but its broken in LookupDispatchAction
(c) something else?
What version of Struts are you using? I suspect you're on 1.1 or
something older than a nightly build. The javadocs on the Struts site
go with the nightly builds.
The unspecified method is in DispatchAction, and is inherited by
LookupDispatchAction, so you won't find it in the LDA source code. It's
actually the protected 'dispatchMethod' code that handles the null:
// Make sure we have a valid method name to call.
// This may be null if the user hacks the query string.
if (name == null) {
return this.unspecified(mapping, form, request, response);
}
If unspecified does not work for a missing parameter in your version of
struts, (it does in 1.2.0 and probably somewhat before that,) either
move to a newer version of Struts, or override 'execute' to provide
default behavior. Check for the presence of the request parameter, if
it exists, call super.execute(), if not, do your default behavior,
probably by calling one of the methods in your LDA.
The reason you're getting conflicting answers is that some of us are
using new builds where unspecified works fine, and some are on other,
older versions. The nightly builds are very stable, I recommend them
and have no problems using them in production.
--
Wendy Smoak
Application Systems Analyst, Sr.
ASU IA Information Resources Management
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
LookupDispatchAction default
I'd like to be able to have someone hit my action, /admin/list.do, without having to specify a submit paramater. However, the action is a subclass of LookupDispatchAction whci requires that the request parameter be supplied. Looking in the struts source code, it would be nice if the LookupDispatchAction could fall back to a default or not consider 'null' to be a bad value and just use 'null' as a key to the lookup Map. For now, any link or redirect to the page must specify what I consider to be the default action -- refresh -- on the URL: /admin/list/do?submit=Refresh. Is there another way to do this? Is it worth suggesting that LookupDispatchAction support a default or null mapping? Regards, Brian.
Re: LookupDispatchAction default
unspecified() is the method you want look at the javadoc. you do need the method name though /admin/list.do?method I saw that using submit as the parameter name causes problems so i wouldn't use that. On 24 Mar 2004, at 15:16, Brian Sayatovic/AMIG wrote: I'd like to be able to have someone hit my action, /admin/list.do, without having to specify a submit paramater. However, the action is a subclass of LookupDispatchAction whci requires that the request parameter be supplied. Looking in the struts source code, it would be nice if the LookupDispatchAction could fall back to a default or not consider 'null' to be a bad value and just use 'null' as a key to the lookup Map. For now, any link or redirect to the page must specify what I consider to be the default action -- refresh -- on the URL: /admin/list/do?submit=Refresh. Is there another way to do this? Is it worth suggesting that LookupDispatchAction support a default or null mapping? Regards, Brian. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: LookupDispatchAction default
From: Brian Sayatovic/AMIG [mailto:[EMAIL PROTECTED] I'd like to be able to have someone hit my action, /admin/list.do, without having to specify a submit paramater. Is there another way to do this? Is it worth suggesting that LookupDispatchAction support a default or null mapping? I'm not sure what version you're on, but look for the 'unspecified' method in DispatchAction, which is inherited by LookupDispatchAction. From the javadoc: http://jakarta.apache.org/struts/api/org/apache/struts/actions/Dispatch Action.html Method which is dispatched to when there is no value for specified request parameter included in the request. Subclasses of DispatchAction should override this method if they wish to provide default behavior different than throwing a ServletException. -- Wendy Smoak Application Systems Analyst, Sr. ASU IA Information Resources Management - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: LookupDispatchAction default
From: Mark Lowe [mailto:[EMAIL PROTECTED] unspecified() is the method you want look at the javadoc. you do need the method name though /admin/list.do?method I saw that using submit as the parameter name causes problems so i wouldn't use that. I agree about not using submit, if you end up needing to use JavaScript to change the value, you run into problems since submit() is already function. Calling either document.forms[0].submit.value=something or document.forms[0].submit() gives an error, I can't remember which. Bad idea, avoid it. ;) However, I have plenty of /admin/list.do links with no request parameters at all, and the unspecified method is called as described. (I use nightly builds, so I don't know when it started working that way...) -- Wendy Smoak Application Systems Analyst, Sr. ASU IA Information Resources Management - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: LookupDispatchAction default
I agree about not using submit, if you end up needing to use JavaScript to change the value, you run into problems since submit() is already function. Calling either document.forms[0].submit.value=something or document.forms[0].submit() gives an error, I can't remember which. Bad idea, avoid it. ;) It was you post on the thread last week where i pick it up. However, I have plenty of /admin/list.do links with no request parameters at all, and the unspecified method is called as described. (I use nightly builds, so I don't know when it started working that way...) Good to know that its been addressed, but I'm on whatever the stable release of 1.1 is. I'd like to be taking the source of 1.2 from cvs and helping to test it but i just cant be arsed with all that maven stuf. But i think i'd still stick to the stable release rather then get caught up in all that unknown territory stuff. On 24 Mar 2004, at 15:30, Wendy Smoak wrote: From: Mark Lowe [mailto:[EMAIL PROTECTED] unspecified() is the method you want look at the javadoc. you do need the method name though /admin/list.do?method I saw that using submit as the parameter name causes problems so i wouldn't use that. I agree about not using submit, if you end up needing to use JavaScript to change the value, you run into problems since submit() is already function. Calling either document.forms[0].submit.value=something or document.forms[0].submit() gives an error, I can't remember which. Bad idea, avoid it. ;) However, I have plenty of /admin/list.do links with no request parameters at all, and the unspecified method is called as described. (I use nightly builds, so I don't know when it started working that way...) -- Wendy Smoak Application Systems Analyst, Sr. ASU IA Information Resources Management - 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: LookupDispatchAction default
From: Mark Lowe [mailto:[EMAIL PROTECTED] It was you post on the thread last week where i pick it up. Sorry, I'm apparently repeating myself! I can't remember last week this early in the morning. Good to know that its been addressed, but I'm on whatever the stable release of 1.1 is. I'd like to be taking the source of 1.2 from cvs and helping to test it but i just cant be arsed with all that maven stuf. But i think i'd still stick to the stable release rather then get caught up in all that unknown territory stuff. I've been using nightly builds since forever, and I've never once built it from source. There's always a compiled version available along with the source. I do download the source and occasionally look at it or use it with JSwat, but building it is definitely not a prerequisite for using the latest and greatest. I have an Ant task that copies the .jars over from where I download and unzip the nightly builds. If I were really clever, I could probably convince Ant to figure out the filename and go get and expand the .zip files, then copy the .jar files. ;) The only weirdness with 1.2.0 I've found is that ActionError is deprecated but there is no replacement, so you get a bunch of warnings if you use it. I don't think you'll have a big problem going from 1.1 to 1.2. -- Wendy Smoak Application Systems Analyst, Sr. ASU IA Information Resources Management - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: LookupDispatchAction default
On 24 Mar 2004, at 16:13, Wendy Smoak wrote: From: Mark Lowe [mailto:[EMAIL PROTECTED] It was you post on the thread last week where i pick it up. Sorry, I'm apparently repeating myself! I can't remember last week this early in the morning. Good to know that its been addressed, but I'm on whatever the stable release of 1.1 is. I'd like to be taking the source of 1.2 from cvs and helping to test it but i just cant be arsed with all that maven stuf. But i think i'd still stick to the stable release rather then get caught up in all that unknown territory stuff. I've been using nightly builds since forever, and I've never once built it from source. There's always a compiled version available along with the source. I do download the source and occasionally look at it or use it with JSwat, but building it is definitely not a prerequisite for using the latest and greatest. I have an Ant task that copies the .jars over from where I download and unzip the nightly builds. If I were really clever, I could probably convince Ant to figure out the filename and go get and expand the .zip files, then copy the .jar files. ;) The only weirdness with 1.2.0 I've found is that ActionError is deprecated but there is no replacement, so you get a bunch of warnings if you use it. I don't think you'll have a big problem going from 1.1 to 1.2. Yeah .. I tried to make my 1.1 apps forward compatible with this by using ActionMessages but to no avail, which is really quite a pain. I was using html:errors tag to display but this is supposed to be okay but wasn't. -- Wendy Smoak Application Systems Analyst, Sr. ASU IA Information Resources Management - 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: LookupDispatchAction default value?
Danny Mui wrote:
I extended the dispatch action to do something like that:
in execute() {
ActionForward forward = null;
if (mapping.getParameter() == null ||
.equals(mapping.getParameter())) {
forward = executeAction(mapping, form, request, response);
} else {
forward = super.dispatchMethod(mapping,form,request,response,
mapping.getParameter());
}
return forward;
}
i'm a little weirder, i like to declaratively tell my action which to
execute. so extending the if statement to look at the request/form is
possible.
this may not be lookupdispatchaction but close enough i guess?
I don't quite understand where this code lives. Is this in a class that
extends Action? Or have you subclassed LookupDispatchAction and fixed
the execute() method?
--
Wendy
Re: LookupDispatchAction default value?
Sorry to have muddled the waters too much, I assumed too much...Having
looked at the LookupDispatchAction code, I can now make a slightly more
educated reply ;).
Yeah I think you're going to have to workaround the parent method.
public class DefaultLookup extends LookupDispatchAction {
public ActionForward execute(.){
if (request.getParameter(mapping.getParameter()) == null) {
return defaultMethod()
} else return super.execute();
}
public abstract ActionForward defaultMethod() ;
}
This should work! i think...
danny
Wendy Smoak wrote:
Danny Mui wrote:
I extended the dispatch action to do something like that:
in execute() {
ActionForward forward = null;
if (mapping.getParameter() == null ||
.equals(mapping.getParameter())) {
forward = executeAction(mapping, form, request, response);
} else {
forward = super.dispatchMethod(mapping,form,request,response,
mapping.getParameter());
}
return forward;
}
i'm a little weirder, i like to declaratively tell my action which to
execute. so extending the if statement to look at the request/form is
possible.
this may not be lookupdispatchaction but close enough i guess?
I don't quite understand where this code lives. Is this in a class that
extends Action? Or have you subclassed LookupDispatchAction and fixed
the execute() method?
--
To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
LookupDispatchAction default value?
I'm using LookupDispatchAction, which uses the 'action' request parameter to call the appropriate method. However, when the 'action' parameter is missing from the request, it dies as expected: javax.servlet.ServletException: Request[/processContact] does not contain handler parameter named action Is there a way to specify a default for the parameter it's supposed to use? If not, I was thinking of using a Filter to make sure that the request parameter is present, and to insert it if necessary. (Seems to me you can't add request parameters, only attributes, but I haven't tried it yet.) Have I missed something obvious or do you have any suggestions for handling this situation? Also, any advice for custom error pages? I have a custom page for my own DAOException class, but these are Error 500's, with different messages. Is it possible to have a different error page for does not contain handler parameter vs. other ServletExceptions that also show as code 500? -- Wendy Smoak http://sourceforge.net/projects/unidbtags
Re: LookupDispatchAction default value?
I extended the dispatch action to do something like that:
in execute() {
ActionForward forward = null;
if (mapping.getParameter() == null ||
.equals(mapping.getParameter())) {
forward = executeAction(mapping, form, request, response);
} else {
forward =
super.dispatchMethod(mapping,form,request,response, mapping.getParameter());
}
return forward;
}
i'm a little weirder, i like to declaratively tell my action which to
execute. so extending the if statement to look at the request/form is
possible.
this may not be lookupdispatchaction but close enough i guess?
well hth
Wendy Smoak wrote:
I'm using LookupDispatchAction, which uses the 'action' request parameter to
call the appropriate method.
However, when the 'action' parameter is missing from the request, it dies as
expected:
javax.servlet.ServletException: Request[/processContact] does not contain
handler parameter named action
Is there a way to specify a default for the parameter it's supposed to
use?
If not, I was thinking of using a Filter to make sure that the request
parameter is present, and to insert it if necessary. (Seems to me you can't
add request parameters, only attributes, but I haven't tried it yet.)
Have I missed something obvious or do you have any suggestions for handling
this situation?
Also, any advice for custom error pages? I have a custom page for my own
DAOException class, but these are Error 500's, with different messages.
Is it possible to have a different error page for does not contain handler
parameter vs. other ServletExceptions that also show as code 500?
--
To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
