[CAUSEWAY-802] Remove the ProfileStore component (in future, can raise a ProfileService as and when we identify a concrete reqt).

• Type: New Feature
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: core-1.5.0
• Fix Version/s: core-1.7.0
• Component/s: Core
• Assignee: Unassigned
• Reporter: Daniel Keir Haywood
• Created: 12/Jun/14 11:18
• Updated: 21/Oct/14 05:55
• Resolved: 04/Oct/14 12:32

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

Issue Links

• is duplicated by: CAUSEWAY-725 For 2.0.0, should we remove the ProfileStore?