PortletRequest.getResponseContentTypes() question

[Robert Michel <bo...@codecore.com>]

I have a couple questions regarding the 
PortletRequest.getResponseContentTypes() method.  I'm not sure to what 
degree this may be an issue for Pluto.

The API doc says:  Only content types that the portlet has defined in 
its deployment descriptor are valid return values for this method call.

PortletRequestImpl.getResponseContentTypes() delegates to 
DynamicInformationProvider.getResponseContentTypes().  The container is 
not checking if the return value is defined in the deployment 
descriptor.  Is it assumed that the portal will do this?  (The portal 
with Pluto actually just sends "text/html".)

Additionally, the API doc says: If the portlet has defined '*' or '* / 
*' as supported content types, these may also be valid return values.

Why would a portlet define a '*' or '*/*' content type?  This can't 
possibly mean that the portlet supports all possible content types, can 
it?  My assumption is that it means that the portlet wants to get a 
render call regardless of the portal's current response content type.  
If this is the case, and the portlet produces some funky content-type 
response, does the portal need to check and toss out the response if 
it's not supported by the portal?

Let's say a portal is building an HTML page and is looking for portlets 
that support "text/html" content-type.  It runs across one that supports 
"*/*", but not explicitly "text/html".  What happens when the portlet 
calls PortletRequestImpl.getResponseContentType()?  According to the 
spec, the return must be defined in a deployment descriptor, which 
implies that "*/*" is the only valid return.  If this comes back, how 
does the portlet know the portal is looking for "text/html"?

Maybe the spec should really say: Only content types that are 
_supported_ by the definitions in the deployment descriptor are valid 
return results.  Then the DynamicInformationProvider can safely return 
"text/html" (because */* supports text/html).  My guess is this is the 
actual intent of the spec.

Finally, in RenderResponseImpl.java, setting the content type doesn't 
seem to have any effect:

    public void setContentType(String type)
    {
        String mimeType = stripCharacterEncoding(type);
        if (!isValidContentType(mimeType)) {
            throw new IllegalArgumentException(mimeType);
        }
        this._getHttpServletResponse().setContentType(mimeType);
        currentContentType = mimeType;
    }

The call to this._getHttpServletResponse().setContentType(mimeType) 
appears to be meaningless.  I'm assuming the underlying 
HttpServletResponse belongs to a real servlet operated by the portal.  
The content type for this response is presumably  set by the portal and 
a PrintWriter may have already been given out.  So subsequent calls made 
by portlets might either do nothing or override the content type set by 
the portal.  If this is indeed the case, I'd be happy to bring it up to 
spec.

Thanks,

Robert

RE: PortletRequest.getResponseContentTypes() question

[sg...@apache.org]

The ability to set the content type is useful in the following
situations:
1.  The Portal implementation displays portlets in inline frames
2.  The Portal can accept more than one content type which it translates
to the ultimate content type of the page.  For instance, if the content
type of the portal page is text/html, the Portal can allow text/xml and
apply an XSL stylesheet before writing the content to the final
response.
3.  For a particular window state, the portal may display no decorations
and allow the portlet to provide all content for the page in any content
type. 

I haven't looked at Pluto code, but the implementation that you showed
below does seem a bit odd.

Scott

> > Finally, in RenderResponseImpl.java, setting the content type
doesn't
> > seem to have any effect:
> >
> >    public void setContentType(String type)
> >    {
> >        String mimeType = stripCharacterEncoding(type);
> >        if (!isValidContentType(mimeType)) {
> >            throw new IllegalArgumentException(mimeType);
> >        }
> >        this._getHttpServletResponse().setContentType(mimeType);
> >        currentContentType = mimeType;
> >    }
> >
> > The call to this._getHttpServletResponse().setContentType(mimeType)
> > appears to be meaningless.  I'm assuming the underlying
> > HttpServletResponse belongs to a real servlet operated by the
portal.
> 
> All portlets are wrapped as servlets in pluto, therefore this belongs
to
> the response of the portlet.
> 
> > The content type for this response is presumably  set by the portal
and
> > a PrintWriter may have already been given out.  So subsequent calls
made
> > by portlets might either do nothing or override the content type set
by
> > the portal.  If this is indeed the case, I'd be happy to bring it up
to
> > spec.
> >
> 
> That is true for the sample portal where only one writer is used, but
> may be different for other portal implementations.
> 
> > Thanks,
> >
> > Robert
> >
> >
> >
> 
> 
> Stefan

Re: PortletRequest.getResponseContentTypes() question

[Stefan Hepper <st...@hursley.ibm.com>]

Hi Robert,


Robert Michel wrote:
> 
> I have a couple questions regarding the 
> PortletRequest.getResponseContentTypes() method.  I'm not sure to what 
> degree this may be an issue for Pluto.
> 
> The API doc says:  Only content types that the portlet has defined in 
> its deployment descriptor are valid return values for this method call.
> 
> PortletRequestImpl.getResponseContentTypes() delegates to 
> DynamicInformationProvider.getResponseContentTypes().  The container is 
> not checking if the return value is defined in the deployment 
> descriptor.  Is it assumed that the portal will do this?  (The portal 
> with Pluto actually just sends "text/html".)
> 

Yes, this needs to be checked by the portal, as the portal set the 
response content types and not the portlet container.
True, that our simple sample portal does not check this and always set 
text/html.


> Additionally, the API doc says: If the portlet has defined '*' or '* / 
> *' as supported content types, these may also be valid return values.
> 
> Why would a portlet define a '*' or '*/*' content type?  This can't 
> possibly mean that the portlet supports all possible content types, can 
> it?  My assumption is that it means that the portlet wants to get a 
> render call regardless of the portal's current response content type.  
> If this is the case, and the portlet produces some funky content-type 
> response, does the portal need to check and toss out the response if 
> it's not supported by the portal?
> 

What is the difference between these two? For the portal it means that 
it can send render requests for any content type to this portlet. This 
is useful if you have proxy portlets or iFrame portlets.

> Let's say a portal is building an HTML page and is looking for portlets 
> that support "text/html" content-type.  It runs across one that supports 
> "*/*", but not explicitly "text/html".  What happens when the portlet 
> calls PortletRequestImpl.getResponseContentType()?  According to the 
> spec, the return must be defined in a deployment descriptor, which 
> implies that "*/*" is the only valid return.  If this comes back, how 
> does the portlet know the portal is looking for "text/html"?
> 

The container can set this, here what the spec says:
"If a portlet defines support for all content types using a wildcard and 
the portlet container supports all content types, the 
getResponseContentType may return the wildcard or the portlet container 
preferred content type."


> Maybe the spec should really say: Only content types that are 
> _supported_ by the definitions in the deployment descriptor are valid 
> return results.  Then the DynamicInformationProvider can safely return 
> "text/html" (because */* supports text/html).  My guess is this is the 
> actual intent of the spec.
> 
> Finally, in RenderResponseImpl.java, setting the content type doesn't 
> seem to have any effect:
> 
>    public void setContentType(String type)
>    {
>        String mimeType = stripCharacterEncoding(type);
>        if (!isValidContentType(mimeType)) {
>            throw new IllegalArgumentException(mimeType);
>        }
>        this._getHttpServletResponse().setContentType(mimeType);
>        currentContentType = mimeType;
>    }
> 
> The call to this._getHttpServletResponse().setContentType(mimeType) 
> appears to be meaningless.  I'm assuming the underlying 
> HttpServletResponse belongs to a real servlet operated by the portal.  

All portlets are wrapped as servlets in pluto, therefore this belongs to 
the response of the portlet.

> The content type for this response is presumably  set by the portal and 
> a PrintWriter may have already been given out.  So subsequent calls made 
> by portlets might either do nothing or override the content type set by 
> the portal.  If this is indeed the case, I'd be happy to bring it up to 
> spec.
> 

That is true for the sample portal where only one writer is used, but 
may be different for other portal implementations.

> Thanks,
> 
> Robert
> 
> 
> 


Stefan