You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by "Mark R. Diggory" <md...@latte.harvard.edu> on 2004/06/18 00:54:33 UTC
ExtendedActionForward
I just finally joined the dev list, so pardon if this might be an old
subject but...
I came up with a simple Extension to ActionForward to manage the
addition of parameters in the forwards request and posted it on the
wiki. I have a version with even more functionality which allows the
replacing and removal of parameters and specific values of a parameter.
Is this something the project would have an interest in?
-Mark
Re: ExtendedActionForward
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
Finally (and I'll drop this thread afterward). Its interesting to note
that on Tomcat 4.1, the parameter map supplied via the
request.getParameterMap() in a JSP page is in fact "mutable" while that
returned in a Servlet request object is not! You can actually remove the
request parameters from the request object in a JSP page! I assume this
object is a copy of the original?
-Mark
Mark R. Diggory wrote:
> So here is a pruned down verison of my ExtendedActionForward. Martin,
> the request object constructor is there as a feature for when the
> forward is a redirect, using this constructor builds a redirect which
> also includes all the original parameters as well as those that were
> added.
>
> -Mark
>
>
> Mark R. Diggory wrote:
>
>> Not only that, I now understand that replace and remove can't be done
>> based on current RequestDispatcher behavior. This behavior is
>> slightly odd for RequestDispatcher though. Why if the
>> "getQueryString()" is completely replaced on forward, is not the
>> parameter map? Or from the opposit perspective, shouldn't the
>> getQueryString also contain the original parameters + new parameters
>> after the forward??? Odd!
>>
>> -Mark
>>
>> Mark R. Diggory wrote:
>>
>>> Duh, I see it now, yes your right, Thats a totally stupid mistake in
>>> my code, there are no problems with the forwarding behavior of
>>> Stuts...
>>>
>>> Isn't that always the case...;-)
>>> Mark
>>>
>>> Martin Cooper wrote:
>>>
>>>>
>>>>
>>>> On Fri, 18 Jun 2004, Mark R. Diggory wrote:
>>>>
>>>>> Martin,
>>>>>
>>>>> I looked into this a little deeper and I'm slightly baffled by
>>>>> something.
>>>>>
>>>>> javax.servlet.RequestDispatcher.forward(request,response);
>>>>>
>>>>> This method pretty much manages the forwarding of requests, and is
>>>>> what is used by the Servlet API and the JSP API's when doing
>>>>> forwarding. If I understand correctly, its behavior is such that
>>>>> when it is gotten from the servlet context using
>>>>>
>>>>> context.getRequestDispatcher(uri);
>>>>>
>>>>> if the uri has request parameters, then the Dispatcher manages to
>>>>> overload the request parameters with those encoded in the uri.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> It's not a question of overloading. If there are parameters in the
>>>> URI with the same names as parameters in the original request, then
>>>> *both* values will show up at the destination. You'll see this if
>>>> you try getParameterValues() instead of getParameter().
>>>
>>>
Re: ExtendedActionForward
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
So here is a pruned down verison of my ExtendedActionForward. Martin,
the request object constructor is there as a feature for when the
forward is a redirect, using this constructor builds a redirect which
also includes all the original parameters as well as those that were added.
-Mark
Mark R. Diggory wrote:
> Not only that, I now understand that replace and remove can't be done
> based on current RequestDispatcher behavior. This behavior is slightly
> odd for RequestDispatcher though. Why if the "getQueryString()" is
> completely replaced on forward, is not the parameter map? Or from the
> opposit perspective, shouldn't the getQueryString also contain the
> original parameters + new parameters after the forward??? Odd!
>
> -Mark
>
> Mark R. Diggory wrote:
>
>> Duh, I see it now, yes your right, Thats a totally stupid mistake in
>> my code, there are no problems with the forwarding behavior of Stuts...
>>
>> Isn't that always the case...;-)
>> Mark
>>
>> Martin Cooper wrote:
>>
>>>
>>>
>>> On Fri, 18 Jun 2004, Mark R. Diggory wrote:
>>>
>>>> Martin,
>>>>
>>>> I looked into this a little deeper and I'm slightly baffled by
>>>> something.
>>>>
>>>> javax.servlet.RequestDispatcher.forward(request,response);
>>>>
>>>> This method pretty much manages the forwarding of requests, and is
>>>> what is used by the Servlet API and the JSP API's when doing
>>>> forwarding. If I understand correctly, its behavior is such that
>>>> when it is gotten from the servlet context using
>>>>
>>>> context.getRequestDispatcher(uri);
>>>>
>>>> if the uri has request parameters, then the Dispatcher manages to
>>>> overload the request parameters with those encoded in the uri.
>>>
>>>
>>>
>>>
>>> It's not a question of overloading. If there are parameters in the
>>> URI with the same names as parameters in the original request, then
>>> *both* values will show up at the destination. You'll see this if
>>> you try getParameterValues() instead of getParameter().
>>
>>
>>
>>>
>>> In this situation, what you get with getParameter() is the same as
>>> what you get with getParameterValues()[0].
>>>
>>> Hope this helps.
>>>
>>> --
>>> Martin Cooper
>>>
>>>
>>>>
>>>> So I go to the Stuts code that facilitates forwarding
>>>>
>>>> RequestProcessor.doForward(...)
>>>>
>>>> and I find that it is (of course) using this facility properly
>>>>
>>>>> protected void doForward(
>>>>> String uri,
>>>>> HttpServletRequest request,
>>>>> HttpServletResponse response)
>>>>> throws IOException, ServletException {
>>>>> // Unwrap the multipart request, if there is one.
>>>>> if (request instanceof MultipartRequestWrapper) {
>>>>> request = ((MultipartRequestWrapper)
>>>>> request).getRequest();
>>>>> }
>>>>>
>>>>> RequestDispatcher rd =
>>>>> getServletContext().getRequestDispatcher(uri);
>>>>> if (rd == null) {
>>>>> response.sendError(
>>>>> HttpServletResponse.SC_INTERNAL_SERVER_ERROR,
>>>>> getInternal().getMessage("requestDispatcher", uri));
>>>>> return;
>>>>> }
>>>>> rd.forward(request, response);
>>>>> }
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> So this makes me suspect that Struts is actually unneccessarily
>>>> encoding the request parameters onto the "uri" (plusthe ones I add)
>>>> prior to making this call to doForward, but I havn't yet gotten
>>>> this deep.
>>>>
>>>> Does this make sense? This is why I believe the parameters would be
>>>> duplicated in my code when I add them by appending them to the uri.
>>>>
>>>> -Mark
>>>>
>>>>
>>>> Mark R. Diggory wrote:
>>>>
>>>>> Martin Cooper wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, 17 Jun 2004, Mark R. Diggory wrote:
>>>>>>
>>>>>>> I just finally joined the dev list
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Welcome!
>>>>>>
>>>>>>> , so pardon if this might be an old subject but...
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> It's been discussed a few times.
>>>>>>
>>>>>>> I came up with a simple Extension to ActionForward to manage the
>>>>>>> addition of parameters in the forwards request and posted it on
>>>>>>> the wiki. I have a version with even more functionality which
>>>>>>> allows the replacing and removal of parameters and specific
>>>>>>> values of a parameter. Is this something the project would have
>>>>>>> an interest in?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> What is the purpose of the constructor which takes a request?
>>>>>> Given that any request parameters will still exist as parameters
>>>>>> if the request is forwarded, I would expect the original
>>>>>> parameters to be duplicated if this constructor is used and the
>>>>>> request is forwarded. No?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Wow, I tested it, and your right. This will only work for a
>>>>> redirect, otherwise it duplicates the parameters (logical, and an
>>>>> oversight on my part).
>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Martin Cooper
>>>>>>
>>>>>>
>>>>> I think the answer to what the behavior should be in this case,
>>>>> and in the case of the feature request in bug tracking can be seen
>>>>> in the basic behavior of the jsp taglibrary:
>>>>>
>>>>> In the following case, the forward supplies only the "test2"
>>>>> parameter. Whereas:
>>>>> <jsp:forward page="Test2.jsp"> <jsp:param name="test2"
>>>>> value="test2"/> </jsp:forward>
>>>>>
>>>>> This forward supplies the parameters that were in the original
>>>>> request.
>>>>> <jsp:forward page="Test2.jsp"/>
>>>>>
>>>>> So this sort of thing has been considered before, prior to
>>>>> Struts... Its Apache code, or its probibly accessable in the JSP
>>>>> spec if it is not?
>>>>>
>>>>> -Mark
>>>>>
Re: ExtendedActionForward
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
Not only that, I now understand that replace and remove can't be done
based on current RequestDispatcher behavior. This behavior is slightly
odd for RequestDispatcher though. Why if the "getQueryString()" is
completely replaced on forward, is not the parameter map? Or from the
opposit perspective, shouldn't the getQueryString also contain the
original parameters + new parameters after the forward??? Odd!
-Mark
Mark R. Diggory wrote:
> Duh, I see it now, yes your right, Thats a totally stupid mistake in
> my code, there are no problems with the forwarding behavior of Stuts...
>
> Isn't that always the case...;-)
> Mark
>
> Martin Cooper wrote:
>
>>
>>
>> On Fri, 18 Jun 2004, Mark R. Diggory wrote:
>>
>>> Martin,
>>>
>>> I looked into this a little deeper and I'm slightly baffled by
>>> something.
>>>
>>> javax.servlet.RequestDispatcher.forward(request,response);
>>>
>>> This method pretty much manages the forwarding of requests, and is
>>> what is used by the Servlet API and the JSP API's when doing
>>> forwarding. If I understand correctly, its behavior is such that
>>> when it is gotten from the servlet context using
>>>
>>> context.getRequestDispatcher(uri);
>>>
>>> if the uri has request parameters, then the Dispatcher manages to
>>> overload the request parameters with those encoded in the uri.
>>
>>
>>
>> It's not a question of overloading. If there are parameters in the
>> URI with the same names as parameters in the original request, then
>> *both* values will show up at the destination. You'll see this if you
>> try getParameterValues() instead of getParameter().
>
>
>>
>> In this situation, what you get with getParameter() is the same as
>> what you get with getParameterValues()[0].
>>
>> Hope this helps.
>>
>> --
>> Martin Cooper
>>
>>
>>>
>>> So I go to the Stuts code that facilitates forwarding
>>>
>>> RequestProcessor.doForward(...)
>>>
>>> and I find that it is (of course) using this facility properly
>>>
>>>> protected void doForward(
>>>> String uri,
>>>> HttpServletRequest request,
>>>> HttpServletResponse response)
>>>> throws IOException, ServletException {
>>>> // Unwrap the multipart request, if there is one.
>>>> if (request instanceof MultipartRequestWrapper) {
>>>> request = ((MultipartRequestWrapper)
>>>> request).getRequest();
>>>> }
>>>>
>>>> RequestDispatcher rd =
>>>> getServletContext().getRequestDispatcher(uri);
>>>> if (rd == null) {
>>>> response.sendError(
>>>> HttpServletResponse.SC_INTERNAL_SERVER_ERROR,
>>>> getInternal().getMessage("requestDispatcher", uri));
>>>> return;
>>>> }
>>>> rd.forward(request, response);
>>>> }
>>>
>>>
>>>
>>>
>>> So this makes me suspect that Struts is actually unneccessarily
>>> encoding the request parameters onto the "uri" (plusthe ones I add)
>>> prior to making this call to doForward, but I havn't yet gotten this
>>> deep.
>>>
>>> Does this make sense? This is why I believe the parameters would be
>>> duplicated in my code when I add them by appending them to the uri.
>>>
>>> -Mark
>>>
>>>
>>> Mark R. Diggory wrote:
>>>
>>>> Martin Cooper wrote:
>>>>
>>>>>
>>>>>
>>>>> On Thu, 17 Jun 2004, Mark R. Diggory wrote:
>>>>>
>>>>>> I just finally joined the dev list
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Welcome!
>>>>>
>>>>>> , so pardon if this might be an old subject but...
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> It's been discussed a few times.
>>>>>
>>>>>> I came up with a simple Extension to ActionForward to manage the
>>>>>> addition of parameters in the forwards request and posted it on
>>>>>> the wiki. I have a version with even more functionality which
>>>>>> allows the replacing and removal of parameters and specific
>>>>>> values of a parameter. Is this something the project would have
>>>>>> an interest in?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> What is the purpose of the constructor which takes a request?
>>>>> Given that any request parameters will still exist as parameters
>>>>> if the request is forwarded, I would expect the original
>>>>> parameters to be duplicated if this constructor is used and the
>>>>> request is forwarded. No?
>>>>
>>>>
>>>>
>>>>
>>>> Wow, I tested it, and your right. This will only work for a
>>>> redirect, otherwise it duplicates the parameters (logical, and an
>>>> oversight on my part).
>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Martin Cooper
>>>>>
>>>>>
>>>> I think the answer to what the behavior should be in this case, and
>>>> in the case of the feature request in bug tracking can be seen in
>>>> the basic behavior of the jsp taglibrary:
>>>>
>>>> In the following case, the forward supplies only the "test2"
>>>> parameter. Whereas:
>>>> <jsp:forward page="Test2.jsp"> <jsp:param name="test2"
>>>> value="test2"/> </jsp:forward>
>>>>
>>>> This forward supplies the parameters that were in the original
>>>> request.
>>>> <jsp:forward page="Test2.jsp"/>
>>>>
>>>> So this sort of thing has been considered before, prior to
>>>> Struts... Its Apache code, or its probibly accessable in the JSP
>>>> spec if it is not?
>>>>
>>>> -Mark
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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: ExtendedActionForward
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
Duh, I see it now, yes your right, Thats a totally stupid mistake in my
code, there are no problems with the forwarding behavior of Stuts...
Isn't that always the case...;-)
Mark
Martin Cooper wrote:
>
>
> On Fri, 18 Jun 2004, Mark R. Diggory wrote:
>
>> Martin,
>>
>> I looked into this a little deeper and I'm slightly baffled by
>> something.
>>
>> javax.servlet.RequestDispatcher.forward(request,response);
>>
>> This method pretty much manages the forwarding of requests, and is
>> what is used by the Servlet API and the JSP API's when doing
>> forwarding. If I understand correctly, its behavior is such that when
>> it is gotten from the servlet context using
>>
>> context.getRequestDispatcher(uri);
>>
>> if the uri has request parameters, then the Dispatcher manages to
>> overload the request parameters with those encoded in the uri.
>
>
> It's not a question of overloading. If there are parameters in the URI
> with the same names as parameters in the original request, then *both*
> values will show up at the destination. You'll see this if you try
> getParameterValues() instead of getParameter().
>
> In this situation, what you get with getParameter() is the same as
> what you get with getParameterValues()[0].
>
> Hope this helps.
>
> --
> Martin Cooper
>
>
>>
>> So I go to the Stuts code that facilitates forwarding
>>
>> RequestProcessor.doForward(...)
>>
>> and I find that it is (of course) using this facility properly
>>
>>> protected void doForward(
>>> String uri,
>>> HttpServletRequest request,
>>> HttpServletResponse response)
>>> throws IOException, ServletException {
>>> // Unwrap the multipart request, if there is one.
>>> if (request instanceof MultipartRequestWrapper) {
>>> request = ((MultipartRequestWrapper) request).getRequest();
>>> }
>>>
>>> RequestDispatcher rd =
>>> getServletContext().getRequestDispatcher(uri);
>>> if (rd == null) {
>>> response.sendError(
>>> HttpServletResponse.SC_INTERNAL_SERVER_ERROR,
>>> getInternal().getMessage("requestDispatcher", uri));
>>> return;
>>> }
>>> rd.forward(request, response);
>>> }
>>
>>
>>
>> So this makes me suspect that Struts is actually unneccessarily
>> encoding the request parameters onto the "uri" (plusthe ones I add)
>> prior to making this call to doForward, but I havn't yet gotten this
>> deep.
>>
>> Does this make sense? This is why I believe the parameters would be
>> duplicated in my code when I add them by appending them to the uri.
>>
>> -Mark
>>
>>
>> Mark R. Diggory wrote:
>>
>>> Martin Cooper wrote:
>>>
>>>>
>>>>
>>>> On Thu, 17 Jun 2004, Mark R. Diggory wrote:
>>>>
>>>>> I just finally joined the dev list
>>>>
>>>>
>>>>
>>>>
>>>> Welcome!
>>>>
>>>>> , so pardon if this might be an old subject but...
>>>>
>>>>
>>>>
>>>>
>>>> It's been discussed a few times.
>>>>
>>>>> I came up with a simple Extension to ActionForward to manage the
>>>>> addition of parameters in the forwards request and posted it on
>>>>> the wiki. I have a version with even more functionality which
>>>>> allows the replacing and removal of parameters and specific values
>>>>> of a parameter. Is this something the project would have an
>>>>> interest in?
>>>>
>>>>
>>>>
>>>>
>>>> What is the purpose of the constructor which takes a request? Given
>>>> that any request parameters will still exist as parameters if the
>>>> request is forwarded, I would expect the original parameters to be
>>>> duplicated if this constructor is used and the request is
>>>> forwarded. No?
>>>
>>>
>>>
>>> Wow, I tested it, and your right. This will only work for a
>>> redirect, otherwise it duplicates the parameters (logical, and an
>>> oversight on my part).
>>>
>>>>
>>>>
>>>> --
>>>> Martin Cooper
>>>>
>>>>
>>> I think the answer to what the behavior should be in this case, and
>>> in the case of the feature request in bug tracking can be seen in
>>> the basic behavior of the jsp taglibrary:
>>>
>>> In the following case, the forward supplies only the "test2"
>>> parameter. Whereas:
>>> <jsp:forward page="Test2.jsp"> <jsp:param name="test2"
>>> value="test2"/> </jsp:forward>
>>>
>>> This forward supplies the parameters that were in the original request.
>>> <jsp:forward page="Test2.jsp"/>
>>>
>>> So this sort of thing has been considered before, prior to Struts...
>>> Its Apache code, or its probibly accessable in the JSP spec if it is
>>> not?
>>>
>>> -Mark
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>
>>
>>
Re: ExtendedActionForward
Posted by Martin Cooper <ma...@apache.org>.
On Fri, 18 Jun 2004, Mark R. Diggory wrote:
> Martin,
>
> I looked into this a little deeper and I'm slightly baffled by something.
>
> javax.servlet.RequestDispatcher.forward(request,response);
>
> This method pretty much manages the forwarding of requests, and is what is
> used by the Servlet API and the JSP API's when doing forwarding. If I
> understand correctly, its behavior is such that when it is gotten from the
> servlet context using
>
> context.getRequestDispatcher(uri);
>
> if the uri has request parameters, then the Dispatcher manages to overload
> the request parameters with those encoded in the uri.
It's not a question of overloading. If there are parameters in the URI
with the same names as parameters in the original request, then *both*
values will show up at the destination. You'll see this if you try
getParameterValues() instead of getParameter().
In this situation, what you get with getParameter() is the same as what
you get with getParameterValues()[0].
Hope this helps.
--
Martin Cooper
>
> So I go to the Stuts code that facilitates forwarding
>
> RequestProcessor.doForward(...)
>
> and I find that it is (of course) using this facility properly
>
>> protected void doForward(
>> String uri,
>> HttpServletRequest request,
>> HttpServletResponse response)
>> throws IOException, ServletException {
>> // Unwrap the multipart request, if there is one.
>> if (request instanceof MultipartRequestWrapper) {
>> request = ((MultipartRequestWrapper) request).getRequest();
>> }
>>
>> RequestDispatcher rd =
>> getServletContext().getRequestDispatcher(uri);
>> if (rd == null) {
>> response.sendError(
>> HttpServletResponse.SC_INTERNAL_SERVER_ERROR,
>> getInternal().getMessage("requestDispatcher", uri));
>> return;
>> }
>> rd.forward(request, response);
>> }
>
>
> So this makes me suspect that Struts is actually unneccessarily encoding the
> request parameters onto the "uri" (plusthe ones I add) prior to making this
> call to doForward, but I havn't yet gotten this deep.
>
> Does this make sense? This is why I believe the parameters would be
> duplicated in my code when I add them by appending them to the uri.
>
> -Mark
>
>
> Mark R. Diggory wrote:
>
>> Martin Cooper wrote:
>>
>>>
>>>
>>> On Thu, 17 Jun 2004, Mark R. Diggory wrote:
>>>
>>>> I just finally joined the dev list
>>>
>>>
>>>
>>> Welcome!
>>>
>>>> , so pardon if this might be an old subject but...
>>>
>>>
>>>
>>> It's been discussed a few times.
>>>
>>>> I came up with a simple Extension to ActionForward to manage the
>>>> addition of parameters in the forwards request and posted it on the
>>>> wiki. I have a version with even more functionality which allows the
>>>> replacing and removal of parameters and specific values of a
>>>> parameter. Is this something the project would have an interest in?
>>>
>>>
>>>
>>> What is the purpose of the constructor which takes a request? Given that
>>> any request parameters will still exist as parameters if the request is
>>> forwarded, I would expect the original parameters to be duplicated if
>>> this constructor is used and the request is forwarded. No?
>>
>>
>> Wow, I tested it, and your right. This will only work for a redirect,
>> otherwise it duplicates the parameters (logical, and an oversight on my
>> part).
>>
>>>
>>>
>>> --
>>> Martin Cooper
>>>
>>>
>> I think the answer to what the behavior should be in this case, and in the
>> case of the feature request in bug tracking can be seen in the basic
>> behavior of the jsp taglibrary:
>>
>> In the following case, the forward supplies only the "test2" parameter.
>> Whereas:
>> <jsp:forward page="Test2.jsp"> <jsp:param name="test2"
>> value="test2"/> </jsp:forward>
>>
>> This forward supplies the parameters that were in the original request.
>> <jsp:forward page="Test2.jsp"/>
>>
>> So this sort of thing has been considered before, prior to Struts... Its
>> Apache code, or its probibly accessable in the JSP spec if it is not?
>>
>> -Mark
>>
>> ------------------------------------------------------------------------
>>
>> ---------------------------------------------------------------------
>> 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: ExtendedActionForward
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
Martin,
I looked into this a little deeper and I'm slightly baffled by something.
javax.servlet.RequestDispatcher.forward(request,response);
This method pretty much manages the forwarding of requests, and is what
is used by the Servlet API and the JSP API's when doing forwarding. If I
understand correctly, its behavior is such that when it is gotten from
the servlet context using
context.getRequestDispatcher(uri);
if the uri has request parameters, then the Dispatcher manages to
overload the request parameters with those encoded in the uri.
So I go to the Stuts code that facilitates forwarding
RequestProcessor.doForward(...)
and I find that it is (of course) using this facility properly
> protected void doForward(
> String uri,
> HttpServletRequest request,
> HttpServletResponse response)
> throws IOException, ServletException {
>
> // Unwrap the multipart request, if there is one.
> if (request instanceof MultipartRequestWrapper) {
> request = ((MultipartRequestWrapper) request).getRequest();
> }
>
> RequestDispatcher rd =
> getServletContext().getRequestDispatcher(uri);
> if (rd == null) {
> response.sendError(
> HttpServletResponse.SC_INTERNAL_SERVER_ERROR,
> getInternal().getMessage("requestDispatcher", uri));
> return;
> }
> rd.forward(request, response);
> }
So this makes me suspect that Struts is actually unneccessarily encoding
the request parameters onto the "uri" (plusthe ones I add) prior to
making this call to doForward, but I havn't yet gotten this deep.
Does this make sense? This is why I believe the parameters would be
duplicated in my code when I add them by appending them to the uri.
-Mark
Mark R. Diggory wrote:
> Martin Cooper wrote:
>
>>
>>
>> On Thu, 17 Jun 2004, Mark R. Diggory wrote:
>>
>>> I just finally joined the dev list
>>
>>
>>
>> Welcome!
>>
>>> , so pardon if this might be an old subject but...
>>
>>
>>
>> It's been discussed a few times.
>>
>>> I came up with a simple Extension to ActionForward to manage the
>>> addition of parameters in the forwards request and posted it on the
>>> wiki. I have a version with even more functionality which allows the
>>> replacing and removal of parameters and specific values of a
>>> parameter. Is this something the project would have an interest in?
>>
>>
>>
>> What is the purpose of the constructor which takes a request? Given
>> that any request parameters will still exist as parameters if the
>> request is forwarded, I would expect the original parameters to be
>> duplicated if this constructor is used and the request is forwarded. No?
>
>
> Wow, I tested it, and your right. This will only work for a redirect,
> otherwise it duplicates the parameters (logical, and an oversight on
> my part).
>
>>
>>
>> --
>> Martin Cooper
>>
>>
> I think the answer to what the behavior should be in this case, and in
> the case of the feature request in bug tracking can be seen in the
> basic behavior of the jsp taglibrary:
>
> In the following case, the forward supplies only the "test2"
> parameter. Whereas:
> <jsp:forward page="Test2.jsp"> <jsp:param name="test2"
> value="test2"/> </jsp:forward>
>
> This forward supplies the parameters that were in the original request.
> <jsp:forward page="Test2.jsp"/>
>
> So this sort of thing has been considered before, prior to Struts...
> Its Apache code, or its probibly accessable in the JSP spec if it is not?
>
> -Mark
>
>------------------------------------------------------------------------
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>For additional commands, e-mail: dev-help@struts.apache.org
>
Re: ExtendedActionForward
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
Martin Cooper wrote:
>
>
> On Thu, 17 Jun 2004, Mark R. Diggory wrote:
>
>> I just finally joined the dev list
>
>
> Welcome!
>
>> , so pardon if this might be an old subject but...
>
>
> It's been discussed a few times.
>
>> I came up with a simple Extension to ActionForward to manage the
>> addition of parameters in the forwards request and posted it on the
>> wiki. I have a version with even more functionality which allows the
>> replacing and removal of parameters and specific values of a
>> parameter. Is this something the project would have an interest in?
>
>
> What is the purpose of the constructor which takes a request? Given
> that any request parameters will still exist as parameters if the
> request is forwarded, I would expect the original parameters to be
> duplicated if this constructor is used and the request is forwarded. No?
Wow, I tested it, and your right. This will only work for a redirect,
otherwise it duplicates the parameters (logical, and an oversight on my
part).
>
>
> --
> Martin Cooper
>
>
I think the answer to what the behavior should be in this case, and in
the case of the feature request in bug tracking can be seen in the basic
behavior of the jsp taglibrary:
In the following case, the forward supplies only the "test2" parameter.
Whereas:
<jsp:forward page="Test2.jsp">
<jsp:param name="test2" value="test2"/>
</jsp:forward>
This forward supplies the parameters that were in the original request.
<jsp:forward page="Test2.jsp"/>
So this sort of thing has been considered before, prior to Struts... Its
Apache code, or its probibly accessable in the JSP spec if it is not?
-Mark
Re: ExtendedActionForward
Posted by Martin Cooper <ma...@apache.org>.
On Thu, 17 Jun 2004, Mark R. Diggory wrote:
> I just finally joined the dev list
Welcome!
> , so pardon if this might be an old subject
> but...
It's been discussed a few times.
> I came up with a simple Extension to ActionForward to manage the addition of
> parameters in the forwards request and posted it on the wiki. I have a
> version with even more functionality which allows the replacing and removal
> of parameters and specific values of a parameter. Is this something the
> project would have an interest in?
What is the purpose of the constructor which takes a request? Given that
any request parameters will still exist as parameters if the request is
forwarded, I would expect the original parameters to be duplicated if this
constructor is used and the request is forwarded. No?
--
Martin Cooper
>
> -Mark
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: ExtendedActionForward
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
Gladly...
Hubert Rabago wrote:
>An extension to add parameters to the ActionForward! Join the club! :)
>
>Maybe you can add this to the enhancement request which covers this issue:
>http://issues.apache.org/bugzilla/show_bug.cgi?id=866
>
>Hubert
>
>--- "Mark R. Diggory" <md...@latte.harvard.edu> wrote:
>
>
>>I just finally joined the dev list, so pardon if this might be an old
>>subject but...
>>
>>I came up with a simple Extension to ActionForward to manage the
>>addition of parameters in the forwards request and posted it on the
>>wiki. I have a version with even more functionality which allows the
>>replacing and removal of parameters and specific values of a parameter.
>>Is this something the project would have an interest in?
>>
>>-Mark
>>
>>
>
>
>__________________________________________________
>Do You Yahoo!?
>Tired of spam? Yahoo! Mail has the best spam protection around
>http://mail.yahoo.com
>
>
Re: ExtendedActionForward
Posted by Hubert Rabago <ja...@yahoo.com>.
An extension to add parameters to the ActionForward! Join the club! :)
Maybe you can add this to the enhancement request which covers this issue:
http://issues.apache.org/bugzilla/show_bug.cgi?id=866
Hubert
--- "Mark R. Diggory" <md...@latte.harvard.edu> wrote:
> I just finally joined the dev list, so pardon if this might be an old
> subject but...
>
> I came up with a simple Extension to ActionForward to manage the
> addition of parameters in the forwards request and posted it on the
> wiki. I have a version with even more functionality which allows the
> replacing and removal of parameters and specific values of a parameter.
> Is this something the project would have an interest in?
>
> -Mark
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org