Feature Proposal: Foswiki Settings Wizard

Motivation

There are alot of customisations that are possible, and hand editing three space-star-spaceSet elements is more fragile than we really would like.

Description and Documentation

We can craft a set of edit and view templates, with tabbed UI and detailed help - and even use drop down boxes for constrained values..

Examples

Impact

WhatDoesItAffect:

%WHATDOESITAFFECT%

edit

Implementation

in foswiki 2.0, we could:

1. not ship the SitePreferences
2. set the initial SKIN to configuration, which presents the installer with an edit template for the SitePreferences topic
3. craft the edit template so that we lead the installer, and future admins of the Site, and Webs through the complex array of options that exist.

ideally, we can further coalesce Set and META::PREFERENCES with the DataForms system, so that we can re-use and extend the Structured value / Constraint system, and also add the mixin DataFrom proposal (from lastyear?) to enable the auto-extension of these 'wizard tabs' when plugins are installed.

Added bonus feature: allow the same UI to be used for User settings..

-- Contributors: SvenDowideit - 14 May 2010

Discussion

There are a lot of customisations available.

1. Admin customisations via configure
2. Site level (admin) customisations via site preferences
3. Web ("group leader") customisations via WebPreferences and templates
4. Application customisations, via skin and templates
5. Topic customisations via local preference settings

Which of these do you envisage this wizard magicking? Because arguably, most of the (2) settings would be happier (never mind more efficient) in (1) configure, which would allow you to focus your wizardification in one place.

-- CrawfordCurrie - 17 May 2010

well, I'd say most of (2) should never be moved to configure, as there are more than enough of those (er, all?) that then also get customized on a web level for webs that have different admins&purposes.

I'd argue for the opposite - to move as many cfg's out of configure and unify in site, web and topic preferences - and (of course) to make the results of that customisation fast - as fast as the current configure output.

I've always been a little undecided about where our settings go - having more than one place is always a pain, but it is important to continue to offer per web/applicaion/topic customizations which can be controlled by different groups of admins.

-- SvenDowideit - 17 May 2010

I just reviewed the settings in DefaultPreferences and I have to agree, there isn't much that should move to configure. The thing I have against wizards is that they have to be re-entrant, or they are more of a pain than a benefit, and they always seem to take an awful lot of maintenance.

Several times I've been on the edge of implementing precompilation of DefaultPreferences and SitePreferences (and even WebPreferences) to accelerate the preference loading phase. Just never got round to it (mainly because it requires careful integration with the prefs code, which is a giant tangle of knitting wool speckled with dead kittens).

-- CrawfordCurrie - 18 May 2010

Notes from the author of the referred code:

• It's far easier to integrate with database stores (or to use real precompilation, like storing preferences in a BDB)
• It uses much less memory than the previous implementation
• There is space for improvements and I didn't made some yet cause there is no point in improving something without a way to measure the result

It's true that I'm away from development for a while, then feel free to revert the code if it's easier to maintain and support. I hope to continue working on foswiki development as I have the time available.

@Sven: Sorry for the off-topic comment.

-- GilmarSantosJr - 18 May 2010

Gilmar

What I'd like to think we can achieve with this feature, is to migrate Preferences towards being DataForms - that way we get to reuse the typing and constraints, edit rendering and query infrastructure, and then additionally enable us to use that to build better template topic bits.

The idea should be to have a default structured editing path for settings, as we do for DataForms today, and to allow us to craft wizards via edit templates - and then to simplify the maintainance of those though improvements in the core.

hell, there really is no reason we don't do the same for the rego topic - clearly we need mixins for both DataForm definitions and for edit&view templates.

-- SvenDowideit - 18 May 2010

Changing to Parked proposal. Needs developer to adopt.

-- Main.GeorgeClark - 19 Nov 2015 - 22:38

Commenting is disabled while not logged in