Preferences - Best Practices?

[tinynumbers]

I've been reading bits and pieces (both here on FMForums and elsewhere on the web) about how to best handle the notions of "preferences" in a FM solution. The way I'm thinking about it, there are two different uses of the word "preferences" within a solution:

1. solution-wide preferences: User-modifiable preferences which are carried over to all users (in a multi-user environment). If any user changes one of these preference values, all users should immediately see this change.

2. user preferences: User-modifiable preferences which are specific to a single user (in a multi-user environment). A user can change one of their user preferences and it should persist for that one user over multiple sessions, but should not be seen by other users, who will have their own private copy of the user preference values.

I haven't seen any consistent description of how to implement these two different types of preferences in a FM solution. My inclination is that solution-wide preferences would have to be implemented in a preferences table with one single record, with a TO of this preferences table joined via Cartesian product to any other TO which needs to utilize these preference values. Globals wouldn't work since they're per-user... right? And user-specific preferences would be implemented as a separate preferences table with a single record per user, related to some other value which is set at startup to the user ID or name.

Is this on the right track?

I would love to hear (or see examples of) how people generally implement this - I assume it's a situation that comes up in almost every substantial solution created.

Any thoughts?

[Vaughan]

I think you are on the right track.

Solution-wide preferences would lie in a single-record "preferences" table. The values stored in here would be used for all users. To make the values stored in the prefs table accessible to all tables (and avoid a multitude of X-linked TOs) each value has a calculated field set to global storage. Note that this won't necessarily refresh the moment the value is changed, it may require the solution to be quit and reopened.

Per-user preferences need to be stored in a table that contains one record per user. This is easy enough to set up and automate: you first need to set up "default" user preferences. Each time a user logs into the solution their record is found and the values used. If it does not exist then create a new record with the default values.

To be honest I've never set up a solution with per-user preferences. Most that do have per-user prefs tend to want to use them to control access and security, which is not the correct way to do it (the end result is always weak).

As I think more about it, I'd have the Users table linked to the Preferences table, so all the "preferences" are accessed from one central point.

[Joe King]

I use pre-user preferences and solution preferences on almost every solution I have created in the past four years. I put all the 'solution prefs' in a table called 'Common Resources'. I place the User Prefs in the User Table.

There are two underlying principles that I think you should think of in this context. Don't think of 'prefenrences' as much as you are thinking of 'data'. The rules of Normalization will serve you well.

I would also warn you to avoid globals for preferences- not only are they not defined in the principles of normalization, but they can also work differently from dev machine to hosted solution, not to mention it takes a bunch of scripting to handle to global prefs correctly.

Hope this helps...

Joe