Re: How to access HttpServletRequest data in portletRequest

[zzkhan <zz...@gmail.com>]

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.

Re: How to access HttpServletRequest data in portletRequest

[zzkhan <zz...@gmail.com>]

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.