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 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? 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. >> > > > -- View this message in context: http://old.nabble.com/How-to-access-HttpServletRequest-data-in-portletRequest-tp27290070p27345826.html Sent from the Pluto - Dev mailing list archive at Nabble.com.
