Hi zzkhan,
Sorry for the delayed response but I was too occupied with other tasks that
this one slipped by.
I have a few suggestions on your questions inline below.
HTH,
Ate
On 01/27/2010 08:54 PM, zzkhan wrote:
Ate, Thanks for the reply, Ive tried to answer/comment on your response below
and am eagerly waiting for some more feedback!
However, if you're willing to leverage pluto specific (e.g. proprietary to
the container/portal implementation) API, there are ways to access the full
client *Servlet* request parameter map.
Yes, at this stage I am williing to use pluto specific stuff if this gets me
running faster as time is more of a priority for me as opposed to future
portability of this app. Are you able to point me to the right direction in
terms of documentation/examples?
If you are developing standard portlets or targeting a solution which should
also work on portlet containers however, you should stick to the Portlet API
only and accept the above limitation (there are good reasons why you
shouldn't want/need to access the underlying Servlet
API directly).
There might even be other ways to solve your functional needs which stick to
the spec. but you'll have to explain them for us to be able to advise you in
that.
The overall context of the work I am doing is that we are trying to port an
existing (JSR168) portlet application from vignette to pluto.
One of the initial things we discovered was that the portlet uses some
information which initially lies (or is populated by other components e.g.
Filters) in the HttpServletRequest but is then made available in the
PortletRequest by some 'glue code' which is actually a couple of
customization classes (extending vignette base classes) that we developed
and hooked into the vignette portal that hosts the portlet.
What I am looking for is equivalent 'extension points' in Pluto which I can
use to achieve the same as what has been done using vignette. Specifically
this would be:
1) Making the ParameterMap from HttpServletRequest available in the
PortletRequest.
2) Be able to take any RequestAttribute from HttpServletRequest and make it
available in the PortletRequest.
I would agree to the principle that the portlet should not need access to
data in the underlying Servlet API but because in this instance I am
migrating an existing application which has been coded such that it relies
on ServletRequest data, I am trying not to change too much of the code and
instead followingp the approach of 'provide it what ever it needs to work'
if that makes any sense.
If you really want to use the Pluto specific API it'll depends on which
version of Pluto you're using (1.x and 2.x having a completely different
container implementation).
We are using Pluto 1.1.7
In Pluto 1.1.7, you should be able to retrieve the underlying servlet request
using the following:
HttpServletRequest servletRequest =
((org.apache.pluto.internal.InternalPortletRequest)portletRequest).getHttpServletRequest();
BTW, Jetspeed Portal (which uses the Pluto container) provides an
additional/optional configuration which removes the above described
restriction (per portlet if needed) thus providing all query string
parameters on the URL on a PortletRequest parameter map, without need to use
Jetspeed specific API. That still isn't portable to other portals but at
least you don't need to use a proprietary API to leverage it.
Have been playing around with jetspeed as well, can you point me to the
specfic place with the jetspeed documentation for this?
This needs you to configure one (or two, read full details about in links
below) configuration property,
"merge.portal.parameters.with.portlet.parameters" either globally in
jetspeed.properties or for only a specific portlet in
jetspeed-portlet.xml.
See:
http://portals.apache.org/jetspeed-2/deployguide/jetspeed-properties.html
and
http://portals.apache.org/jetspeed-2/deployguide/guide-registry.html
(search for merge.portal.parameters.with.portlet.parameters within those pages).
Ate Douma wrote:
On 01/26/2010 06:15 PM, Scott O'Bryan wrote:
Would this not be the same at the RequestParamMap in the Portlet
Request? I mean, there is no gaurentee, by spec, that the query string
is what you expect it to be.
>
> Scott
IMO: No and yes to the above two statements.
The PortletRequest parameter map will (by spec) only provide your with the
query string parameters as targeting the portlet itself.
No other parameters should and will be provided to the portlet.
Note: with Portlet 2.0, this might also included shared parameters, but
this still isn't the same as (all) the query string parameters in
the URL.
However, if you're willing to leverage pluto specific (e.g. proprietary to
the container/portal implementation) API, there are ways to
access the full client *Servlet* request parameter map.
If you are developing standard portlets or targeting a solution which
should also work on portlet containers however, you should stick to
the Portlet API only and accept the above limitation (there are good
reasons why you shouldn't want/need to access the underlying Servlet
API directly). There might even be other ways to solve your functional
needs which stick to the spec. but you'll have to explain them for us
to be able to advise you in that.
If you really want to use the Pluto specific API it'll depends on which
version of Pluto you're using (1.x and 2.x having a completely
different container implementation).
BTW, Jetspeed Portal (which uses the Pluto container) provides an
additional/optional configuration which removes the above described
restriction (per portlet if needed) thus providing all query string
parameters on the URL on a PortletRequest parameter map, without need to
use Jetspeed specific API. That still isn't portable to other portals but
at least you don't need to use a proprietary API to leverage it.
Regards,
Ate
On 01/23/2010 02:29 PM, zzkhan wrote:
Hi, I need to access query string parameters which are in the URL used
to
access the portal page on which my portlet is rendered. Essentially, I
am
after the Request Param Map object in the HttpServletRequest. Is there
anyway in pluto I can do this?
Thanks.
