-
1. RequestDispatcher query string
rraposa Jan 7, 2011 10:56 AM (in response to rraposa)Never mind - I just figured it out. The parameter from the query string passed in to the include() method is available in the HttpRequest object - the "request" object in the JSP page.
The following code in test.jsp shows two ways to display the "message" parameter:
<div class="portlet-section-body">
<%= request.getParameter("message") %>
<br/>
<p>${request.message}</p>
</div>
This seems to contradict the JSR286 spec, which clearly states that query string parameters need to be aggregated as render parameters, and that these query parameters can override any previously defined render parameters.
-
2. RequestDispatcher query string
theute Jan 7, 2011 12:08 PM (in response to rraposa)Can you please open a JIRA for a deeper look ?
If you arlready have a simple portlet that shows the defect it would be great to attach it to the Jira
Thanks !
Thomas.
-
3. RequestDispatcher query string
trong.tran Jan 10, 2011 7:11 AM (in response to rraposa)Hi Rich,
As I understand in your case, the request object belongs RenderRequest class type and the request.getParameter method exactly returns the value of a render parameter.
So there is nothing wrong here :-)
-
4. RequestDispatcher query string
theute Jan 10, 2011 7:25 AM (in response to trong.tran)AFAIU, Rich says that this part of the spec isn't working:
*************
PLT.19.1.1 Query Strings in Request Dispatcher Paths
The getRequestDispatcher method of the PortletContext that creates
PortletRequestDispatcher objects using path information allows the optional
attachment of query string information to the path. For example, a Developer may obtain
a PortletRequestDispatcher by using the following code:
String path = "/raisons.jsp?orderno=5";
PortletRequestDispatcher rd = context.getRequestDispatcher(path);
rd.include(renderRequest, renderResponse);
Parameters specified in the query string used to create the PortletRequestDispatcher
must be aggregated with the portlet render parameters and take precedence over other
portlet render parameters of the same name passed to the included servlet or JSP. The
parameters associated with a PortletRequestDispatcher are scoped to apply only for
the duration of the include call.
*************
and <%= renderRequest.getParamter("message")%> in test.jsp doesn't return the value "Thank you!" in his case (I guess, I haven't tried)
-
5. RequestDispatcher query string
trong.tran Jan 10, 2011 7:32 AM (in response to theute)i have just tried this and it still works well for me.
Waiting for Rich to confirm what exactly is his case
-
6. RequestDispatcher query string
rraposa Jan 10, 2011 8:02 AM (in response to trong.tran)It is possible that I just don't understand the difference between a render parameter and a request parameter. Suppose I have the following code in my render method:
request.setAttribute("reply", "No thanks");
String path = "/jsp/myform.jsp?reply=Thank you!";
getPortletContext().getRequestDispatcher(path).include(request, response);
According to the spec, the query string parameter "reply" should be aggregated with the other render parameters, and take precedence over render parameters with the same name. Here is what myform.jsp looks like:
<portlet:defineObjects/>
EL: ${reply}
Render request: <%= renderRequest.getParameter("reply") %>
Request: <%= request.getParameter("reply") %>
The output does not seem consistent with the spec:
EL: No thanks
Render request: null
Request: Thank you!
Notice the Expression Language for ${reply} is "No thanks", the renderRequest object doesn't have a parameter named "reply", but the HttpRequest object contains the overridden value. My question is: how come the renderRequest object does not contain a parameter named "reply" whose value is "Thank you!"? And how did the EL value of ${reply} end up being "No thanks"?
-
7. RequestDispatcher query string
trong.tran Jan 10, 2011 10:51 PM (in response to rraposa)Yes, you are right. it was my misunderstanding and thanks for your clarification, Rich.
it looks like a bug in the tablib implementation for the portlet spec. Could you open a JIRA as Thomas asked ?
-
8. RequestDispatcher query string
rraposa Jan 10, 2011 11:25 PM (in response to trong.tran)I already did! Here it is:
https://issues.jboss.org/browse/GTNPORTAL-1750
Let me know if I can do anything to help.
Thanks!
Rich
-
9. RequestDispatcher query string
mwringe Jan 13, 2011 5:38 PM (in response to rraposa)Parameters specified in the query string used to create the PortletRequestDispatcher
must be aggregated with the portlet render parameters and take precedence over other
portlet render parameters of the same name passed to the included servlet or JSP. The
parameters associated with a PortletRequestDispatcher are scoped to apply only for
the duration of the include call.
I am reading this as follows:
1) the PortletRequestDispatcher contains its own set of parameters (note: not the same thing as RenderRequest parameters)
2) the PortletRequestDispatcher's must contain the same parameters as the portlet render parameters ("... must be aggregated with the portlet render parameters...")
3) if the PortletRequestDispatcher's path contains query strings, those parameters must be added to the PortletRequestDispatcher's list of parameters and override any parameters added in step 2 from the portlet render parameters
I don't view this as a way to modify the RenderRequest parameters.
The way I view this is that the RenderRequest paramters will not change, but the Request parameters will (which is what seems to be the case with your tests).
-
10. RequestDispatcher query string
rraposa Jan 13, 2011 9:24 PM (in response to mwringe)Matt,
Thanks for the response. I agree - adding a parameter to a query string doesn't change a RenderRequest parameter permanently, but it *should* change for the scope of the included JSP or Servlet. And if it's not a render parameter in the included JSP or servlet, then what is it?
An included JSP has access to render parameters, and the spec states that query string parameters must take precedence over existing render request parameters, at least for the scope of the JSP. I am either oversimplifying this or I'm missing something. Are you sure your statement #1 above is accurate? If it is, how are these PortletRequestDispatcher parameters accessed in the JSP? That might help me understand better.
Thanks for your help!
Rich
-
11. RequestDispatcher query string
mwringe Jan 14, 2011 9:32 AM (in response to rraposa)Thanks for the response. I agree - adding a parameter to a query string doesn't change a RenderRequest parameter permanently, but it *should* change for the scope of the included JSP or Servlet. And if it's not a render parameter in the included JSP or servlet, then what is it?
I don't think it should be touching the RenderRequest at all, I believe this has to do only with the Request of the servlet, not the RenderRequest of the portlet.
query string parameters must take precedence over existing render request parameters, at least for the scope of the JSP.
I read this as meaning:
1) the Request needs to contain the same set of parameters as the RenderRequest and also any parameters included as query strings in the path. There are two separate parameter lists.
2) the query string parameters need to take precedence in the Request parameter list. In this case, it means that if the query string contains the same parameter as one which was included in the RenderRequest, the query string value needs to take precedence (as in take precedence in the Request parameter list, not the RenderRequest parameter lists).
From the spec, I believe it should work as follows:
- RenderParameters: name1 = value1 name2=value2
- path for request dispatcher: /test.jsp?name1=value3
Then from the jsp:
request.getParameter("name1") -> value3
request.getParameter("name2") -> value2
renderRequest.getParameter("name1") -> value1
renderRequest.getParameter("name2") -> value2
-
12. RequestDispatcher query string
trong.tran Jan 15, 2011 1:57 AM (in response to mwringe)From the spec, I believe it should work as follows:
- RenderParameters: name1 = value1 name2=value2
- path for request dispatcher: /test.jsp?name1=value3
Then from the jsp:
request.getParameter("name1") -> value3
request.getParameter("name2") -> value2
renderRequest.getParameter("name1") -> value1
renderRequest.getParameter("name2") -> value2
Yes, that is exactly what is expected from the spec i think
-
13. RequestDispatcher query string
rraposa Jan 15, 2011 10:07 AM (in response to trong.tran)Matt and Trong - thank you for the clarification! I appreciate your time.
So with the example being used here:
- RenderParameters: name1 = value1 name2=value2
- path for request dispatcher: /test.jsp?name1=value3
What do you think the output of the following should be in test.jsp:
${name1}
In other words, is the Expression Language a shortcut to the renderRequest parameters or the request parameters?
Thanks!
Rich
P.S.: By the way, the output of ${name1} will be value1.
-
14. RequestDispatcher query string
trong.tran Jan 17, 2011 11:35 PM (in response to rraposa)Rich Raposa wrote:
Matt and Trong - thank you for the clarification! I appreciate your time.
So with the example being used here:
- RenderParameters: name1 = value1 name2=value2
- path for request dispatcher: /test.jsp?name1=value3
What do you think the output of the following should be in test.jsp:
${name1}
In other words, is the Expression Language a shortcut to the renderRequest parameters or the request parameters?
Thanks!
Rich
P.S.: By the way, the output of ${name1} will be value1.
I think it makes sense to returns the same value as request.getParameter("name1"), that is value3. Anyway it's just my opinion as these are not very clear in spec from my reading. Somebody who has good experienced view on this could tell something more persuasively