You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by "Ate Douma (JIRA)" <je...@portals.apache.org> on 2009/03/30 00:25:50 UTC
[jira] Created: (JS2-944) 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 "supports" 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 "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.
--
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
[jira] Updated: (JS2-944) PortletDefinition Language needs to
indicate if its locale is a supported-locale as defined by or for the
Portlet descriptor
Posted by "Ate Douma (JIRA)" <je...@portals.apache.org>.
[ https://issues.apache.org/jira/browse/JS2-944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ate Douma updated JS2-944:
--------------------------
Comment: was deleted
(was: 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. )
> PortletDefinition Language needs to indicate if its locale is a supported-locale as defined by or for the Portlet descriptor
> ----------------------------------------------------------------------------------------------------------------------------
>
> 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 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.
--
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
[jira] Updated: (JS2-944) PortletDefinition Languages needs to
provide one instance representing the default inline "PortletInfo elements
of the portlet descriptor (without Locale)
Posted by "Ate Douma (JIRA)" <je...@portals.apache.org>.
[ 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
[jira] Resolved: (JS2-944) PortletDefinition Language needs to
indicate if its locale is a supported-locale as defined by or for the
Portlet descriptor
Posted by "Ate Douma (JIRA)" <je...@portals.apache.org>.
[ https://issues.apache.org/jira/browse/JS2-944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ate Douma resolved JS2-944.
---------------------------
Resolution: Fixed
> PortletDefinition Language needs to indicate if its locale is a supported-locale as defined by or for the Portlet descriptor
> ----------------------------------------------------------------------------------------------------------------------------
>
> 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 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.
--
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
[jira] Updated: (JS2-944) PortletDefinition Language needs to
indicate if its locale is a supported-locale as defined by or for the
Portlet descriptor
Posted by "Ate Douma (JIRA)" <je...@portals.apache.org>.
[ 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 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.
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 "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.
Summary: PortletDefinition Language needs to indicate if its locale is a supported-locale as defined by or for the Portlet descriptor (was: 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
> ----------------------------------------------------------------------------------------------------------------------------
>
> 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 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.
--
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
[jira] Commented: (JS2-944) PortletDefinition Languages needs to
provide one instance representing the default inline "supports" elements of
the portlet descriptor (without Locale)
Posted by "Ate Douma (JIRA)" <je...@portals.apache.org>.
[ https://issues.apache.org/jira/browse/JS2-944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12693628#action_12693628 ]
Ate Douma commented on JS2-944:
-------------------------------
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.
> PortletDefinition Languages needs to provide one instance representing the default inline "supports" 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 "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.
--
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