portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ate Douma (JIRA)" <jetspeed-...@portals.apache.org>
Subject [jira] Updated: (JS2-944) PortletDefinition Languages needs to provide one instance representing the default inline "PortletInfo elements of the portlet descriptor (without Locale)
Date Mon, 30 Mar 2009 00:44:50 GMT

     [ https://issues.apache.org/jira/browse/JS2-944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Ate Douma updated JS2-944:
--------------------------

    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.

  was:
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.

        Summary: PortletDefinition Languages needs to provide one instance representing the
default inline "PortletInfo elements of the portlet descriptor (without Locale)   (was: 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) 
> -----------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JS2-944
>                 URL: https://issues.apache.org/jira/browse/JS2-944
>             Project: Jetspeed 2
>          Issue Type: Bug
>          Components: Container, Portlet Registry
>    Affects Versions: 2.2
>            Reporter: Ate Douma
>            Assignee: Ate Douma
>             Fix For: 2.2
>
>
> 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.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org


Mime
View raw message