ページ/要素のバックアップ(No.59)

Send to your Kindle

機能の実装。ほとんどのプラグインはページ/要素。拡張の要。

ページ/要素を使うためにXというフレームワークがある。
利用者によってページに記述され、ページごと呼び出される。
要素は利用者が入力した情報と、いろいろな機能を併せ持つもの。
- 要素はページに記録された情報をオブジェクト化したもの。
- 要素はいろいろ考えた機能の実装。要素の作り方は自由にしていい。
要素をページ上に配置するために使われるのが記法。
ビルトイン要素は簡易マークアップで。プラグイン要素は汎用記法で。
→ :Done/ページ型／スレッド／データコンテキスト／記法定義まとめ#je7681db
要素はページに記述できるプラグイン。記述方法は→記法。
汎用記法か、管理者が定義した記法で記述すると機能するようになる。
記法処理中にどの記法も汎用記法に置き換えられる。
→ 意味ない。編集時に記法を再現するので置き換える前のテキストは必要。汎用記法に置き換えたとしてもさらにオブジェクトに置き換えなければならないため何のキャッシュにもならない。
→ 解析処理を統一するため。簡易マークアップをプラグイン要素に対応付けられるようになる。

:t/要素より
ページ/要素/

:t/要素より †

URLクエリー †

:/検索式を使う検索 †

利用するユースケースクラスによってはURLクエリーがページと同じ型になる。ページとの違いはデータコンテキストの違いだけ。呼ばれたページに含まれるページ/要素は、URLクエリーからデータを引き出すことになる。

あるユースケースでは、URLクエリー上で一時的なページを作れる。レスポンスにはそのページが載る。複数のページをひとつのレスポンスにまとめたりできる。

いろいろなページ/要素 †

:i/レイアウト要素 †

随時作ればいい。
スタイルを与えるだけのもの。あるいは入口と出口の要素を分けて、出口をテンプレート内に配置。入口はページ本文で後から追加。入口の内容が出口にだけ表示される。

未分類 †

:i/時刻だけ書いたら同じページに書かれている日付を加味 †

その要素自身の機能で。

:i/投稿時展開する記法は要らない †

:i/階層化ページ名がタグなら一覧化しないと[?] †

:/HTMLコンテナー †

:/HTML変換の内部処理 †

:/WikiEngineから機能の呼び出し †

:/データアクセスとは †

:/ブロック要素は段落単位で †

:/プラグインが使えるフック †

:/ページ全体も要素 †

:/ページ属性の型は文字列だけ †

:/機能/API/オブジェクト取得API †

:/機能/API/トリガー2種類 †

:/機能/API/バージョン †

:/機能/APIとは †

:/継承対応要素 †

:/要素からWikiEngineインスタンスを起動可能 †

:/解釈をはさんだ検索 †

:Done/2つ呼ぶ記法 †

:Done/クライアント側にサービス側オブジェクトのProxyを作るには †

:Done/グローバルオブジェクトを書き換える機能[?] †

:Done/セレクターは属性値デコレーションに使えない[?] †

:Done/ページセット取得記法とエレメント取得記法 †

:Done/ページ型／スレッド／データコンテキスト／記法定義をまとめて設計[?] †

:Done/履歴はオブジェクト形式で？ †

:Done/検索はクエリーとページの類似度判定 †

:Done/検索フォーマットは機能を呼ぶか †

:Done/目次に出したいだけの見出しはどう書くか †

:Done/要素がアクティブなWiki／Page／Userを得るには †

:Done/記法の衝突対策 †

:ToDo/タグとは何か[?] †

:i/APIリファレンスは処理系に付属しているツールで生成[?] †

:i/LTSV→テーブル †

:i/ToWikitextはそのまま返す †

:i/Tokenize対象はNotationText †

:i/UIからの呼び出し方法2種 †

:i/UIを使うページ要素 †

:i/UI要素 †

:i/URIは内部型を含むラッパー †

:i/URIを解析して異なるページ要素に渡す仕組み †

:i/URLクエリーは一時的ページ †

:i/class属性を付けるならそれごと記法として実装 †

:i/to…は複数指定 †

:i/「Wiki記法」の削減 †

:i/おとなりページ †

:i/ここからの目次 †

:i/なにかのカウンター †

:i/インライン/ブロック/ページの3スコープ → ページ/ラインの2スコープ †

:i/オブジェクトにUIを持たせる †

:i/クエリーにどう反応するか †

:i/データの保存先指定 †

:i/ハブとして機能する要素 †

:i/ファセットを並べるだけでなく集計もしたい †

:i/ファセット分類 †

:i/ファセット化の対象は専用のメタデータ †

:i/フォーム要素 †

:i/ブロック要素／インライン要素を区別しない †

:i/プラグイン内でプラグインを呼び出すために †

:i/プラグイン要素は記法 †

:i/プレビューの集め方 †

:i/プレースホルダー記法 †

:i/プログラムコードを記述するには †

:i/プロセス起動ごとに呼ばれる要素 †

:i/ページ──要素間はコンポジションに †

:i/ページとは †

:i/ページと他オブジェクトとの関わり合い †

:i/ページと要素は似ている[?] †

:i/ページのイテレーター †

:i/ページは… †

:i/ページは要素でもある †

:i/ページは要素のインターフェイス †

:i/ページは要素のコンポジション †

:i/ページ内容がオブジェクト構成を表す †

:i/ページ要素のUI †

:i/ページ要素間のつながり[?] †

:i/ページ要素間の連携方法[?] †

:i/メタタグになる要素[?] †

:i/ユースケースに即席ページを †

:i/リンクは種別によって見せ方を変える †

:i/ローカライズに関西弁や語尾に何かを付ける方言も †

:i/一行テキスト †

:i/下位展開範囲のスレッドを統合するもの †

:i/何かのカウンター †

:i/全ページの属性を一覧化して書き換え †

:i/名前の同一視 †

:i/型別一覧 †

:i/大抵のHTMLはテンプレートで †

:i/改行は要素 †

:i/文字列からの型変換はExcelでもやっている †

:i/日付に経過日数 †

:i/検索で共起要素を探すには †

:i/検索式は1つの要素で †

:i/検索用テキストを作るならページ要素で †

:i/検索語にスケール指定を †

:i/機能/New![?] †

:i/機能/カウンター[?] †

:i/機能/カレンダー[?] †

:i/機能/ソート[?] †

:i/機能/バルーン[?] †

:i/機能/文字数[?] †

:i/機能/集合操作[?] †

:i/段落まるごとの打ち消しは見せない †

:i/注釈(note)はセクションを越えない †

:i/注釈は…化 †

:i/画像検索[?] †

:i/目次に出したいだけの注釈 †

:i/編集できないときDanglingLinkを無くす[?] †

:i/置き換えもElement任せ †

:i/裏は複数[?] †

:i/要素がページに記述されたとき、Chain of Responsibilityで？ †

:i/要素が使用できるもの †

:i/要素ごとの処理時間計測 †

:i/要素にidを付けるとき †

:i/要素にはUsageを含める †

:i/要素には個数制限を設けないように †

:i/要素に書き込む方法 †

:i/要素のインスタンスID †

:i/要素のネスト †

:i/要素の使い方は2種類 †

:i/要素の展開タイミング †

:i/要素の説明はページに[?] †

:i/要素は検索時の比較方法もメソッドとして持つ †

:i/要素は部品 †

:i/要素同士の順序 †

:i/要素埋め込み †

:i/要素展開は閲覧時 †

:i/要素間データフローの分岐 †

:i/記法が含むもの[?] †

:i/記法定義は記法→要素クラス→記法 †

:i/設定違いを別記法にするとシンプルに †

セレクター †

データアクセス †

フレームワーク/WikiEngineでやること †

プラグイン †

プロトタイピング[?] †

ページ/要素 †

ページ/要素/API[?] †

ページ/要素/UI †

ライブラリー[?] †

全てURIで †

埋め込み †

旧検索[?] †

汎用記法 †

ページ/要素とは †

:i/ページとは †

ページ/要素はデータベーステーブル内のフィールドにあたる。ただし1要素で値1つ（1フィールドの1レコード分）。

ページ/要素/API[?] †

要素（機能の実装）がAPIを提供してもいい。制限しないだけ。サポートもしない。自由。

ページ/要素ができること／しなくてもいいこと †

:i/リクエスト内のパラメーターと汎用記法のパラメーターは同じ †

呼び出され方を区別しなくていい。
データコンテキストの区別はデータコンテキスト名別のTo…メソッドでできるし。

:i/クエリーにどう反応するか †

要素の協調でリダイレクトをどう行なうか？

→リダイレクトは要素ではなくユースケースの役目。問題なし。

要素がリダイレクトを指示するなら他の要素の出力を抑えなければならない。協調しないということなので、不可。リダイレクトをするユースケースを呼び出すボタンを用意して、利用者に押してもらう（協調しないユースケースを呼んでもらう）ような方法なら可。

要素で行う場合でも、:i/レイアウト要素と同じように、HTMLヘッダーやHTTPヘッダーに出力できれば可能。要素から要素を呼ぶことになる。

:i/要素の展開タイミング †

ページ/要素/UI †

拡張可能な要素のUIとは。
†:i/UIを使うページ要素

要素を呼び出すためのUIは記法。エディターと組み合わせて使う一大機能。
†記法
†汎用記法

:i/簡単なAPI †

簡単不自由なAPIと、面倒自由なAPIの両方を用意。
引数の違い。

例えばページ/要素のコンストラクターを2種類用意。どちらかを定義すれば要素として使えるように。

ページ/要素/API#vcafaa10[?] †

テストコード。
インストール時に動くか確認。
管理者が改造したときにも使える。運用しやすくなる。

UIは…ページ/要素クラス別のページ（複数のバージョンがある場合は下位ページでも作って）にあるテスト実行ボタンで。
テストが複数定義されていればその数だけボタンを表示するように。リフレクション→UIに反映。
テスト環境をどう作るのか。テスト用コードだけでできなければならない。

:i/エラーメッセージにクラス名 †

エラーメッセージの書き方。
競合も矛盾もない。

エラーメッセージはエラー対処のためのUIでもある。
検索がサイト間のハブサイト、エラーメッセージはその検索へユーザーを誘導する。

:i/汎用記法で名前付きパラメーター †

:i/要素にはUsageを含める †

性質 †

:i/設定違いを別記法にするとシンプルに †

設定はスペースにひとつ。その中に同じ要素のパラメーター違いを用意して、それぞれを別の記法にするのがいい。

:i/複数行パラメーターの書き方 †

書き方…記法の問題。改行文字をどう扱うか。

:i/要素3態 †

記法は別になった。要素はオブジェクト。

:i/ページは要素のコンポジション †

ページに要素を与えると機能になるような設計。
ページが機能を持つので、ページ名が機能名になっていい。

:i/要素は部品 †

要素は組み合わせて使う。
個々が機能を提供しなくてもいい。

:i/要素がページに記述されたとき、Chain of Responsibilityで †

→ :i/要素がページに記述されたとき、Chain of Responsibilityで？
要素間／ページ間の依存をなくす。それぞれが独立。連携するなら相手に依存することになる。プラグインが守らなければならないルールが無い代わりに、連携をサポートすることも無い。

:/ページ全体も要素 †

:i/プラグイン要素は記法 †

プラグインは作る。要素の元になる上位クラス。
要素のプラグイン版として作るので、プラグインインターフェイスを実装した要素になる。

:i/要素展開は閲覧時 †

:i/要素はChain of Responsibility †

:i/要素クラスの継承 †

:i/要素の使い方は2種類 †

:i/要素に使い方が2種類あっても実体は1つ †

:i/要素はリクエストから直接呼び出されてもネスト可能 †

:i/要素呼び出しとMVC †

ビューを軽量にするにはビューから子を呼ばないこと。子はコントローラーから呼ぶ。
ビューから別のコントローラー呼び出しができれば効率的なように見えるけど、利用者によって貼り付けるものが変わったり判断を要するので、結局コントローラーがいろいろやることになる。

使われ方 †

:i/URLクエリーは一時的ページ †

:i/要素を必要なときにインストール †

ページ/要素/ †

ページ/要素でやること

ページ/要素/UI