master
Joey Hess 2008-07-27 16:31:22 -04:00
parent 9607452346
commit f484deabbc
1 changed files with 12 additions and 47 deletions

View File

@ -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 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 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 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 The underlying work has been done to privide metadata about all options via
file that's enough to get `ikiwiki.cgi` working, and that sets values for getsetup hooks, so it's just a matter of writing a web interface plugin.
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 setup page could `require` every available plugin, and then call a The plugin could have these config options:
`getsetup` function, which would look something like:
sub getsetup () { # list of options to include in web setup (safe = all things with safe = 1)
eval q{use Some::Thing}; websetup_include => [qw{safe}],
die $@ if $@; # list of options to exclude from web setup
websetup_exclude => [qw{option_baz}],
return option_foo => { Leaning toward just making it write out to the same setup file, rather than
safe => 1, writing to a subsidiary setup file. However, this would mean that any
rebuild => 1, comments in the file would be lost, and that it couldn't be used if the
type => "boolean", setup file had weird stuff (perl code, etc).
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.
[[!tag wishlist]] [[!tag wishlist]]