管理者向けの機能。
ページで設定、ページでWikiシステム構築。
工夫とプラグイン要素次第で新機能を作れるようなのが理想。
あとでなおす †
ページで設定、ページでWikiシステム構築。
新しいWikiを作るときに工夫と機能次第で新機能を作れるような。
拡張の仕組み †
- 機能ファイルを置く
- ページ内で呼び出しコマンドを書く
インスタンスの定義をページでできる。
利用者の権限によって編集できるところ/できないところがある。
(ページ単位)
ページはネストできるので下位に1つでも動的部分があれば動的生成になる。
管理 †
設定類はページに書く †
プラグインの設定もページに。データアクセスでどこからでもどのページでも参照。
WikiTextから設定値を読み込むようなライブラリが無いと、プラグインから設定ページを利用する意味が無い。
ページに設定を書けば、設定もバージョニングできる。
プラグインの導入も特定のページに書くことで。
表から設定値取得 †
テーブル記法から設定値を得るのなら、テーブルにAPIとしての機能を持たせる。
検索/フィルタリングよりも。
:t/管理より †
設定値取得…
問い合わせの形式は?
→値名と何かオプション属性で。
管理 †
テーブル記法はプラグイン。でも差し替え可能なだけにして、wikiに必要なものとする。
カスタマイズを戻すには †
ページの初期値は公式サイトにでも貼っておけば十分。
ページ/履歴もあるし。
管理/ †
設定値は文字列だけ †
設定では純粋な数値型を使わない。
どれもN/Aと設定なし(Null)と∞(無限大、Infinity)が使えるように。
- ∞(Negtive Infinity)も?
0や-1は、1や2と同じ型になること。0や-1を「設定なし」や「使用しない」といった意味にしないこと。
全てページに書くので文字列になる。それを数値その他として解釈。
無指定→デフォルト値。ハードコーディングだったり、デフォルト値の設定があったり。デフォルト値設定も無ければハードコーディング。
管理用にページ/要素を処理しないモードを。 †
トリガー
- URLクエリーからのコマンド
奥にしまう †
アクセスされていないページと付帯データは別サーバーに。
毎日ダンプ †
毎日ダンプファイル作成、Wikiに追加。
特定ページにリンクを作成。
いつでも作成できる最新版ダンプファイルは要パスワード。
(処理が重そうなので。重くならなければパスワード不要)
毎日というのが更新間隔に合わないかも。
それなら前回ダンプファイル作成から数えて最初の更新後、6時間経ったらダンプファイル作成などに。
- -
ダンプファイルの保存先がDropboxと同期するページだとなおいい。
定期的にDropboxにダンプが作られて、それがDropboxからWebに公開される。
自動的に削除してもDropbox側にバックアップが残るし問題に対処できる期間が延びて安心。