Forum OpenACS Q&A: Do You Have a Preference?

Collapse
Posted by Raad Al-Rawi on
Actually, do your users have preferences, and are they kept anywhere?
I'm really talking about the user-preferences package, which I came across during work on calendar & notifications.
I was looking for a way to store things like the number of days displayed in the list view, the user's default view etc. and noticed user-prefs.

It only works on Oracle, didn't work properly and seems a bit abandoned; which is a shame as I think it could be very useful in maintaining the continuity of a user's experience.
I fixed a couple of obvious problems so that it works, but I think it probably needs a re-think in some areas, as well as a Postgress port.

What do people think? Is it worth some effort, or are there other mechanisms for storing user settings for packages that are better?

<Raad>
Collapse
Posted by Randy O'Meara on
Raad,

I asked (kinda) this same question recently (https://openacs.org/forums/message-view?message_id=120936) hoping to generate a discussion of "whose 'extended user' package is the best?"

It is probably worth some effort. My feeling is that there are some packages out there somewhere.  It appears that the OpenACS site is need of a package like this also (see Talli's comment in referenced thread). I think a flexible user-prefs package might be a quite large effort.

How is the user-prefs package you mention implemented? By extending the user-related tables or maybe it uses the attributes subsystem?

I am thinking that I'll probably just incorporate user prefs in my own application by extending the user table in the application's data model.

Randy

Collapse
Posted by Raad Al-Rawi on
Hi Randy

I think we may have our wires crossed, so to speak :)
The user-prefs package is intended (AFAIK) to store personal preferences for other packages.

E.g. The calendar package displays a "day" view by default and there is no way for a user to individually set that to "month".

By creating a "calendar-default-display" preference associated with the calendar package, and extending the calendar package (& OACS UI) slightly to use this preference, any user could set their preference for the default calendar view.

What you were referring to is extending users' properties/attributes - not quite the same thing, but something I agree would be useful as well.

<Raad>

Collapse
Posted by Raad Al-Rawi on
Having said that, there is nothing to stop you from using the user-prefs package for creating extended user attributes (e.g. ICQ#, pager # etc.)

User-prefs basically allows you to create a setting (or preference), then you can create an individual entry for any user for that setting (i.e. the value of that setting for that user).
Because you can also associate the setting with a package, you could use that to dynamically generate appropriate "Package Settings" pages to allow users/admins to change individual/default settings. You could use the "user-prefs" package itself to store extended user attributes.

I'm wondering if nobody has needed this sort of thing, as I think it has great potential for making OACS/dotLRN more friendly and consistent, from a user's perspective.

In dotLRN, there are a few existing things that would benefit:

  - calendar: default view
  - calendar: list view: number of days to display
  - filestore: "new" files period

and I can think of a few new ones:

  - calendar: event notification period
  - news: days to show news for
  - forums: number of threads per page

of course, such things would mean changes to packages; but I see this as a natural step in OACS/dotLRN evolution.

<Raad>

Collapse
Posted by Randy O'Meara on
Even though our initial wires were crossed, it sounds like the user-preferences package might do what I want, and it might also do what Talli wants for the oacs site.

I was thinking that acs_attributes would be the way to go until I read Ben's comment (in the contrib/packages/user-preferences package) about the braindead[ness] of acs_attributes. I'm wondering if acs_attributes is still in bad shape. Can anyone provide guidance or examples of acs_attributes usage?

Raad: Can you commit your fixes to the oacs contrib repository? Or, place them in filestorage at /storage so I can have a look?

Thanks,

Randy

Collapse
Posted by Raad Al-Rawi on
I've uploaded a tarball of my fixed version of this into /storage - if anyone wants to update it via CVS, the version will need incrementing.

Although it works, I feel there are still some issues with the package:

  - is the data structure valid against current OpenACS?
  - does it do everything it needs to do?
  - does it have sufficient developer support in terms of utility procs etc?
  - if it is used in other packages, what about dependencies?

Just a few thoughts - I'll come back to this again.

<Raad>