[jira] [Updated] (ISIS-802) Remove the ProfileStore component (in future, can raise a ProfileService as and when we identify a concrete reqt).
[ https://issues.apache.org/jira/browse/ISIS-802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Haywood updated ISIS-802: - Fix Version/s: (was: core-2.0.0) core-1.7.0 > Remove the ProfileStore component (in future, can raise a ProfileService as > and when we identify a concrete reqt). > -- > > Key: ISIS-802 > URL: https://issues.apache.org/jira/browse/ISIS-802 > Project: Isis > Issue Type: New Feature > Components: Core >Affects Versions: core-1.5.0 >Reporter: Dan Haywood >Assignee: Dan Haywood > Fix For: core-1.7.0 > > > As a write-up from IsisCon2014, Dan said: > > > > > > 6. Profile Store > > > > > > The profile store is a component of the framework that is not supported by > > > either the Wicket or Restful Objects viewers, but whose functionality is > > > broadly superceded by the UserSettingsService. > To which Kevin replied: > > When the UI becomes user-configurable (re-arranged, pallete change, > > etc) this should be demo'd. > > > > Where are user preferences (e.g. UI language, timezone, etc) currently > > stored? Do we have demo code? > And so Dan said: > There are two points here... where to store preferences, and how/what within > Isis should consume them. > For the former, we have the UserSettingsService (part of applib); in the JDO > applib there is an entity-based implementation, > For the latter, nothing in Isis particularly consumes these. For timezones > we tend to use LocalDate which gets around the issue to some extent; but you > are right that the UserProfile class (in the profilestore) does hold this > Localization class; that needs surfacing out as a first-class concept somehow. > So perhaps ProfileStore should live on, but not as a component, but instead > as a separate service. > In all, I see three related subdomains: > [Shiro security] -> [Isis user profile (i18n etc) service] -> [Isis user > settings service] > I'll raise a ticket to capture this thinking so far. > ~ > ... which is what this ticket is... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ISIS-802) Remove the ProfileStore component (in future, can raise a ProfileService as and when we identify a concrete reqt).
[ https://issues.apache.org/jira/browse/ISIS-802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Haywood updated ISIS-802: - Fix Version/s: (was: core-1.7.0) core-2.0.0 > Remove the ProfileStore component (in future, can raise a ProfileService as > and when we identify a concrete reqt). > -- > > Key: ISIS-802 > URL: https://issues.apache.org/jira/browse/ISIS-802 > Project: Isis > Issue Type: New Feature > Components: Core >Affects Versions: core-1.5.0 >Reporter: Dan Haywood >Assignee: Dan Haywood > Fix For: core-2.0.0 > > > As a write-up from IsisCon2014, Dan said: > > > > > > 6. Profile Store > > > > > > The profile store is a component of the framework that is not supported by > > > either the Wicket or Restful Objects viewers, but whose functionality is > > > broadly superceded by the UserSettingsService. > To which Kevin replied: > > When the UI becomes user-configurable (re-arranged, pallete change, > > etc) this should be demo'd. > > > > Where are user preferences (e.g. UI language, timezone, etc) currently > > stored? Do we have demo code? > And so Dan said: > There are two points here... where to store preferences, and how/what within > Isis should consume them. > For the former, we have the UserSettingsService (part of applib); in the JDO > applib there is an entity-based implementation, > For the latter, nothing in Isis particularly consumes these. For timezones > we tend to use LocalDate which gets around the issue to some extent; but you > are right that the UserProfile class (in the profilestore) does hold this > Localization class; that needs surfacing out as a first-class concept somehow. > So perhaps ProfileStore should live on, but not as a component, but instead > as a separate service. > In all, I see three related subdomains: > [Shiro security] -> [Isis user profile (i18n etc) service] -> [Isis user > settings service] > I'll raise a ticket to capture this thinking so far. > ~ > ... which is what this ticket is... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ISIS-802) Remove the ProfileStore component (in future, can raise a ProfileService as and when we identify a concrete reqt).
[ https://issues.apache.org/jira/browse/ISIS-802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeroen van der Wal updated ISIS-802: Summary: Remove the ProfileStore component (in future, can raise a ProfileService as and when we identify a concrete reqt). (was: Profile Service as a replacement for the ProfileStore component) > Remove the ProfileStore component (in future, can raise a ProfileService as > and when we identify a concrete reqt). > -- > > Key: ISIS-802 > URL: https://issues.apache.org/jira/browse/ISIS-802 > Project: Isis > Issue Type: New Feature > Components: Core >Affects Versions: core-1.5.0 >Reporter: Dan Haywood >Assignee: Dan Haywood > Fix For: core-1.7.0 > > > As a write-up from IsisCon2014, Dan said: > > > > > > 6. Profile Store > > > > > > The profile store is a component of the framework that is not supported by > > > either the Wicket or Restful Objects viewers, but whose functionality is > > > broadly superceded by the UserSettingsService. > To which Kevin replied: > > When the UI becomes user-configurable (re-arranged, pallete change, > > etc) this should be demo'd. > > > > Where are user preferences (e.g. UI language, timezone, etc) currently > > stored? Do we have demo code? > And so Dan said: > There are two points here... where to store preferences, and how/what within > Isis should consume them. > For the former, we have the UserSettingsService (part of applib); in the JDO > applib there is an entity-based implementation, > For the latter, nothing in Isis particularly consumes these. For timezones > we tend to use LocalDate which gets around the issue to some extent; but you > are right that the UserProfile class (in the profilestore) does hold this > Localization class; that needs surfacing out as a first-class concept somehow. > So perhaps ProfileStore should live on, but not as a component, but instead > as a separate service. > In all, I see three related subdomains: > [Shiro security] -> [Isis user profile (i18n etc) service] -> [Isis user > settings service] > I'll raise a ticket to capture this thinking so far. > ~ > ... which is what this ticket is... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
