Anyone willing to reply please?
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 > > 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-tp27290070p27473016.html Sent from the Pluto - Dev mailing list archive at Nabble.com.
