目次 † Edit

  1. 目次
  2. 関連
  3. ページ周辺のタグ
  4. ページとは
  5. 思い付き
    1. Wiki構築をページで
    2. アクセス権は引き継がれる
    3. Wikiは1ページが1つの板
    4. HTML許可ページ
    5. ヘッダーの使い道
  6. 実装
    1. newプラグインを標準に
    2. 添付ファイルは1ページ扱い
    3. 存在しないページは無い
    4. ページの内容はコードと見なせる
    5. 出力の統合はどうやるか？
    6. ページ/編集はページ/属性を変える一例
    7. 本文のレンダリングは最後
    8. ページを更新できるのは自身だけ
    9. Webページのテンプレートは特定のページに書く
    10. コンテンツとスタイルの分離
    11. リストとハッシュ
    12. ページ内容がオブジェクト構成を表す
    13. 1つのページ名にインスタンスは1つ
    14. アクセスログはページの属性
    15. ページはプラグインのDB
    16. 再作成を頻繁に行うので…
    17. 資料
    18. 属性はファイル名に保存
      1. ファイル名に書けない属性
      2. ファイル名に置く属性
  7. 設計
  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

ページは…

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

ページは…

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

ページの構成…

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

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

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

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

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

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

存在しないページ=内容が空で存在するページ。
ページ管理クラス以外では（UIからも含めて）そうなっているように。

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

出力の統合はどうやるか？ † Edit

→順位付きで出力。同順位同士では後に追加。
順位には複数に分かれたHTMLヘッダー領域も含まれる。

ページ/編集はページ/属性を変える一例 † Edit

ページ/属性のエディターがWikiサイト。
ページ/編集はページ/属性にある「内容」を更新、保存する機能。
→継承される領域やページ/裏だけでなく、ページ/属性の数だけWiki上のページのフィールドがあるということに。
RIGHT::t/属性

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

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

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

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

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

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

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

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

衝突したか知らせるために、編集後のレスポンスには最新版が必要。

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

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

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

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

条件、それに合ったときの戻り値は特定のページに。
条件に使えるデータ、戻り値の用途はシステムにコードで定義。

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

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

  1. スタイルシート
  2. フィルター
  3. テンプレート

…で。

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

リストとハッシュ † Edit

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

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

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

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

Flyweight。

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

ページを扱うとき、一緒にアクセスログも扱えるように。

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

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

再作成を頻繁に行うので… † Edit

ページにID
同一IDはFlyweight。
→Factoryが要る。

資料 † Edit

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

属性はファイル名に保存 † Edit

ファイルの中に書くよりも活用しやすいので、属性はファイル名の一部に。
データ量が大きい属性やプラグインが定義する属性には対応せず、ファイルの中に書くことにして。
凍結→r、とか編集権限削除とか読み取り専用とか。

ファイル名に書けない属性 † Edit

長すぎるもの。
リンクされたときに、リンクのツールチップ（バルーン表示）に出す文字列。
そのページの概要、一行説明。
→ページ内か属性専用欄に。ページのヘッダーとして。

ファイル名に置く属性 † Edit

設計 † Edit

コード † Edit

Perl † Edit

code*:364