aboutsummaryrefslogtreecommitdiff
path: root/doc/todo/online_configuration.mdwn
diff options
context:
space:
mode:
authorJoey Hess <joey@kodama.kitenet.net>2008-07-27 16:31:22 -0400
committerJoey Hess <joey@kodama.kitenet.net>2008-07-27 16:31:22 -0400
commitf484deabbcee65721b497fc1d2fb572b4df47988 (patch)
tree10e983ca54b3c6b6049213ab768a1f2a1cd6d81c /doc/todo/online_configuration.mdwn
parent96074523461eb0ad5a419fbcedfe4089ab7a7713 (diff)
downloadikiwiki-f484deabbcee65721b497fc1d2fb572b4df47988.tar
ikiwiki-f484deabbcee65721b497fc1d2fb572b4df47988.tar.gz
update
Diffstat (limited to 'doc/todo/online_configuration.mdwn')
-rw-r--r--doc/todo/online_configuration.mdwn59
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]]