詳細な設計→Page
目次 † 
関連 †
#tagcloud(0,related=ページ)
ページとは †
→ Page[?]
ページは再帰構造のデータベース。MVCのModelの中核。MVCのViewでもある。
ページがMまたはVに属するのではなく、ページの中にMとVが存在する。
wikiは1つのページ。
ページとは †
ページは…
- データ保存場所
- 保持しているデータや関連情報を提供する
- 利用者から送られてきたクエリーのうち、自身に関する部分だけは解釈できる
→これはフレームワークに。他のクラスにおいても同じ。 入れ子関係になっている場合、親になるページインスタンスから属性を受け継ぐ
→入れ子にはしない。埋め込みリンクで閲覧時にそう見えるようにするだけ。でも下位にあるページは属性を継承できる。
思い付き †
ページの内容はコードと見なせる †
- ページの内容は基本的に全てコメント
- ただし、#（機能の接頭辞）で始まる行はコード
- コードの出力はコメント
コードとして再処理することは無い。
他のコードの引数（データ）になることはある。 - コードの出力はコードと置き換わる。
ファイルと類似 †
Wikiのページにはファイルと同様にアクセス許可リスト、日付、読み専用などの属性、パスなどがある。
スレッドモード †
コメント、トラックバック、Wikipediaでのノートのようなものは裏に隠す。（ページ/裏に限らず、普段見えないところ）
UIはWikipedia式のタブでいい。
フローとストックのフロー側。
Wiki構築をページで †
Wiki構築をページで。
APIでページ内の表をレコード単位で読み出しするようなことができれば実現しやすい。
アクセス権は引き継がれる †
自動生成ページは元のページ（入力されたページ）すべてのアクセス権を引き継ぐ。アクセス権の合成ルールが必要。
→:ToDo/ページ自動更新時の権限[?]
Wikiは1ページが1つの板 †
…などを。
※利用者登録も？WikiFarmとは違う？
→ToDo/ブログや掲示板として利用できるか[?]
HTML許可ページ †
ブログパーツなど、サイトに貢献する人だけが作れるページ。
HTMLタグなどが閲覧ページまでエスケープされずに残る。
作った後は（ページの機能を利用して）他のページに埋め込んだりできる。言い換えればホワイトリスト。
ヘッダーの使い道 †
ページ内容以外から呼ばれた機能のディスプレイとして使用。
形式いくつか用意。上部にテキスト表示するバナー、下部に表示するバルーン、右上にアイコンや通知バッジ出すなど。コードで指定。そのためフレームワーク側にライブラリとして用意を。
組み込み済みの基本的な記法を使えるように。
ヘッダー。つまり通常のページを埋め込みリンクで埋め込むだけ。
内容は…
…などをAPI経由で追加。
方法 †
canonical †
- 同じページの編集ビュー・履歴ビューなど
ページ名（外部名）が同じページはすべてデフォルトビュー（閲覧ビュー）をおすすめ。 - データフォーマットの違い
HTML/プレーンテキスト/印刷用など
デフォルトのデータ形式（HTML）に。
スタイル・体裁のほうのフォーマットなどは対象外。
読む側設定のスタイルは無視できないのでおすすめ条件にしない。
体裁の方もそのまま。
これはGoogleに見せるためのメタデータ。
セクションと比べると… †
ページはセクションの集約。
Wikitextを持たない。代わりに（Wikitextを持った）セクションを持つ。
作り方はページ作成フォームとか、DanglingLinkとかから。
リンク先になれる。URIを持つ。
下位展開のルールによって一度に展開される埋め込みの深度に制限がかかる。
全ページ見出しから始める †
閲覧時、ページ名を見出しと同様に表示。
見出しになったページ名にもEditボタンを付ける。
ページ内容の有効な一行目がページ名。なのでページ名を見出しにすればいい。
記法/タイトル記法もあるけど、これは後に続く要素にタイトルを付けるものなのでページタイトルには向かない。でも最初の記法/タイトルをタイトルにしてもいいかも？
new機能を標準に †
ページ名の隣（一覧や検索結果や自動リンク）には機能/New![?]が付く。
実装するならオプション。サイト設定でon/off。
添付ファイルもページ †
→機能/ファイルアップロード[?]
存在しないページは無い †
存在しないページ=内容が空で存在するページ。
ページ管理クラス（ページとファイルを結び付けるクラス）以外では（UIからも含めて）そうなっているように。つまりこれを実現するのはページ管理クラス(PageFactory)
本文のレンダリングは最後 †
描画順序は内容が変わりにくい順で、上から。ヘッダー、サイドバー、フッター、本文。
これは重複描画の判定を考えて。
1つの画面に重複部分があるとき、ヘッダーなどを優先、重複判定は本文側でする。
二重展開を防ぐようにした場合、先にヘッダーなどを展開しないとヘッダー編集時のプレビューができなくなるから。
ページを更新できるのは自身だけ †
編集など、ページの属性を変更する操作は自身が全て行なう。
（自身とはインスタンス）
他から変更したいときは、指示を対象ページにキューイング。
そのページは最新状態をリクエストされるまでに自身を変更すればいい。
キュー出し/入れはフレームワーク/WikiEngineで。それを呼び出すのはページクラス。ページだけのものではないので。
ページの参照は自由にできていい。普通にロックを掛けて読むだけ。
編集は遅延処理。
ページに手を加えるにはページごとに{属性→値}という形式で指示をキューイング。
適当なときに処理。
最新版が必要なときはそのページを呼び出して、最新版になってもらう。
これはページの特殊な参照方法。
衝突したか知らせるために、編集後のレスポンスには最新版が必要。それまでに更新しなければならない。
Webページのテンプレートは特定のページに書く †
システムが用意するページ（Webページ）は:config/Page/Editのような特定のページで定義。
WikiTextの編集方法でページデザインやヘッダーの機能を変更。
このページを書き換えて…
条件、それに合ったときの戻り値は特定のページに。
条件に使えるデータ、戻り値の用途はシステムにコードで定義。（用意されている中から選択して設定で利用）
リストとハッシュ †
エントリー、見解はハッシュ構造。順序なし。キー指定で参照。
版はリスト構造。末尾が最新版。
ページ内容がオブジェクト構成を表す †
ページは独立したオブジェクト。
それを構成するPageElementを決めるのはページ内容。
機能からはこのオブジェクト構成を参照できるように。
WebページのDOM風アクセスと同様に。
1つのページ内部名にインスタンスは1つ †
Flyweight。内部名がID。ページ名は同じものが複数あっていいが内部名は重複なし。
アクセスログはページの属性 †
アクセスログから逆リンクを表示すればその場しのぎの低負荷のBackLinkになる。
ページは機能のDB †
機能が生成するデータはPageElementを通じてページに記録。見ることは出来るので、読みやすいデータ書式がいい。
機能が独自にデータ保存するよりも使いやすくなければ無意味。
例えばテーブル（表）にレコード形式のデータ、定義リスト(DD)にキー・バリュー形式のデータ、のように。
資料 †
ごく簡単なHTMLの説明 - The Web KANZAKI
http://www.kanzaki.com/docs/htminfo.html
閲覧時のページ→HTML変換の参考に。
空のページ †
空でページ名だけのページは、閲覧時に編集画面。DanglingLinkのかわり。
内容が無いからといって削除されたりはしない。
属性と内容 †
ページ/属性と、ページ/内容。
「属性」という言葉が紛らわしい。Tag: ToDo
どちらも記法あり。内容の方はそれに加えてプレーンテキストも。
属性の方にプレーンテキストを書いてもいいが特に意味がない。
APIや機能呼び出しからは区別なし。指定すると呼び出しが煩雑になるので。
継承処理後の属性と内容を1つにしたものが参照可能になる。
属性部分を何かで括ったりもしない。
他オブジェクトとの関わり合い †
ページ…Elementのコンテナー。ページがページを含むことはできない。
ページ同士に関連は無し。リンクオブジェクトでつながりが分かるだけ。
Element…ページの要素。ページはElementに含まない。深い構造にしないため。
ページ/セクション（実装がページと類似）はセクション同士でネスト可能。
コード †
code*:364 Perl