|
Home > Archive > WebSphere Portal Server > January 2004 > Setting content type on PortletResponse object
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Setting content type on PortletResponse object
|
|
| Jon Mell 2004-01-19, 3:00 pm |
| Hi,
Is there any way to set the contentType on a PortletResponse object? I
want a portlet to 'stream' a file to the browser so that it asks the user
whether it wants to download the file. In a servlet if I set the contentType
to something unknown by the browser this works. In the View method of my
portlet I have the following code:
PrintWriter outputStream=response.getWriter();
response.setContentType("portal/content");
outputStream.write(contentToBeDownloaded);
outputStream.flush();
outputStream.close();
However, this just outputs the content to the portal. Further, if I call
response.getContentType() it is set still to "text/html; charset=UTF-8".
Is there anyway to (temporarily) change this?
Thanks,
Jon
| |
| Michael Harris 2004-01-19, 3:00 pm |
| You can't change the content type in a portlet because the output of a
portlet is always combined with other HTML (or other markup) to build a full
page. To change the content type requires that your portlet control the
entire page (which it can't do). As such, it is not possible for a portlet
to push a file to the browser using the portletResponse object.
To do what you want, you need to package a servlet with your portlet which
returns the content you want to push to the client. Then you need to get
the browser to initate a separate connection to the URL of the servlet. You
can do this in many ways such as providing the user with a link to click on,
or as the href in an <iframe>.
| |
| Jon Mell 2004-01-19, 3:00 pm |
| Thanks - I thought of that, but such a servlet would require information in
the Portal session (which is where the required content sits)... which it
would not be able to access, and a Portlet cannot put that information in
the 'true' HTTPSession which the servlet could access. Unless I am missing
something...?
Jon
"Michael Harris" <none@none.com> wrote in message
news:bp0qbj$7ec6$1@news.boulder.ibm.com...quote:
> You can't change the content type in a portlet because the output of a
> portlet is always combined with other HTML (or other markup) to build a
fullquote:
> page. To change the content type requires that your portlet control the
> entire page (which it can't do). As such, it is not possible for a
portletquote:
> to push a file to the browser using the portletResponse object.
>
> To do what you want, you need to package a servlet with your portlet which
> returns the content you want to push to the client. Then you need to get
> the browser to initate a separate connection to the URL of the servlet.
Youquote:
> can do this in many ways such as providing the user with a link to click
on,quote:
> or as the href in an <iframe>.
>
>
>
| |
| Michael Harris 2004-01-19, 3:00 pm |
| You aren't missing anything. What you need is to create a way for the
information to flow from the portlet to the servlet. There are a lot of
different ways to get the data from the portlet to the servlet... each has
its own architecture, security, and performance issues:
1. put the data on the URL to the servlet - This solution is the simplest
for string data. But it isn't secure since the data is passing "in the
clear" over the HTTP stream and is viewable in the browser.
2. put the data in the ServletContext - This solution keeps all of the data
on the server but it isn't clusterable and you need to use the sessionID as
part of your keys to partition each user's data from the other. (The
ServletContext is shared by all users.) Since you cannot guarantee that the
servlet will be called (such as in the case of a network outage at just the
wrong time), you need to remove the data when the portlet's logout() method
is called in addition to in the servlet. (logout is called when the user's
session times out.) If you don't remove the data from the ServletContext on
logout(), the data will never get garbage collected.
3. put the data in a custom portlet service or other Java library you
write - This solution has the exact same issues as using the ServletContext
as long as the data remains inside the JVM. If you use the portlet service
to access an external data source, then it has the kinds of characteristics
in the next example (#4).
4. put the data in an external data store such as a database - This solution
is clusterable however, be sure to have a way to orphan the data in case it
is never retrieved.
5. push the data to the servlet by calling the servlet URL with a special
parameter directly from the portlet - This solution should be clusterable
and orphaning isn't a problem since the data is stored in the servlet's
session. Performance and streaming of the data across an HTTP connection
are the main issues with this technique.
6. Use an unsupported, undocumented technique for accessing a shared HTTP
session. There are ways to access a shared HTTP session object from both
the portlet and the servlet. However, they are different for each version
of WPS and sometimes the APIs even changes in a fixpack. (This is why it
isn't supported or documented.) Some of these techniques have been posted
in this newsgroup in the past. Use this technique at your own risk knowing
that your code will likely break in the future.
|
|
|
|
|