User Parameter Package - RFC

There seems to be a need in OpenACS for user-defined parameters. These might include customizing a menu, personalizing a site style template, or even removing or adding includes and panels.

 Here's an initial brainstorm of possible field types:

• Personalized text - user defined text or titles, such as the title of a personal subsite homepage
• Turn on/off toolbar buttons
• Color picker
• CSS stylesheet
• Turn on/off includes (e.g. Solution Grove homepage)
• Change site theme (e.g selva) - is this possible?

The best part of this is that it is dead easy to add new parameters via the APM.

Please post your comments here.

Ryan Gallimore - Viscous Media

CM: What would the user facing UI for this look  like? Parameters are such a horrid UI.

I was talking to a person from the MIT media lab who works on a site for kids there. Their site allows the kids to use the CSS personalization for My Space. This means that there are all sorts of cool themes for the kids without the site owners having to program them.  T. The problem they have is that some of the themes have very very My Space specific things, like hide the 3rd table in the 4th div, which is of course quite different on their site then My Space's.  Nevertheless, this is an idea we might want to use, making out stuff compatible either My Space or another system with a wide variety of themes so we get a lot of looks for "free"

Daveb: what do you mean by user-editable parameters? Do you mean "preferences"? Is this for administrators or regular users.  

Ryan: by user-editable pages I mean regular users, and yes you could call them preferences, but users would  be editing parameters directly in oacs. As far as UI goes, I think the current UI for parameters would work well - perhaps with more field validation.

Maltes: There exists a user_preferences table and this is where your custom applications should store it's values. Then just write a page with form callback hooks (look at callback::contact::special_attributes::ad_form_values::contract and callback::contact::special_attributes::ad_form_save::contract respectively in /contacts/www/contact-add.tcl) which will allow the packages to extend the form with the variables they allow the user to edit. This way you only need one page e.g. in acs-subsite /pvt/edit_preferences where the user can change all his / her user_preferences, including the ones already stored in this table. Each package would then (for each parameter it wants to have a user setting for):

• Extend user_preferences by adding the column
• Write a form extension callback implementation
• Write a form save callback implementation
• Add the code that deals with the parameter's return somewhere

Obviously it would make sense for the last step to have a cached procedure "user::get_preference -name -user_id". And we should probably enforce a naming convention like "${package_key}_$pref_name" so we are not accidentally running into name conflicts on the table.