Jetspeed 2
  1. Jetspeed 2
  2. JS2-944

PortletDefinition Language needs to indicate if its locale is a supported-locale as defined by or for the Portlet descriptor

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.2.0
    • Fix Version/s: 2.2.0
    • Component/s: Container, Portlet Registry
    • Labels:
      None

      Description

      The Portlet API 2.0 TCK has a check for no supported/specified locales in the portlet descriptor.
      This means that PortletConfig.getSupportedLocales() should in that case return an empty Enumeration.
      As Jetspeed maps and stores the supported locales and the (possibly) provided predefined portlet "PortletInfo" elements from a resource bundle in its Language OM, we need to keep track if a Language is created for such a supported-locale definition by or for the Portlet descriptor.

      Most specifically, the "default" (English) Language is always created and on the fly by Jetspeed (and should not be allowed to be removed!)
      using either the inline PortletInfo definition in the portlet descriptor or, if a ResourceBundle is provided, taking overrides from its English ResourceBundle.
      If however there is no <supported-locale>en</supported-locale> defined, this "default" Language may not be used to represent the formally supported locales.

      This will be implemented by adding a supportedLocale boolean on Language and only set to true for those locales as specified by <supported-locale/> definitions in the portlet descriptor.

        Activity

        Ate Douma created issue -
        Ate Douma made changes -
        Field Original Value New Value
        Summary PortletDefinition Languages needs to provide one instance representing the default inline "supports" elements of the portlet descriptor (without Locale) PortletDefinition Languages needs to provide one instance representing the default inline "PortletInfo elements of the portlet descriptor (without Locale)
        Description The Portlet API 2.0 TCK has a check for no supported/specified locales in the portlet descriptor.
        This means that PortletConfig.getSupportedLocales() should in that case return an empty Enumeration.
        As Jetspeed maps and stores the supported locales and the (possibly) provided predefined portlet "supports" elements from a resource bundle in its Language OM, we need to store always one instance thereof *without* a Locale to represent this use-case.

        Currently the Language OM is stored with the *required* locale_string column in the database however as we assumed the inline definition to correspond with the English Locale (which *is* the required default Locale).
        However, as theoretically a English resourcebundle can be provided with values different from the inline "supports" elements (title, short-title, keywords), there is indeed a need to distinguish these from each other.

        I'll fix this "bug" by changing the locale_string to become optional and always store the inline definition of these "supports" elements (if even specified) separately from a possible English locale version.
        Note: if none of these "supports" elements is provided inline in the portlet.xml descriptor, this will lead to an entry with *no* values (other than the required FK) at all.

        In addition, the logic for retrieval and handling of the defaul "supports" values will have to be adjusted as well.
        The Portlet API 2.0 TCK has a check for no supported/specified locales in the portlet descriptor.
        This means that PortletConfig.getSupportedLocales() should in that case return an empty Enumeration.
        As Jetspeed maps and stores the supported locales and the (possibly) provided predefined portlet "PortletInfo" elements from a resource bundle in its Language OM, we need to store always one instance thereof *without* a Locale to represent this use-case.

        Currently the Language OM is stored with the *required* locale_string column in the database however as we assumed the inline definition to correspond with the English Locale (which *is* the required default Locale).
        However, as theoretically a English resourcebundle can be provided with values different from the inline "PortletInfo" elements (title, short-title, keywords), there is indeed a need to distinguish these from each other.

        I'll fix this "bug" by changing the locale_string to become optional and always store the inline definition of these "PortletInfo" elements (if even specified) separately from a possible English locale version.
        Note: if none of these "PortletInfo" elements is provided inline in the portlet.xml descriptor, this will lead to an entry with *no* values (other than the required FK) at all.

        In addition, the logic for retrieval and handling of the default "PortletInfo" values will have to be adjusted as well.
        Ate Douma made changes -
        Summary PortletDefinition Languages needs to provide one instance representing the default inline "PortletInfo elements of the portlet descriptor (without Locale) PortletDefinition Language needs to indicate if its locale is a supported-locale as defined by or for the Portlet descriptor
        Description The Portlet API 2.0 TCK has a check for no supported/specified locales in the portlet descriptor.
        This means that PortletConfig.getSupportedLocales() should in that case return an empty Enumeration.
        As Jetspeed maps and stores the supported locales and the (possibly) provided predefined portlet "PortletInfo" elements from a resource bundle in its Language OM, we need to store always one instance thereof *without* a Locale to represent this use-case.

        Currently the Language OM is stored with the *required* locale_string column in the database however as we assumed the inline definition to correspond with the English Locale (which *is* the required default Locale).
        However, as theoretically a English resourcebundle can be provided with values different from the inline "PortletInfo" elements (title, short-title, keywords), there is indeed a need to distinguish these from each other.

        I'll fix this "bug" by changing the locale_string to become optional and always store the inline definition of these "PortletInfo" elements (if even specified) separately from a possible English locale version.
        Note: if none of these "PortletInfo" elements is provided inline in the portlet.xml descriptor, this will lead to an entry with *no* values (other than the required FK) at all.

        In addition, the logic for retrieval and handling of the default "PortletInfo" values will have to be adjusted as well.
        The Portlet API 2.0 TCK has a check for no supported/specified locales in the portlet descriptor.
        This means that PortletConfig.getSupportedLocales() should in that case return an empty Enumeration.
        As Jetspeed maps and stores the supported locales and the (possibly) provided predefined portlet "PortletInfo" elements from a resource bundle in its Language OM, we need to keep track if a Language is created for such a supported-locale definition by or for the Portlet descriptor.

        Most specifically, the "default" (English) Language is always created and on the fly by Jetspeed (and should not be allowed to be removed!)
        using either the inline PortletInfo definition in the portlet descriptor or, if a ResourceBundle is provided, taking overrides from its English ResourceBundle.
        If however there is no <supported-locale>en</supported-locale> defined, this "default" Language may not be used to represent the formally supported locales.

        This will be implemented by adding a supportedLocale boolean on Language and only set to true for those locales as specified by <supported-locale/> definitions in the portlet descriptor.
        Ate Douma made changes -
        Comment [ Special note: the j2-admin PAM portlet needs to provide restricted editing for this "default" or inline Language entry: its Locale is required to remain empty (thus readonly) and neither is it allowed to delete this entry.
        Probably best is to provide separate editing fields for this "default" Language and filter it out from the list of otherwise editable Languages. ]
        Ate Douma made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Ate Douma made changes -
        Status Resolved [ 5 ] Closed [ 6 ]
        Transition Time In Source Status Execution Times Last Executer Last Execution Date
        Open Open Resolved Resolved
        10h 36m 1 Ate Douma 30/Mar/09 10:01
        Resolved Resolved Closed Closed
        918d 12h 7m 1 Ate Douma 04/Oct/11 22:08

          People

          • Assignee:
            Ate Douma
            Reporter:
            Ate Douma
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development