- バックアップ一覧
- 差分 を表示
- 現在との差分 を表示
- 現在との差分 - Visual を表示
- ソース を表示
- 管理 へ行く。
- 1 (2007-12-30 (日) 02:57:50)
- 2 (2011-12-14 (水) 01:29:17)
- 3 (2012-09-20 (木) 08:06:03)
- 4 (2013-02-16 (土) 06:06:54)
- 5 (2013-03-20 (水) 22:41:16)
- 6 (2013-04-04 (木) 05:12:40)
- 7 (2013-04-10 (水) 15:33:44)
- 8 (2013-04-10 (水) 18:57:53)
- 9 (2013-04-10 (水) 21:19:00)
- 10 (2014-01-23 (木) 04:08:30)
- 11 (2014-02-24 (月) 06:14:54)
- 12 (2014-03-01 (土) 17:11:56)
- 13 (2014-03-21 (金) 13:56:33)
管理者向けの機能。
あとでなおす † 
ページで設定、ページでWikiシステム構築。
新しいWikiを作るときに工夫と機能次第で新機能を作れるような。
拡張の仕組み †
- 機能ファイルを置く
- ページ内で呼び出しコマンドを書く
インスタンスの定義をページでできる。
利用者の権限によって編集できるところ/できないところがある。
（ページ単位）
「ページの更新間隔」を0より大きく設定すると、設定時間内では1回までしか更新されなくなる。
キャッシュ、メモが使われるようなもの。
ページはネストできるので下位に1つでも動的部分があれば動的生成になる。
設定類はページに書く †
プラグインの設定もページに。データアクセスでどこからでもどのページでも参照。
WikiTextから設定値を読み込むようなライブラリが無いと、プラグインから設定ページを利用する意味が無い。
ページに設定を書けば、設定もバージョニングできる。
プラグインの導入も特定のページに書くことで。
表から設定値取得 †
テーブル記法から設定値を得るのなら、テーブルにAPIとしての機能を持たせる。
検索/フィルタリングよりも。
設定値取得…
問い合わせの形式は？
→値名と何かオプション属性で。
テーブル記法はプラグイン。でも差し替え可能なだけにして、wikiに必要なものとする。
カスタマイズを戻すには †
ページの初期値は公式サイトにでも貼っておけば十分。
ページ/履歴もあるし。
設定値は文字列だけ †
設定では純粋な数値型を使わない。
どれもN/Aと設定なし(Null)と∞（無限大、Infinity）が使えるように。
- ∞（Negtive Infinity）も？
0や-1は、1や2と同じ型になること。0や-1を「設定なし」や「使用しない」といった意味にしないこと。
全てページに書くので文字列になる。それを数値その他として解釈。
無指定→デフォルト値。ハードコーディングだったり、デフォルト値の設定があったり。デフォルト値設定も無ければハードコーディング。
管理用にページ/要素を処理しないモードを。 †
トリガー
- URLクエリーからのコマンド
奥にしまう †
アクセスされていないページと付帯データは別サーバーに。
毎日ダンプ †
毎日ダンプファイル作成、Wikiに追加。
特定ページにリンクを作成。
いつでも作成できる最新版ダンプファイルは要パスワード。
（処理が重そうなので。重くならなければパスワード不要）
毎日というのが更新間隔に合わないかも。
それなら前回ダンプファイル作成から数えて最初の更新後、6時間経ったらダンプファイル作成などに。
ダンプファイルの保存先がDropboxと同期するページだとなおいい。
定期的にDropboxにダンプが作られて、それがDropboxからWebに公開される。
自動的に削除してもDropbox側にバックアップが残るし問題に対処できる期間が延びて安心。