Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
2.2.0
-
None
-
None
Description
This problem was reported by Lance Zhang as seen below.
— On Sun, 8/16/09, Lance Zhang <lzhang51@yahoo.com> wrote:
> From: Lance Zhang <lzhang51@yahoo.com>
> Subject: Re: JS_PORTLET_HEAD_ELEMENTS in event of file download
> To: "Jetspeed Developers List" <jetspeed-dev@portals.apache.org>
> Date: Sunday, August 16, 2009, 4:02 PM
> I saw it is taking elements from the
> window, i guess this for the desktop, but can we change the
> code to be this way.
>
>
> if (!headElements.isEmpty())
> {
>
> out.println("<JS_PORTLET_HEAD_ELEMENTS>");
> for
> (KeyValue<String, Element> kvPair : headElements)
>
>
> out.print("</JS_PORTLET_HEAD_ELEMENTS>");
> }
>
>
>
>
>
>
> ----- Original Message ----
> From: Lance Zhang <lzhang51@yahoo.com>
> To: Jetspeed Developers List <jetspeed-dev@portals.apache.org>
> Sent: Sunday, August 16, 2009 9:42:13 AM
> Subject: JS_PORTLET_HEAD_ELEMENTS in event of file
> download
>
> Hi, David,
>
> I am trying to use the FileServerPortlet and I think there
> is an issue.
>
> The FileServe pipeline invokes the PortletValve, in the
> PortletAggregatorImpl, the writeHeadElements by default
> write
> JS_PORTLET_HEAD_ELEMENTS to the header. That makes the
> browser not able to recognize the PDF coming back.
>
> Once i commented out the section of code, the PDF seems
> coming back fine, is this a defect or something wrong in the
> config?
>
> If it is header, why it is not using addHeader?
>
> thanks/Lance
>
>
After looking into pipelines.xml, I found that there are two different portlet valves: portletValve and portletValveTitleInHeader. The former is for fileserver-pipeline and the latter is for the other pipelines.
So, I think we can check the "titleInHeader" member variable to decide whether head elements are to be included during portlet rendering for desktop.