Best practice for storing user preferences

Joe Krill asked on September 30, 2014 23:05

Is there any recommendations as far as best practices for storing "one-off" user preferences? Specifically, I've created a custom web part which can be slightly customized by the user and I want to retain those customizations for them across sessions. I want this to be persisted for when they visit next, and I don't want to rely on the browser for this stuff, so storing it in a cookie or something similar doesn't get this done.

It seems like overkill to add a new column to the UserSettings class in the Membership module for this. And I've noticed that the UserSettings object has a fairly generic UserPreferences property/column already:

CMS.Membership.MembershipContext.AuthenticatedUser.UserSettings.UserPreferences

But there's virtually no documentation on this -- all I've found is this extremely generic information in the API docs. It would seem that this would be some sort of generic container object for this kind of stuff. But I don't know. It certainly works as far as I've tried it:

var user = CMS.Membership.MembershipContext.AuthenticatedUser;
if(user != null) {
    user.UserSettings.UserPreferences["myRandomDateValue"] = DateTime.Now;
    user.UserSettings.Update();
}

But I don't want to rely on it without having something more solid to go on. Is that what this is intended to be used for? If not, is there a recommended way to handle this that hopefully doesn't involve adding an explicitly defined column or binding somewhere?

user settings user users settings custom code

Recent Answers

Yehuda Lando answered on October 1, 2014 11:51

I think it's intended to be used like that. There is also the UserCustomData field, which many other objects have for storing custom data.

2 votesVote for this answer Mark as a Correct answer

Brenden Kehren answered on October 1, 2014 14:24

I'd agree with Yehuda on both items.

0 votesVote for this answer Mark as a Correct answer

Joe Krill answered on October 1, 2014 20:15

Thanks very much for your help! I do wish this was made a bit more explicit by Kentico, though -- I hate to rely on things that aren't technically documented.

0 votesVote for this answer Mark as a Correct answer

Brenden Kehren answered on October 6, 2014 00:10

There are many things in nearly all software packages that are left open for users to customize as they wish. So specifically stating a user has to "use this field for this task" is not always feasible. Having built software for a specific purpose, I've found sales teams find other ways to sell or utilize the software which then makes some of those specific items irrelevant.

With your license purchase you have unlimited phone and email support from Kentico. If you worked with a Kentico Partner, they should have the knowledge to provide you answers to your questions. As a Kentico Gold Partner, I provide all my clients with whatever they ask for because I know Kentico will help me if I don't know.

0 votesVote for this answer Mark as a Correct answer

Joe Krill answered on October 6, 2014 15:20

I understand that completely. I'm not looking for something specific at all. But it would be helpful to know what is "safely customizable" . Something as simple as "This field can be used as a simple storage mechanism for various end-user settings" or "this field is used internally by Kentico".

My primary concern would be that I would use something like this, and then some future hotfix or update then uses it for a different purpose. And because it wasn't documented one way or the other, I don't really have a reliable way to know what the chances are of that happening.

I posted here first, rather than emailing support, because it seemed that this would be the type of thing that could be useful for others who have the same or a similar issue. And if I were to ask using email, this information would just remain private.

0 votesVote for this answer Mark as a Correct answer

Sandro Jankovic answered on December 1, 2014 14:59

Hi Joe,

It is safe to use this field for user settings as we have no plans to change the functionality in future updates. If a change like this does happen down the line it will be documented and suggestions for dealing with the change will be provided, but it is highly unlikely that this will happen. We are constantly working on improving and expanding our documentation and I will make a note to include this feature as well.

Best Regards,

Sandro

0 votesVote for this answer Mark as a Correct answer