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:
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? Parmeters are such a horrid UI.
I was talking to a person from the MIT media lab who works on a site for kids there. Thier 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 diffent on thier site then My Space's. Nevertheless, this is an idea we might want to use, making out stuff compatiable 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):