You are viewing a plain text version of this content. The canonical link for it is here.
Posted to pluto-user@portals.apache.org by Stefan Hepper <st...@hursley.ibm.com> on 2003/12/01 18:24:03 UTC

Re: why getPortletOutputStream()?

That was a requirement from iFrame-based portals that use the browser as 
aggregation engine and perform calls for each iFrame to the portal. The 
MIME types for each iFrame can be different (so one page really has 
multiple MIME types) and a portlet acting as a proxy for these iFrames 
does not know in advance which MIME types to serve. Therefore we allowed 
the */* as MIME type in the DD. Thus the same proxy portlet can serve 
html in one request and pdfs in the next request.

This is not explicitly mentioned in the spec as it is not the 
recommended programming model, as it bypasses the portlet API.

Stefan

Glenn R. Golden wrote:

> Can you say more about iFrame portlets and binary output and browser 
> aggregation, and how this is different from markup portlets that the 
> portal engine aggregates?  I didn't see any of this from my read of the 
> portlet spec.
> 
> Thanks.
> 
> - Glenn
> 
> On Thursday, November 27, 2003, at 02:46  PM, Stefan Hepper wrote:
> 
>> We put this into the API to allow iFrame portlets to produce binary 
>> output that would be aggregated on the browser.
>>
>> Stefan
>>
>> Tony Field wrote:
>>
>>> Hi pluto-users...
>>> If the portlet spec says portlets render mark-up fragments, why do we 
>>> provide a mechanism to stream bytes (using getPortletOutputStream())? 
>>>  Does "mark-up fragment" imply bytes in addition to just characters?
>>> Thanks,
>>> Tony
> 
> 
>