Very dissappointed to see the response trend on this forum. There is already a great deficiancy of pluto documentation/examples on the internet which led me to this forum. It all seems to be going downhill for me unfortunately.
zzkhan wrote: > > 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-tp27290070p27695189.html Sent from the Pluto - Dev mailing list archive at Nabble.com.
