→記法
→X/PageElement[?]

「機能/」で始まるページを作成

目次 † Edit

  1. 目次
  2. 関連
  3. 機能周辺のタグ
  4. 機能
    1. インライン/ブロック/ページ
  5. 実装
    1. 名前付きパラメーター
    2. 機能にUsage
    3. 時刻だけ書いたら同じページに書かれている日付を加味
    4. インスタンス
    5. 複数行パラメーターの書き方
    6. 3態
    7. ページがコンポジション
    8. 機能の展開タイミング
    9. 導入
    10. 導入は「置いて書く」
    11. 機能は部品
    12. 投稿時展開するものは要らない
    13. その他の機能
  6. 設計
    1. 展開は閲覧時
    2. Chain of Responsibility
    3. ページ─機能はコンポジションに
    4. どの機能か
    5. クラス継承
    6. 使い方2種類
    7. 使い方が2種類あっても実体は同じ
    8. リクエストからの直接呼び出しでもネスト可能に
    9. URLクエリーは一時的ページ
    10. MVC
    11. 設置
  • 機能の仕組みについて
  • 「こんな機能があったらいいな」
     

関連 † Edit

 

検索:機能

 

機能周辺のタグ † Edit

Array
 

機能 † Edit

呼び方「機能」→「PageElement」に。

機能追加の仕組みと追加されるもの。
記法の機能。
汎用の機能呼び出し記法か、機能ごとに定義した記法で記述すると機能するようになる。

内部では記法は機能呼び出し記法に置き換えられる。
機能呼び出しをするクラスは機能記法だけを扱えればいい。

インライン/ブロック/ページ † Edit

3種類の型。
使われ方と出力の違い。使われ方はUIの範疇なので、機能では出力だけ気にすればいい。

インライン
普通の。どこからどこまでかを指示して書く。1文字単位。
ブロック
1段落（空行と空行の間）を一度に処理。段落のどこかに書けばいい。
ページ
1ページを一度に処理。ページの属性として書く。

使われ方の違いは「どう書くか」だけの違い。
1行ごとに指示を書くか、1ページにまとめて指示するか。

内部では渡されるデータの長さと呼び出される回数が違うだけ。
複数行をまとめて扱う必要のある場合、表などはページやブロックじゃないと。

実装 † Edit

名前付きパラメーター † Edit

無名引数を使うならリファレンスやコード補完があるときだけ。
汎用記法では名前付きパラメーターにする。

機能にUsage † Edit

機能に書かれているテキストをヘルプに出す。
バルーンやtipsにも出せるようなシンプルな体裁で。
というか、組み込み済みのWikitextで。

Usage()→組み込み済みWikiText

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

検索時の同一性評価で、足りない情報を同じページから取得。
時刻だけの表現には同じページにある日付を。同じページに日付だけの表現がないなら日付時刻から日付を流用。

足りないフィールドは同じ（近い）ページから取得。
Wikiなので情報は非定型。補える場合は少ないし重複がある。
→足りない情報を補うための機能ではなく、近い情報を加味する基本的な機能で。

属性の継承とは違う。
機能が独自に使うデータなので、フレームワークは関わらない。
広い期間で有効なデータ領域を用意するだけ。
→数種類。ページ、プロセス、セッション、アプリケーション。機能向け機能。

各機能はそこにパラメーター履歴を残して置けばいい。

フレームワークでは機能の呼び出し順を一定にする。上から順に。

インスタンス † Edit

というか、設定を複数用意可能に。
同じ機能でも設定ごとに異なる記法を当てて、使い分けできるように。

機能側で設定ページをパラメーター化すればいい。
記法の記述で、Notationと設定を抱き合わせにすれば実現可能。
フレームワークでやる必要はない。

複数行パラメーターの書き方 † Edit

複数行を機能に渡すには、置き換えと埋め込みページが良さそう。

3態 † Edit

WikiText→オブジェクト→HTML
…を機能ごとに行う。出力はそのままレスポンスに含める。

記法（設定に依存しない基本的な記法）をHTMLに変換するためのライブラリを用意。
これで他の記法と変換結果を統一。

HTMLのメモ化は機能ごとに。

オブジェクトの保存はバージョニングのこと。
ページの属性次第で保存するかしないかが決まる。
保存しないのは特殊なページ。

ページがコンポジション † Edit

ページは機能のコンポジション。永続化と復帰を単純化。

リンクは1つのオブジェクトにしたほうが都合が良い。
…が、機能が低下するので却下。
永続化と復帰が複雑になる。

機能の展開タイミング † Edit

ページ特有の解析処理（利用者登録など）の前か後かは機能の実装次第で決まるように。
ページ特有の処理の前に展開すれば展開後のテキストも解析されることになる。

includeのように他のページを取り込む機能を使えば、任意のページを利用者登録ページに取り込んで一括登録できる。その代わり取り込まれるページも管理者権限でしか編集できないようにしなければならない。など利点と欠点がある。

機能の出力はそれ以上処理しないので、自動リンクや埋め込みの展開などは機能側で行なう。
記法（機能呼び出し）のパラメーター部分に記法があっても処理するのは機能。それ以外はページが処理。
これでページ/編集/HTML書き込み[?]の埋め込みと展開を邪魔しないようにできる。
機能の出力はWikiTextではなくHTML。そのままレスポンスの一部になる。

機能の処理のうち共通部分に埋め込みの展開を置いてもいい。
メタシンボルの埋め込みで動的なパラメーター指定ができるが、これを全機能の仕様にしたいので。

入力:WikiText　→

ページ記法の解釈、オブジェクト化。
機能埋め込み展開
機能自身の処理と自動リンク（機能次第）

→　出力:HTML

導入 † Edit

  1. ファイルコピー
    所定のサブディレクトリは1つの機能。
  2. 設定ページ作成
    ページ/名前はフレームワークによって決まっている。

導入は「置いて書く」 † Edit

  1. サーバーにファイルを置く
  2. Wikiに何か書く

これで使えるように。
他に必要なことがあれば、この後にメッセージが見えるように。

機能の出力がメッセージになるか、機能一覧か機能ページにメッセージ出力。

管理者だけが読めるメッセージにしたいときは？
管理者宛の親展メッセージにできればいい。呼ばれるたびに送信。数を制限するなら機能が自粛。

機能は部品 † Edit

機能は部品であるべき。
組み合わせる余地が要る。

  • tag.inc.phpのように固いものや大きなもの、応用の利かないものはまずい。
  • ツール化しないように。
    ツールはページ+機能で。
    アプリケーションはWiki全体で。

投稿時展開するものは要らない † Edit

投稿時展開するくらいなら編集時にボタンなどで展開後のテキストを挿入した方がいい。
MediaWikiの~~~~のようなもの。
そういったボタンを使えないクライアントにはただの文字列を提供。編集ページを開いた時点で展開しておく。それをコピペ。量が多くなるのであまり一度に用意できない。

その他の機能 † Edit

設計 † Edit

機能というクラスは作らない。
記法(記法)と同じ扱い。X/PageElement[?]

記法はネスト可能。
独自データをページに保存可能。ページに残すので履歴付き。

機能のアンインストール方法は？しやすく
しやすくする以上のことはできない。

PageElementをオブジェクトとして永続化する場合、Pageと一緒にということになる。
動的データはPageが持つWikiTextからすべて作成可能。
PageインスタンスはWikiTextから生成したPageElement構造体。

利用者による編集と同じで、ページを更新するときは履歴を作るのが基本。
でも、PageElementの設定（PageElementのコードで定義）で履歴を作らないことが指示されていれば作らない。

展開は閲覧時 † Edit

閲覧時展開。
置き換えない。
HTMLに置き換えてもHTMLエスケープしてしまうので。
ずっと動的に展開。

メタシンボルの類も同じ。他の機能と同様に。

Chain of Responsibility † Edit

ユーザーが直接呼び出すタイプの機能はChain of Responsibility。

クエリーは機能名とページ名を指定するのでなく、やって欲しいことを。
同じクエリーでも導入されている機能次第で別の処理が行われるかも知れないし、いくつの機能が反応するかも変わってくる。管理次第。

これはWikiが正しく構築されていれば正しく動くし、間違っていれば結果（ページ出力）に表れるので分かりやすい。対応付けを厳格にすると設定が難しくなるし、後から付け足した設定で以前の設定が無効になることもあるので、それを回避するのが狙い。

フレームワークもChain of Responsibility。

ページ─機能はコンポジションに † Edit

Notationオブジェクトは書くたびにインスタンス生成。
リファレンスだけを増やしたいときはPukiWikiでの「include機能」のような特別な方法で。

どの機能か † Edit

機能使用時の記述は機能を表すキーワードと、機能指定のキーワードで。
1つのキーワードで複数の機能呼び出し可能。
処理できる機能1つが処理する。

処理可能かどうかの判定は機能ごとに優先順位ありで、機能内に優先度を記述しておく。

クラス継承 † Edit

組み込み済みクラスを継承して機能化。上位クラスと同じ扱いをされるように。下位クラスを知っているクラスからはそのクラスとして扱われるように。

記法類は機能に継承されていいように。

使い方2種類 † Edit

  • ページに記述→機能はHTML生成。
  • 別機能のパラメーターとして記述→別機能からパラメーターを渡すよう要求される→純粋なデータを生成。

ls→ページ名リストを生成。パラメーターとしてはページセットを生成。

書かれた場所…コンテキスト、文脈。文脈次第で型が変わる。意味は変わらない。使いにくくなるので。

使い方が2種類あっても実体は同じ † Edit

どちらの使われ方でも記法を返す。それが何に埋め込まれるかはフレームワークが決める。

実装はインターフェイス。
イベントハンドラーのようなもの。

ユーザーからのリクエストで呼ばれるだけの機能でも、ページに書かれたときに自身を呼ぶリンクやボタンを生成するようにすれば使いやすくなる。

リクエストからの直接呼び出しでもネスト可能に † Edit

PukiWikiのコマンド型機能のように、ページに書かずに使う場合でもネスト可能に。一時的なページを生成してもいい。

またはデリゲート可能に。最後に呼ぶもの以外はデータコンテキスト。

URLクエリーは一時的ページ † Edit

URLクエリーもページと
同じように解析、展開。
使い方も実装も統一できる。

MVC † Edit

M
いくつでも。（複数クラス、複数ファイル）
名前などすべて利用者の任意。
V
いくつでも。
Mと同じように任意。
C
機能のエントリーポイント。
同機能のMとVを呼び出す。
名前に規則あり。フレームワークから呼び出しやすくするため。
C（前）とC（後）がある。
フレームワーク→1.C（前）→2.M、Vなど
→3.子のC（前）→4.子のM、子のVなど
→5.子のC（後）→6.子のM、子のVなど
→7.C（後）→8.M、Vなど

深さ優先の呼び出し。

設置 † Edit

Wiki上での設定で記法を変更できるなら、機能の追加手順は

  1. プログラムファイルを置く
  2. 記法定義に追加
    の2ステップ。ただし、機能呼び出し用の汎用記法 + 機能名で呼び出すなら記法定義は要らない。