- 追加された行はこの色です。
- 削除された行はこの色です。
RIGHT:[[:t/要素]] [[:t/Wiki]]
機能の実装。ページ/要素を使うためにXというフレームワークがある。
利用者によってページに記述され、ページごと呼び出される。
----
#contents
*ページ/要素 [#p002bc10]
## ページ/要素
- 要素は利用者が入力した情報と、いろいろな機能を併せ持つもの。
- 要素はページに記録された情報をオブジェクト化したもの。
- 要素はいろいろ考えた機能の実装。要素の作り方は自由にしていい。
- 要素をページ上に配置するために使われるのが[[記法]]。
*[[:t/要素]]より [#ua6a9967]
**ページ/要素とは [#x085ebd8]
ページに記述できるプラグイン。記述方法は→[[記法]]。
汎用記法か、管理者が定義した記法で記述すると機能するようになる。
%%記法処理中にどの記法も汎用記法に置き換えられる。%%
→要素はユーザーから渡されたWikiTextを返せなければならない。要素を生成する前に何かに置き換えることはできない。
RIGHT:[[:t/機能]] [[:t/Wiki]] [[:t/汎用記法]]
***[[:i/ページとは]] [#y7f86567]
ページ/要素かデータベーステーブルにあたる。
***[[ページ/要素/API]] [#v9a941b9]
要素（機能の実装）がAPIを提供してもいい。制限しないだけ。サポートもしない。自由。
RIGHT:[[:t/API]] [[:t/要素]]
**ページ/要素ができること／しなくてもいいこと [#sdf5bce0]
***[[:i/リクエスト内のパラメーターと汎用記法のパラメーターは同じ]] [#r2d562d2]
呼び出され方を区別しなくていい。
データコンテキストの区別はデータコンテキスト名別のTo…メソッドでできるし。
***[[:i/クエリーにどう反応するか]] [#v2ea51d4]
要素の協調でリダイレクトをどう行なうか？
→リダイレクトは要素ではなくユースケースの役目。問題なし。
要素がリダイレクトを指示するなら他の要素の出力を抑えなければならない。協調しないということなので、不可。リダイレクトをするユースケースを呼び出すボタンを用意して、利用者に押してもらう（協調しないユースケースを呼んでもらう）ような方法なら可。
RIGHT:[[:t/要素]] [[:t/UI]] [[:t/実装]]
***要素の展開タイミング [#s5e07f71]
ページ特有の解析処理（利用者登録など）の前か後かは要素の実装次第で決まるように。
ページ特有の処理の前に展開すれば展開後のテキストも解析されることになる。
%%includeのように他のページを取り込む要素を使えば、任意のページを利用者登録ページに取り込んで一括登録できる。その代わり取り込まれるページも管理者権限でしか編集できないようにしなければならない。など利点と欠点がある。%%
要素の出力はそれ以上処理しないので、自動リンクや埋め込みの展開などは要素側で行なう。
記法（要素呼び出し）のパラメーター部分に記法があっても処理するのは要素。それ以外はページが処理。
これで[[ページ/編集/HTML書き込み]]の埋め込みと展開を邪魔しないようにできる。
要素の出力はWikiTextではなくHTML。そのままレスポンスの一部になる。
要素の処理のうち共通部分に埋め込みの展開を置いてもいい。
メタシンボルの埋め込みで動的なパラメーター指定ができるが、これを全要素の仕様にしたいので。
----
入力:WikiText →
|ページ|記法の解釈、オブジェクト化。|
|要素|埋め込み展開|
|~|要素自身の処理と自動リンク（要素次第）|
→ 出力:HTML
RIGHT:[[:t/要素]] [[:t/実装]] [[:t/Wiki]]
***[[ページ/要素/UI]] [#k5398aa0]
拡張可能な要素のUIとは。
†[[UIを使うページ要素]]
要素を呼び出すためのUIは記法。エディターと組み合わせて使う一大機能。
†[[記法]]
†[[汎用記法]]
RIGHT:[[:t/UI]] [[:t/要素]] [[:t/開発]] [[:t/記法]]
***[[:i/簡単なAPI]] [#c65a0538]
簡単不自由なAPIと、面倒自由なAPIの両方を用意。
引数の違い。
例えばページ/要素のコンストラクターを2種類用意。どちらかを定義すれば要素として使えるように。
RIGHT:[[:t/API]] [[:t/開発]] [[:t/要素]]
***[[ページ/要素/API#vcafaa10]] [#q1e224ba]
テストコード。
インストール時に動くか確認。
管理者が改造したときにも使える。運用しやすくなる。
UIは…ページ/要素クラス別のページ（複数のバージョンがある場合は下位ページでも作って）にあるテスト実行ボタンで。
テストが複数定義されていればその数だけボタンを表示するように。リフレクション→UIに反映。
テスト環境をどう作るのか。テスト用コードだけでできなければならない。
RIGHT:[[:t/開発]] [[:t/API]] [[:t/管理]]
***[[:i/エラーメッセージにクラス名]] [#y3fb5f7e]
エラーメッセージの書き方。
競合も矛盾もない。
エラーメッセージはエラー対処のためのUIでもある。
検索がサイト間のハブサイト、エラーメッセージはその検索へユーザーを誘導する。
RIGHT:[[:t/管理]] [[:t/開発]] [[:t/実装]]
***名前付きパラメーター [#nbd6ac71]
無名引数を使うならリファレンスやコード補完があるときだけ。
汎用記法では名前付きパラメーターにする。
RIGHT:[[:t/記法]] [[:t/Wiki]]
***要素にUsage [#k51eb310]
要素に書かれているテキストをヘルプに出す。
マウスポイント時のバルーンやtipsにも出せるようなシンプルな体裁で。
というか、組み込み済みの記法で。
Usage()→ビルトインの記法と汎用記法
→ [[:i/UIを使うページ要素#g6a26065,usage]]
RIGHT:[[:t/UI]] [[:t/機能]] [[:t/Wiki]]
**ほか [#wdbd0966]
***時刻だけ書いたら同じページに書かれている日付を加味 [#c431fe67]
検索時の同一性評価で、足りない情報を同じページから取得。
時刻だけの表現には同じページにある日付を。同じページに日付だけの表現がないなら日付時刻から日付を流用。
足りないフィールドは同じ（近い）ページから取得。
Wikiなので情報は非定型。補える場合は少ないし重複がある。
→足りない情報を補うための機能ではなく、近い情報を加味する基本的な機能で。
----------
属性の継承とは違う。
要素が独自に使うデータなので、フレームワークは関わらない。
広い期間で有効なデータ領域を用意するだけ。
→数種類。ページ、プロセス、セッション、アプリケーション。要素向け機能。
各要素はそこにパラメーター履歴を残して置けばいい。
----------
フレームワークでは要素の呼び出し順を一定にする。上から順に。
RIGHT:[[:t/記法]] [[:t/要素]] [[:t/Wiki]]
***投稿時展開するものは要らない [#m2d2a19a]
投稿時展開するくらいなら編集時にボタンなどで展開後のテキストを挿入した方がいい。
MediaWikiの~~~~のようなもの。
そういったボタンを使えないクライアントにはただの文字列を提供。編集ページを開いた時点で展開しておく。それをコピペ。量が多くなるのであまり一度に用意できない。
RIGHT:[[:t/記法]] [[:t/Wiki]]
**性質 [#g8639f13]
***インスタンス [#e9d13d0c]
というか、設定を複数用意可能に。
同じ要素でも設定ごとに異なる記法を当てて、使い分けできるように。
要素側で設定ページをパラメーター化すればいい。
記法の記述で、Notationと設定を抱き合わせにすれば実現可能。
フレームワークでやる必要はない。
RIGHT:[[:t/実装]] [[:t/要素]] [[:t/Wiki]]
***複数行パラメーターの書き方 [#j664af5a]
複数行を要素に渡すには、置き換えと埋め込みページが良さそう。
-置き換え
plugin(l1\\l2,p2)
WikiCreole式。
改行文字になる表現を使って。要素には改行文字が渡る。
-埋め込み
plugin({{ページ}})
他のページを指すリファレンスを渡す。ページは埋め込みの仕組みを使って展開されてからパラメーターとして要素へ。
RIGHT:[[:t/記法]] [[:t/Wiki]]
***3態 [#xaf55508]
WikiText→オブジェクト→HTML
…を要素ごとに行う。出力はそのままレスポンスに含める。
記法（設定に依存しない基本的な記法）をHTMLに変換するためのライブラリを用意。
これで他の記法と変換結果を統一。
HTMLのメモ化は要素ごとに。
%%オブジェクトの保存はバージョニングのこと。%%
%%ページの属性次第で保存するかしないかが決まる。%%
%%保存しないのは特殊なページ。%%
RIGHT:[[:t/要素]] [[:t/永続化]] [[:t/Wiki]]
***ページがコンポジション [#tdc9b3bd]
ページは要素のコンポジション。永続化と復帰を単純化。
%%リンクは1つのオブジェクトにしたほうが都合が良い。…が、機能が低下するので却下。永続化と復帰が複雑になる。%%
→リンクはリンク元のオブジェクト。オブジェクト間の関連ではないのでリンク先には影響しない。逆リンクは逆リンクとして別途用意。
RIGHT:[[:t/Wiki]]
***要素は部品 [#e9dcf7f2]
要素は部品であるべき。
組み合わせる余地が要る。
-tag.inc.phpのように固いものや大きなもの、応用の利かないものはまずい。
-ツール化しないように。
ツールはページ+要素で。
アプリケーションはWiki全体で。
RIGHT:[[:t/要素]] [[:t/実装]] [[:t/Wiki]]
***[[:i/要素がページに記述されたとき、Chain of Responsibilityで]] [#y336df0d]
→ [[:i/要素がページに記述されたとき、Chain of Responsibilityで？]]
要素間／ページ間の依存をなくす。それぞれが独立。連携するなら相手に依存することになる。プラグインが守らなければならないルールが無い代わりに、連携をサポートすることも無い。
***その他の要素 [#y407bec0]
-ページ全体
閲覧時展開。内容とページ名
-1ページ内の見出し全て
閲覧時展開。ページ名（省略可）
-1ページ内のレベル1見出し全て
閲覧時展開。Webcat Plusに渡せるような。
RIGHT:[[:t/記法]] [[:t/要素]] [[:t/実装]] [[:t/Wiki]]
***プラグインは記法 [#l8006fb9]
プラグインというクラスは作らない。
記法と同じ扱い。[[X/PageElement]]
記法はネスト可能。
独自データをページに保存可能。ページに残すので履歴付き。
プラグインのアンインストール方法は？''しやすく''
しやすくする以上のことはできない。
PageElementをオブジェクトとして永続化する場合、Pageと一緒にということになる。
動的データはPageが持つWikiTextからすべて作成可能。
PageインスタンスはWikiTextから生成したPageElement構造体。
利用者による編集と同じで、ページを更新するときは履歴を作るのが基本。
でも、PageElementの設定（PageElementのコードで定義）で履歴を作らないことが指示されていれば作らない。
RIGHT:[[:t/記法]] [[:t/プラグイン]] [[:t/実装]] [[:t/Wiki]]
***展開は閲覧時 [#vcaee641]
閲覧時展開。
置き換えない。
HTMLに置き換えてもHTMLエスケープしてしまうので。
ずっと動的に展開。
メタシンボルの類も同じ。他の要素と同様に。
RIGHT:[[:t/記法]] [[:t/実装]] [[:t/Wiki]]
***Chain of Responsibility [#sac8e7d3]
ユーザーが直接呼び出すタイプの要素はChain of Responsibility。
クエリーは要素名とページ名を指定するのでなく、やって欲しいことを。
同じクエリーでも導入されている要素次第で別の処理が行われるかも知れないし、いくつの要素が反応するかも変わってくる。管理次第。
これはWikiが正しく構築されていれば正しく動くし、間違っていれば結果（ページ出力）に表れるので分かりやすい。対応付けを厳格にすると設定が難しくなるし、後から付け足した設定で以前の設定が無効になることもあるので、それを回避するのが狙い。
フレームワークもChain of Responsibility。
RIGHT:[[:t/要素]] [[:t/実装]] [[:t/Wiki]]
***ページ─要素はコンポジションに [#g11dba69]
Notationオブジェクトは書くたびにインスタンス生成。
リファレンスだけを増やしたいときはPukiWikiでの「include機能」のような特別な方法で。
RIGHT:[[:t/要素]] [[:t/実装]] [[:t/Wiki]]
***クラス継承 [#q354093f]
組み込み済みクラスを継承して要素化。上位クラスと同じ扱いをされるように。下位クラスを知っているクラスからはそのクラスとして扱われるように。
記法類は要素に継承されていいように。
RIGHT:[[:t/要素]] [[:t/実装]] [[:t/Wiki]]
***使い方2種類 [#ja39efd9]
-ページに記述→要素はHTML生成。
-別要素のパラメーターとして記述→別要素からパラメーターを渡すよう要求される→純粋なデータを生成。
ls→ページ名リストを生成。パラメーターとしてはページセットを生成。
書かれた場所…コンテキスト、文脈。文脈次第で型が変わる。意味は変わらない。使いにくくなるので。
RIGHT:[[:t/記法]] [[:t/UI]] [[:t/Wiki]]
***使い方が2種類あっても実体は同じ [#dd4bffa7]
どちらの使われ方でも記法を返す。それが何に埋め込まれるかはフレームワークが決める。
実装はインターフェイス。
イベントハンドラーのようなもの。
ユーザーからのリクエストで呼ばれるだけの要素でも、ページに書かれたときに自身を呼ぶリンクやボタンを生成するようにすれば使いやすくなる。
RIGHT:[[:t/記法]] [[:t/UI]] [[:t/Wiki]]
***リクエストからの直接呼び出しでもネスト可能に [#y63849e2]
PukiWikiのコマンド型要素のように、ページに書かずに使う場合でもネスト可能に。一時的なページを生成してもいい。
またはデリゲート可能に。最後に呼ぶもの以外はデータコンテキスト。
RIGHT:[[:t/要素]] [[:t/実装]] [[:t/Wiki]]
***MVC [#k8e5528f]
:M|いくつでも。（複数クラス、複数ファイル）
名前などすべて利用者の任意。
:V|いくつでも。
Mと同じように任意。
:C|要素のエントリーポイント。
同要素のMとVを呼び出す。
名前に規則あり。フレームワークから呼び出しやすくするため。
C（前）とC（後）がある。
|フレームワーク|CENTER:→|1.C（前）|CENTER:→|2.M、Vなど|||
|~|>|>||3.子のC（前）|CENTER:→|4.子のM、子のVなど|
|~|>|>||5.子のC（後）|CENTER:→|6.子のM、子のVなど|
|~|CENTER:→|7.C（後）|CENTER:→|8.M、Vなど|||
深さ優先の呼び出し。
RIGHT:[[:t/要素]] [[:t/実装]] [[:t/Wiki]]
**利用例 [#w93325f6]
***URLクエリーは一時的ページ [#p4142095]
URLクエリーもページと
同じように解析、展開。
使い方も実装も統一できる。
RIGHT:[[:t/要素]] [[:t/実装]] [[:t/URI]] [[:t/Wiki]]
**要素を実行時に取得 [#u65f404c]
要素をUIからのシステム呼び出し時に取得したい。
管理者が要素のURIを入力して。
システムが要素を取得、インストール。
アンインストールは…
要素と同じ著作者のファイルだけ消す。
他の要素でも使うようなものは除く。
参照数をカウントしておけば（また、カウントし直しが随時できれば）より正確にアンインストールできる。
RIGHT:[[:t/要素]] [[:t/実装]] [[:t/UI]] [[:t/プラグイン]] [[:t/Wiki]]
***URIで示された場所に置くもの [#le39d6d5]
-プログラム他、インストールするもの
-必要なもの（他者が作ったもの）
-インストールの仕方、形式的な書式
URI集を特定のサイトで作り、RSS化。
各Wikiで定期的に取得。
管理者用の機能。
RIGHT:[[:t/要素]] [[:t/実装]] [[:t/URI]] [[:t/Wiki]]
**要素/ [#m6f2d009]
#ls
