詳細な設計→Page

目次 † Edit

  1. 目次
  2. 関連
  3. ページ周辺のタグ
  4. ページとは
  5. 思い付き
    1. Wiki構築をページで
    2. アクセス権は引き継がれる
    3. Wikiは1ページが1つの板
    4. HTML許可ページ
    5. ヘッダーの使い道
  6. 実装
    1. 構成
    2. ページとは
    3. 全ページ見出しから始める
    4. newプラグインを標準に
    5. 添付ファイルは1ページ扱い
    6. 存在しないページは無い
    7. ページの内容はコードと見なせる
    8. 本文のレンダリングは最後
    9. ページを更新できるのは自身だけ
    10. Webページのテンプレートは特定のページに書く
    11. コンテンツとスタイルの分離
    12. リストとハッシュ
    13. ページ内容がオブジェクト構成を表す
    14. 1つのページ内部名にインスタンスは1つ
    15. アクセスログはページの属性
    16. ページはプラグインのDB
    17. 資料
    18. DOMアクセス
  7. 設計
    1. 属性と内容
    2. 他オブジェクトとの関わり合い
  8. コード
    1. Perl

関連 † Edit

検索:ページ

ページ周辺のタグ † Edit

Array

ページとは † Edit

→Page[?]

ページは再帰構造のデータベース。MVCのModelの中核。MVCのViewでもある。
ページがMまたはVに属するのではなく、ページの中にMとVが存在する。
wikiは1つのページ。

思い付き † Edit

  • 仕様が大きくなりそう
    ページの仕様は分割する必要がありそう？
  • Wikiのページにはファイルと同様にアクセス許可リスト、日付、読み専用などの属性、パスなどがある。
  • 章を1ページにすれば使い回しや情報集約のために分ける作業が減る。

Wiki構築をページで † Edit

Wiki構築をページで。
他のWikiEngineでのプラグイン。

  • ページにはアクセス権、日付、読み専用属性、パスなどがある。
  • 章を1ページにすれば使い回しや情報集約のために分ける作業が減る。

APIでページ内の表をレコード単位で読み出しするようなことができれば実現しやすい。

アクセス権は引き継がれる † Edit

自動生成ページは元のページ（入力されたページ）すべてのアクセス権を引き継ぐ。
アクセス権の合成ルールが必要。

自動生成ページの実装次第。他の要素には影響しない。

Wikiは1ページが1つの板 † Edit

※利用者登録も？WikiFarmとは違う？

HTML許可ページ † Edit

ブログパーツなど、サイトに貢献する人だけが作れるページ。
HTMLタグなどが閲覧ページまで残る。

作った後は（ページの機能を利用して）他のページに埋め込んだりできる。

ヘッダーの使い道 † Edit

**自由欄
適宜、動的要素を表示する部分。ページの先頭に表示。WikiFormatで位置が指定されているときはそこ（だけ）に表示。RIGHT::t/属性
→ヘッダー。つまり通常のページを埋め込みリンクで埋め込むだけ。
動的かどうかはプラグインによるのでここでは考慮しない。

内容は…

…などを章として追加。

実装 † Edit

構成 † Edit

310x310

ページヘッダー、内容、ページフッターは連結して1つのページとして閲覧時展開。

ページヘッダーにページ見出し（ページ名とEditボタン）やタグリンク一覧（そのページ名を表すメタシンボル付き）を置く。

ページとは † Edit

ページは…

  • データ保存場所
  • 保持しているデータや関連情報を提供する
  • 利用者から送られてきたクエリーのうち、自身に関する部分だけは解釈できる
    →これはフレームワークに。他のクラスにおいても同じ。
  • 入れ子関係になっている場合、親になるページインスタンスから属性を受け継ぐ
    →入れ子にはしない。埋め込みリンクで閲覧時にそう見えるようにするだけ。でも下位にあるページは属性を継承できる。

ページは…

  • 読まれる
  • 書かれる
  • 自動的に書かれる
  • 自動的に読まれる
    ページに書かれた設定をプログラムが参照するとき。
  • 名前を持つ
  • ID（内部名）を持つ

ページの構成…

全ページ見出しから始める † Edit

閲覧時、ページ名を見出しと同様に表示。
見出しにはEditボタンを。

ページ内容の有効な一行目がページ名。なのでページ名を見出しにすればいい。
（一行目かTITLE:やNAME:で始まる行。複数あるなら全てを連結したもの）

newプラグインを標準に † Edit

ページへのリンク（Wiki内リンク）にはNew!が付く。
実装するならオプション。サイト設定で。

添付ファイルは1ページ扱い † Edit

添付ファイル1つに1ページ生成。フォーマットの統一。
こうしたほうが扱いやすいし、ページの機能を添付ファイルでも利用できる。

埋め込みリンクを利用して添付ファイルに対応するページを他のページに埋め込み。

存在しないページは無い † Edit

存在しないページ=内容が空で存在するページ。
ページ管理クラス（ページとファイルを結び付けるクラス）以外では（UIからも含めて）そうなっているように。

ページの内容はコードと見なせる † Edit

ページ内容をコードと見なすと…

  • ページの内容は基本的に全てコメント
  • ただし、#（プラグインの接頭辞）で始まる行はコード
  • コードの出力はコメント
    コードとして再処理することは無い。
    他のコードの引数（データ）になることはある。
  • コードの出力はコードと置き換わる。

本文のレンダリングは最後 † Edit

本文（ヘッダーなど以外の部分）の展開（レンダリング、HTML変換）は最後。
1つの画面に重複部分があるとき、ヘッダーなどを優先する。
二重展開を防ぐようにした場合、先にヘッダーなどを展開しないとヘッダー編集時のプレビューができなくなるから。

ページを更新できるのは自身だけ † Edit

編集など、ページの属性を変更する操作は自身が全て行なう。
（自身とはインスタンス）

他から変更したいときは、指示を対象ページにキューイング。
そのページは最新状態をリクエストされるまでに自身を変更すればいい。

参照は自由にできていい。

編集は遅延処理。
ページに手を加えるにはページごとに{属性→値}という形式で指示をキューイング。
適当なときに処理。

最新版が必要なときはそのページを呼び出して、最新版になってもらう。

衝突したか知らせるために、編集後のレスポンスには最新版が必要。それまでに更新しなければならない。

Webページのテンプレートは特定のページに書く † Edit

システムが用意するページ（Webページ）は:config/Page/Editのような特定のページで定義。

このページを書き換えて…

  • ページの構造・内容（HTML)
  • どんなときにどんなページを使うか
    User-Agent別に定義して、フルブラウザ用とか、ケータイ用とか、スマートフォン用とか。
    利用者の権限別とか。

条件、それに合ったときの戻り値は特定のページに。
条件に使えるデータ、戻り値の用途はシステムにコードで定義。（用意されている中から選択して設定で利用）

コンテンツとスタイルの分離 † Edit

「人気のページ」など、データを提供するページはコンテンツとスタイルを分ける。
スタイルは…

  1. スタイルシート
    RIGHT::t/スタイルシート[?]
  2. フィルター
  3. テンプレート

…で。
フィルターとテンプレートは別のページに埋め込んだときに可能…になるはず。

→検索に含まれている。

リストとハッシュ † Edit

リスト状に並んだページ…版。
ハッシュに格納…Wiki。

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

ページは独立したオブジェクト。
それを構成するElement系クラスを決めるのはページ内容。

プラグインからはこのオブジェクト構成を参照できるように。
WebページのDOMアクセスと同様に。

1つのページ内部名にインスタンスは1つ † Edit

Flyweight。内部名がID。ページ名は同じものが複数あっていい。

アクセスログはページの属性 † Edit

アクセスログもページ化する。
プラグインから扱えるように。

ページはプラグインのDB † Edit

プラグインが生成するデータはページに記録。
プラグインが独自にデータ保存するよりも使いやすくなければ無意味。

資料 † Edit

ごく簡単なHTMLの説明 - The Web KANZAKI
http://www.kanzaki.com/docs/htminfo.html

閲覧時のページ→HTML変換の参考に。

DOMアクセス † Edit

ページ名の代わりに、ページ名＋その中のElement を書けるように。
getElementsById, getElementsByClassNameといった感じ。

クラス名かインスタンス名のどちらか、あるいは両方を指定。
いずれも複数のインスタンスを取得できる。
クラス名の指定はサブクラス名の指定を含む。
だから指定したクラスが返るとは限らない。

Elementはクラス名、インスタンス名で指定。
クラス名→複数インスタンス。
インスタンス名→複数インスタンス。（インスタンス指定でも複数返ってくることがあるので、大抵の場合先頭を使う）

Elementのインスタンス名とは…

  • 見出しの場合は表示される見出しそのもの
  • 表（テーブル）ならそのタイトル
  • ol、ulならタイトル
  • それらしいパラメーターを持たないElementはインスタンス名
    あらかじめインスタンス名を付けられるように。それを参照時に指定。

実装上はどれもインスタンス名を持っていて、それが何か他のパラメーターになっている。
インスタンス名が要求されると、タイトルを返すとか。

インスタンス名を持たないというのも有り。インスタンス名では探せなくなる。

設計 † Edit

属性と内容 † Edit

ページ/属性と、ページ/内容。
「属性」という言葉が紛らわしい。:t/？[?]

属性
テキストのリスト。下位ページが継承する。（1項目ごとに）
内容
テキスト1つ。継承されない。

どちらもWikiNotationあり。内容の方はそれに加えてプレーンテキストも。
属性の方にプレーンテキストを書いてもいいが特に意味がない。

APIやプラグイン呼び出しからは区別なし。指定すると呼び出しが煩雑になるので。
継承処理後の属性と内容を1つにしたものが参照可能になる。
属性部分を何かで括ったりもしない。

他オブジェクトとの関わり合い † Edit

ページ…Elementのコンテナー。ページがページを含むことはできない。
ページ同士に関連は無し。リンクオブジェクトでつながりが分かるだけ。
Element…ページの要素。ページはElementに含まない。深い構造にしないため。

PageとNotationは、ContainerとElementの関係。
クラス名…Page、Notation。”Container”、”Element”という言葉は属性名やインターフェイス名で使用。

機能

  • 同型のオブジェクトとの類似度算出
    コードで。Elementのクラス別。
  • 出力用（ページの一部になるもの）に変換
    逆変換は不可能。
  • 生成
    コンストラクター

コード † Edit

Perl † Edit

code*:364