diff options
| -rw-r--r-- | doc/todo/online_configuration.mdwn | 59 |
1 files changed, 12 insertions, 47 deletions
diff --git a/doc/todo/online_configuration.mdwn b/doc/todo/online_configuration.mdwn index 94c4c66f8..2393b75af 100644 --- a/doc/todo/online_configuration.mdwn +++ b/doc/todo/online_configuration.mdwn @@ -11,56 +11,21 @@ Currently admin prefs are per-admin, and are stored in the userdb. That seems like a bad choice in the context of this idea. Instead, admin setup should be configured on a separate page than the regular user prefs page, and should be shared amoung all admins, and the ideal storage would be -another ikiwiki setup file, which could be loaded in, and written back out. +a ikiwiki setup file, which could be loaded in, and written back out. -If `ikiwiki-makerepo` were extended a little bit to generate the stub setup -file that's enough to get `ikiwiki.cgi` working, and that sets values for -all the dangerous options, leaving only safe ones 'undef', then users could -set up ikiwiki using it, and configure the rest with the web interface, -without ever needing to edit a setup file. +The underlying work has been done to privide metadata about all options via +getsetup hooks, so it's just a matter of writing a web interface plugin. -The setup page could `require` every available plugin, and then call a -`getsetup` function, which would look something like: +The plugin could have these config options: - sub getsetup () { - eval q{use Some::Thing}; - die $@ if $@; + # list of options to include in web setup (safe = all things with safe = 1) + websetup_include => [qw{safe}], + # list of options to exclude from web setup + websetup_exclude => [qw{option_baz}], - return option_foo => { - safe => 1, - rebuild => 1, - type => "boolean", - default => 0, - description => gettext("Enable foo."), - }, - option_bar => { - safe => 0, - rebuild => 0, - type => "password", - default => "", - description => gettext("Password for bar."), - }; - } - -The types would be: boolean, string, password, filename, other. -This would be the type of the leaf fields; if a value in `%config` is an -array or hash, the type specifies the type of values that go into it. - -From this info, a form can be built, that has core setup values at the -top, followed by each plugin whose `getsetup` succeeded, with a check box -to enable/disable that plugin, and all of its setup options listed after -it. - -The main setup file could control what options are read from the -online setup file: - - online_setup_include => 'safe', # all things with safe = 1 - online_setup_exclude => [qw{option_baz}], - -Note that posting the setup form would sometimes need to cause a rebuild -of the whole wiki. This could be done with output streamed to the admin in -the web browser. The `rebuild` fields would be set to 1 for values that -require a wiki rebuild when changed, and to 0 for values that only need the -wrappers to be refreshed. +Leaning toward just making it write out to the same setup file, rather than +writing to a subsidiary setup file. However, this would mean that any +comments in the file would be lost, and that it couldn't be used if the +setup file had weird stuff (perl code, etc). [[!tag wishlist]] |