portletspec3
  1. portletspec3
  2. PORTLETSPEC3-14

Errata: Clarification about the Portlet Title

    Details

      Description

      The JSR 286 spec defines several ways for setting the portlet title:

      1) The title can be set in a resource bundle.
      2) The title can be set in the portlet-info section of the portlet descriptor.
      3) The title can be set by overriding the GenericPortlet.getTitle() method.
      4) The title can be set during the render headers part of the render phase

      However, these are all optional ways of setting the title. It is not defined
      what happens when none of them are used. In that case, WebSphere Portal, at least,
      uses the <portlet-name> value from the portlet descriptor, which is mandatory.

      I don't know how the RI treats this case.

      Do we need to specify something here?

        Activity

        msnicklous created issue -
        Hide
        msnicklous added a comment -

        Updated the problem priority to "minor" from "major" ... corrected an oversight on my part.

        Show
        msnicklous added a comment - Updated the problem priority to "minor" from "major" ... corrected an oversight on my part.
        msnicklous made changes -
        Field Original Value New Value
        Priority Major [ 3 ] Minor [ 4 ]
        Hide
        julien_viet added a comment -

        We have a similar issue withGateIn portlet container : https://issues.jboss.org/browse/GTNPC-19 .

        Portlet 1.0 did not have this issue as specifying a portlet-info section was mandatory and this part was relaxed with portlet 2.0 leading to case where nothing could be specified.

        I don't know if the portlet-name is the most appropriate value (as it can be quite developer oriented), for instance if the portlet display name is available makes imho a better candidate (and it is localized).

        So I think we should say that it is correct to explicit title and in that case, the portlet container is free to pickup a title using the available information and the last resort value would be the portlet name.

        Show
        julien_viet added a comment - We have a similar issue withGateIn portlet container : https://issues.jboss.org/browse/GTNPC-19 . Portlet 1.0 did not have this issue as specifying a portlet-info section was mandatory and this part was relaxed with portlet 2.0 leading to case where nothing could be specified. I don't know if the portlet-name is the most appropriate value (as it can be quite developer oriented), for instance if the portlet display name is available makes imho a better candidate (and it is localized). So I think we should say that it is correct to explicit title and in that case, the portlet container is free to pickup a title using the available information and the last resort value would be the portlet name.
        Hide
        Neil Griffin added a comment -

        I don't know how the RI treats this case. Do we need to specify something here?

        If the <title>...</title> is missing in the portlet.xml descriptor, the Pluto throws an exception:

        Error rendering portlet portlet-name-from-descriptor.
        java.util.MissingResourceException: Can't find resource for bundle org.apache.pluto.driver.container.InlinePortletResourceBundle, key javax.portlet.title
        at java.util.ResourceBundle.getObject(ResourceBundle.java:374)
        at java.util.ResourceBundle.getString(ResourceBundle.java:334)
        at javax.portlet.GenericPortlet.getTitle(GenericPortlet.java:281)
        at javax.portlet.GenericPortlet.render(GenericPortlet.java:252)}}

        Liferay throws a similar exception:

        {{03:50:53,012 ERROR [http-bio-8080-exec-171][IncludeTag:253] Current URL /c/portal/render_portlet generates exception: Can't find resource for bundle com.liferay.portlet.PortletResourceBundle, key javax.portlet.title
        03:50:53,014 ERROR [http-bio-8080-exec-171][IncludeTag:154] java.util.MissingResourceException: Can't find resource for bundle com.liferay.portlet.PortletResourceBundle, key javax.portlet.title
        at java.util.ResourceBundle.getObject(ResourceBundle.java:374)
        at java.util.ResourceBundle.getString(ResourceBundle.java:334)
        at com.liferay.portal.util.PortalImpl.getPortletTitle(PortalImpl.java:3498)
        at com.liferay.portal.util.PortalUtil.getPortletTitle(PortalUtil.java:1065)}}

        Using <portlet-name> as a last resort seems fine to me.

        Show
        Neil Griffin added a comment - I don't know how the RI treats this case. Do we need to specify something here? If the <title>...</title> is missing in the portlet.xml descriptor, the Pluto throws an exception: Error rendering portlet portlet-name-from-descriptor. java.util.MissingResourceException: Can't find resource for bundle org.apache.pluto.driver.container.InlinePortletResourceBundle, key javax.portlet.title at java.util.ResourceBundle.getObject(ResourceBundle.java:374) at java.util.ResourceBundle.getString(ResourceBundle.java:334) at javax.portlet.GenericPortlet.getTitle(GenericPortlet.java:281) at javax.portlet.GenericPortlet.render(GenericPortlet.java:252)}} Liferay throws a similar exception: {{03:50:53,012 ERROR [http-bio-8080-exec-171] [IncludeTag:253] Current URL /c/portal/render_portlet generates exception: Can't find resource for bundle com.liferay.portlet.PortletResourceBundle, key javax.portlet.title 03:50:53,014 ERROR [http-bio-8080-exec-171] [IncludeTag:154] java.util.MissingResourceException: Can't find resource for bundle com.liferay.portlet.PortletResourceBundle, key javax.portlet.title at java.util.ResourceBundle.getObject(ResourceBundle.java:374) at java.util.ResourceBundle.getString(ResourceBundle.java:334) at com.liferay.portal.util.PortalImpl.getPortletTitle(PortalImpl.java:3498) at com.liferay.portal.util.PortalUtil.getPortletTitle(PortalUtil.java:1065)}} Using <portlet-name> as a last resort seems fine to me.
        Hide
        msnicklous added a comment -

        @Neil - interesting ... it appears we have an inconsistency between the spec and the RI here. The schema for the 2.0 deployment descriptor calls for both the title and the portlet-info elements to be optional:

        ==========
        ...
        <complexType name="portlet-infoType">
        <sequence>
           <element name="title" type="portlet:titleType" minOccurs="0"/>
           <element name="short-title" type="portlet:short-titleType" minOccurs="0"/>
           <element name="keywords" type="portlet:keywordsType" minOccurs="0"/>
        </sequence>
        ...
        <element name="resource-bundle" type="portlet:resource-bundleType" minOccurs="0"/>
        <element name="portlet-info" type="portlet:portlet-infoType" minOccurs="0"/>
        <element name="portlet-preferences" type="portlet:portlet-preferencesType" minOccurs="0"/>
        ...
        ==========
        

        I think Pluto seems to be working according to the Portlet 1.0 schema. Does it throw an exception when the entire portlet-info block is missing? If I read the portlet 1.0 schema correctly, the portlet-info block is optional, but when it is present the title element is mandatory. If Pluto is parsing according to the 1.0 schema in this point, it should not throw an exception when the entire portlet-info block is missing.

        I think the 2.0 schema describes the correct behavior, and that we should mention this situation in the appropriate section in the spec. The fallback behavior if no title is specified in any manner should be something like this: "If no title is specified, the portlet container can define the portlet title using any available information, for example through use of the portlet name."

        I'll look for the appropriate location in the spec, prepare a concrete change proposal, and post it here.

        Show
        msnicklous added a comment - @Neil - interesting ... it appears we have an inconsistency between the spec and the RI here. The schema for the 2.0 deployment descriptor calls for both the title and the portlet-info elements to be optional: ========== ... <complexType name="portlet-infoType"> <sequence> <element name="title" type="portlet:titleType" minOccurs="0"/> <element name="short-title" type="portlet:short-titleType" minOccurs="0"/> <element name="keywords" type="portlet:keywordsType" minOccurs="0"/> </sequence> ... <element name="resource-bundle" type="portlet:resource-bundleType" minOccurs="0"/> <element name="portlet-info" type="portlet:portlet-infoType" minOccurs="0"/> <element name="portlet-preferences" type="portlet:portlet-preferencesType" minOccurs="0"/> ... ========== I think Pluto seems to be working according to the Portlet 1.0 schema. Does it throw an exception when the entire portlet-info block is missing? If I read the portlet 1.0 schema correctly, the portlet-info block is optional, but when it is present the title element is mandatory. If Pluto is parsing according to the 1.0 schema in this point, it should not throw an exception when the entire portlet-info block is missing. I think the 2.0 schema describes the correct behavior, and that we should mention this situation in the appropriate section in the spec. The fallback behavior if no title is specified in any manner should be something like this: "If no title is specified, the portlet container can define the portlet title using any available information, for example through use of the portlet name." I'll look for the appropriate location in the spec, prepare a concrete change proposal, and post it here.
        Hide
        Neil Griffin added a comment -

        msnicklous wrote above:

        I think Pluto seems to be working according to the Portlet 1.0 schema. Does it throw an exception when the entire portlet-info block is missing?

        Yes, Pluto 2.0.3 throws java.util.MissingResourceException in the following cases:

        1. When the <portlet-title> element is missing
        2. When the <portlet-info> block is missing

        During our phone call, msnicklous asked:

        Would adding a doHeaders method set the title dynamically?

        Yes, on Pluto 2.0.3 adding a doHeaders() method made it possible to set the title dynamically.

        BUT on Liferay, the getTitle() method is called by the page layout engine prior to the portlet lifecycle being invoked, so the doHeaders() approach does not work in Liferay.

        Show
        Neil Griffin added a comment - msnicklous wrote above: I think Pluto seems to be working according to the Portlet 1.0 schema. Does it throw an exception when the entire portlet-info block is missing? Yes, Pluto 2.0.3 throws java.util.MissingResourceException in the following cases: 1. When the <portlet-title> element is missing 2. When the <portlet-info> block is missing During our phone call, msnicklous asked: Would adding a doHeaders method set the title dynamically? Yes, on Pluto 2.0.3 adding a doHeaders() method made it possible to set the title dynamically. BUT on Liferay, the getTitle() method is called by the page layout engine prior to the portlet lifecycle being invoked, so the doHeaders() approach does not work in Liferay.
        Show
        Neil Griffin added a comment - Test Portlet: https://github.com/ngriffin7a/portletbox/tree/master/issues/PORTLETSPEC3-14-portlet
        Hide
        msnicklous added a comment -

        As mentioned previously, it seems that according to the deployment descriptor schema, the <portlet-info>, <portlet-title> and <resource-bundle> elements are all optional, even though the Pluto implementation does not treat them as being optional.

        My take is that Pluto has a bug in this area, and that the elements should be handled as being optional. As a clarification, I propose the following change in the spec.

        Referring to the [latest version of the working document] (https://java.net/projects/portletspec3/downloads/download/WorkingDocs/PortletSpec3-20130708.pdf):
        On page 52 after line 16 add the following paragraph:
        =====
        The <portlet-info> and <resource-bundle> elements are optional in the deployment descriptor. If neither are present, the portlet title will not be explicitly defined. In this case, the portlet container can draw on other information, for example on the <portlet-name> or <display-name> values from the portlet descriptor, to define the portlet title.
        =====

        Show
        msnicklous added a comment - As mentioned previously, it seems that according to the deployment descriptor schema, the <portlet-info>, <portlet-title> and <resource-bundle> elements are all optional, even though the Pluto implementation does not treat them as being optional. My take is that Pluto has a bug in this area, and that the elements should be handled as being optional. As a clarification, I propose the following change in the spec. Referring to the [latest version of the working document] ( https://java.net/projects/portletspec3/downloads/download/WorkingDocs/PortletSpec3-20130708.pdf): On page 52 after line 16 add the following paragraph: ===== The <portlet-info> and <resource-bundle> elements are optional in the deployment descriptor. If neither are present, the portlet title will not be explicitly defined. In this case, the portlet container can draw on other information, for example on the <portlet-name> or <display-name> values from the portlet descriptor, to define the portlet title. =====
        Hide
        Neil Griffin added a comment -

        @msnicklous: Just to clarify, if neither are present, then it is left as an implementation detail?

        Show
        Neil Griffin added a comment - @msnicklous: Just to clarify, if neither are present, then it is left as an implementation detail?
        Hide
        msnicklous added a comment -

        implemented fix in spec.

        Show
        msnicklous added a comment - implemented fix in spec.
        msnicklous made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Hide
        msnicklous added a comment -

        reviewed on 20130730 and can be closed.

        Show
        msnicklous added a comment - reviewed on 20130730 and can be closed.
        msnicklous made changes -
        Status Resolved [ 5 ] Closed [ 6 ]

          People

          • Assignee:
            Unassigned
            Reporter:
            msnicklous
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: