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
>
>
>