- バックアップ一覧
- 差分 を表示
- 現在との差分 を表示
- 現在との差分 - Visual を表示
- ソース を表示
- :Done/属性の継承法則 へ行く。
- 1 (2013-04-25 (木) 05:00:30)
- 2 (2013-04-25 (木) 05:01:00)
- 3 (2014-02-24 (月) 08:42:27)
- 4 (2014-02-26 (水) 00:38:52)
- 5 (2017-01-03 (火) 03:17:44)
- 6 (2017-01-03 (火) 03:32:07)
- 7 (2017-01-03 (火) 03:45:39)
- 8 (2017-01-03 (火) 04:41:52)
- 9 (2017-01-03 (火) 04:51:08)
- 10 (2017-01-03 (火) 05:07:21)
- 11 (2017-01-03 (火) 06:57:21)
- 12 (2017-01-03 (火) 07:08:35)
- 13 (2017-01-03 (火) 07:58:13)
- 14 (2017-01-03 (火) 08:09:31)
- 15 (2017-01-03 (火) 08:16:55)
- 16 (2017-01-05 (木) 03:02:07)
- 17 (2017-01-05 (木) 05:39:18)
- 18 (2017-01-05 (木) 05:51:08)
- 19 (2018-01-09 (火) 07:32:23)
- 20 (2019-01-16 (水) 19:58:08)
- 21 (2019-01-16 (水) 20:25:42)
- 22 (2019-01-22 (火) 17:50:49)
- 23 (2019-07-09 (火) 03:00:15)
- 24 (2019-10-07 (月) 10:28:22)
- 25 (2019-11-07 (木) 20:58:48)
- 26 (2019-11-07 (木) 21:04:41)
- 27 (2019-11-07 (木) 21:55:34)
- 28 (2019-11-07 (木) 22:27:22)
- 29 (2019-11-08 (金) 05:59:30)
- 30 (2019-11-08 (金) 06:42:12)
- 31 (2019-11-08 (金) 09:26:28)
同階層で競合する属性はマージ/異階層は上書き † 
上位ページはすべて参照しなければならない。属性単位のオーバーライドで、状況によらず最上位に継承すべき属性があり得るので。でもキャッシュを作成しておけば何階層も辿らなくていい。
上位ページは複数存在するので、同じ近さの上位ページはまとめてマージ。
(編集衝突時のページ/版のマージと同じ?共通点は重複せず、相違点だけ追加していく?)
そして遠いほうから順に上書き(オーバーライド)。属性名が上下異階層間で重複していたら、最も近いものだけを使うということになる。最上位ページの属性は常に参照される上、最も上書きされやすい。
何階層あろうが2階層間の処理なので、実装では1階層上を継承する処理を再帰呼び出し。最上位まで処理される。
属性のマージは却下、優先順位を定義 † 
属性名に重複があったらいずれかを優先させなければならない。てもまとめて、複数の値を持つようにする。複数選択可能な列挙型ならともかく、フラグや数値ならマージしようがないので結局優先順位が必要になる。同階層間の優先順位とは…?
型を変えてはいけないので、集合や配列でもない限りひとつ以外を無視することになる。集合や配列ならマージ可能。でも配列では順序が必要なのでやっぱり優先順位は必要。
そもそもマージは継承を適切にできない場合の次善策だったはず。元から必要のあったものではない。
→ 同階層にあるページ間で属性名が重複したら、無効化するエラーにするしかない。マージは却下。エラーはWikiらしくない。
属性/継承は管理者がひとりで設計するので、これでいいはず。
属性ごとにそれを使う処理側で「どんな値を優先するか」を定義する?
大きいほう、長いほう、上位から順に連結(マージ)など。集合化なども可能に。選択肢はフレームワークが用意したものか、処理側で定義したもの(引数2つ受けて一方を返すコード)のいずれか。処理側で定義すれば、どちらか一方ではなくマージ(合成)を適切にすることも可能になる。
属性名が重複したとき、この「どんな値を優先するか」の定義が無ければ属性値参照時にエラー無効化。(設定時はいろいろあるし、ページ名変更でもエラーチェックが必要になるので参照時)
エラー処理が必要。エラーならどうするか?
属性が無かったことにするとなると、既存設定を後から無効化できてしまう。
→ 属性は管理者のものなのでそれでいい。定義が無くても安全になるように(重複時の処理も属性も無いのを基本として)実装しなければならない。
異なる階層間でも独自のオーバーライド処理を書ければ、テンプレートの中に下位のテンプレートを埋め込むことも可能になる。同階層間の場合とは別に定義。
:/属性はオーバーライド時にデコレーションも可能にしたい[?]
継承ルール † 
属性は未定義のものだけ親ページから継承する。先祖に無ければデフォルト値。デフォルト値はWikiの設定にある。
…を与えられるように。
通常のページ/内容は元からこの定義リストになっていることにする。属性名が無いと通常の内容の定義になる。
未定義の属性だけ継承…というのはやめる。継承されるはずの値は全て評価しないと、属性にした要素が呼ばれないことになる。要素はただ呼ばれるだけでも意味があるが、それがなくなると応用が利かなくなってしまう。
→継承は最上位からの上書きで。
属性名を検出、継承ルールを適用するのはフレームワーク/WikiEngineの役目。属性記述に使える要素もフレームワーク次第。記述方法もフレームワークに従う。
継承ルール † 
/1/2/3 (/2/3/1なども同じページを指す)
上記のページは以下のページ(上位ページ)が持つ属性を継承する。
/1/2 (/2/1と同じページ)
/1/3 (/3/1と同じページ)
/2/3 (/3/2と同じページ)
/1
/2
/3
/ (ルートページ)
継承順は上位から下位へ。異階層間は上書きなので下位が有効になる。同階層間は属性の定義によるマージ。1ページ内での重複も属性の定義によるマージ。
属性の型は1つ。継承ルールも1つ。、上書きとマージの仕方も1つ。
同名ページもある † 
継承元には同名ページ(見解、代表ページ)がある。同じ名前で別の属性(権限)を持つので、属性が必ず衝突する。
これを無効化していては、継承が機能しない。どうするか?
→ :Done/同名ページ群から属性を継承するには