[
https://issues.apache.org/jira/browse/ISIS-802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Haywood updated ISIS-802:
-----------------------------
Description:
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...
was:
>
> 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.
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?
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.
> Profile Service as a replacement for the ProfileStore component
> ---------------------------------------------------------------
>
> 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.2#6252)
