ページ/型とその関連項目についての設計。

ページ/属性の実装について、あとでなおす


ページ/型について再考 Edit

ページ/型添付ファイルのもの Edit

ページ/内容添付と同じ扱いにするので、ページ/型を「ページ/要素」にして添付ファイル扱い。
ページ/型はクラスで表現。「ページ/要素」かMIMEタイプのいずれかを指定。
CSVなどを入力するときはMIMEタイプで指定(記法で書いたテーブルをCSVで出力するならは「ページ/要素」、出力をデータコンテキスト「CSV」で行なう)。HTML書き込みのときもMIMEで指定。Markdownページ/要素を表す記法なのでMIMEタイプではなく「ページ/要素」。

ページ/要素」も独自のMIMEタイプにしてしまうのがいい。application/prs.X.document とか application/x-X-document とか。

ページの本体は属性領域。そこにページ/型名が書かれていて、名を冠したクラスに別の操作方法が定義されている。独自オブジェクトを操作するクラスは1つ。それが今のPageクラス(の一部)。

要素やPNGはいいけどHTMLはだめという編集権限はどう設定するのか?→「ページ/型:HTMLを投稿できる」という権限/鍵をファイルアップロードユースケースで判定。錠の無い権限?→どこかのページにだけこの錠を与えておけば、これを継承した下位ページだけでHTMLを受け入れるという仕様にしたい。権限/錠は「鍵を要求する」のと、「鍵があれば許可する」という意味。
閲覧権限も別に設定できたほうが一貫性が保てていい。「ページ/型:HTMLを見られる」という錠と鍵が揃うとページ/型:HTMLのときでもページを閲覧できる。

「(このページが)ページ/型:HTMLのときページを閲覧できる」といった表記のほうがいい。

ページの内部 Edit

ページは複数ページのコンポジション。

それぞれのページは要素のコンポジション。

ドキュメントとスレッドのページ/型は「ページ/要素」ほか添付ファイル次第のにもなる。
属性/裏/権限領域ページ/型は「ページ/要素」だけで参照時に属性/継承などの特殊処理。それとも独自で別クラスにする?

スレッドは1件1件がドキュメントと同じ Edit

ドキュメントはスレッド投稿の1件に相当。それぞれ内部にページ/型を持つ。
多くの場合、ドキュメントのページ/型は「ページ/要素」。スレッドのページ/型は「text/plain」。

→:スレッドモードはドキュメントモード

属性領域はただのページ Edit

属性領域もページページには属性領域があるけど「属性領域の属性領域」は作らない。
ページ属性領域は同じ名前を持つだけで、定義上は無関係。クラス定義でもページの参照と同じAPIで属性領域を参照。

属性領域の特殊な参照方法(属性/継承してから参照)は参照する側で行なう。属性領域を参照するときは必ず継承処理も行なう…というのをカプセル化したクラスをコントロール層に用意。ページクラスは使い勝手の良さやプログラミングのしやすさとは無縁にしておく。

ページ/属性を何かと統一できない? Edit

特殊な点 Edit

属性/継承処理が特殊。

これをどこで定義して、何をトリガーにするのか?
属性の参照時。

属性を参照する側が処理するのか/参照される側が処理するのか?
→参照される側。参照される側は自身が属性だと自覚していなければならない。

属性の参照方法は特殊なもの?
属性であることくらいは意識しないと。

ページ/内部名属性領域名(裏/権限などもここで指定)とページ/要素名(複数)を指定すれば、継承済みのすぐに使える値が(Dictionaryで)手に入るように。
ページ/要素を指定しなければ全ての属性値が手に入って、受け取った側でいろいろ探せるように。

継承があると(継承ルールの「連結」により)値が必ずコレクションになってしまう。データが通常のデータアクセスとは変わってしまうので、参照方法もデータアクセスとは違うものにしなければならない。その代わりデータアクセスとは違う形式の値を返していい。

データコンテキストの指定で属性/継承すれば分かりやすい? Edit

継承ルールの「連結」を排除すればデータアクセスと統一できる。
属性であることや継承などを気にするのは、参照される側だけでいい。隠蔽。
直近の親が複数あるので連結が必要になっている→その複数の値は自身の値が無いときだけ。
→「連結」の排除は不可能。必要な場合がある。

データコンテキストの指定で(参照する側で)継承付きの参照方法を使う?「属性」コンテキスト。APIとしては使いにくくなるけど、全てデータコンテキストでというのは分かりやすい。
属性領域は他のデータコンテキストで読めてもいいので、その仕様と統一。
データコンテキストでの指定だと、Xの外からも継承付き参照ができる!!
→コンテキスト「属性」でデータアクセスすると、継承済みの属性値が手に入るように。継承ルールの「連結」があるので値はいずれもコレクション。この点が他のコンテキストと異なる。
他に「権限」というのも。
ページ/裏の場合は「属性」にする。でも継承はない。(将来、継承ありになってもそのままでいい)

属性」コンテキストでは形式が分からない。他は「HTML」や「JSON」なので「属性」ではなく…?(でも継承付きであることが分からなければならない)
データコンテキストは形式か。「属性」ではなく「継承ありのDictionary」であるべき。

データコンテキスト属性/継承は合わない。

記法定義 Edit

記法ページ/要素と別。どんな記法がどの要素になるのかは変更可能。

記法定義をどこに書くか Edit

Xにおいて)記法が存在するのはページ/型ページ/要素になっているページ

記法系データコンテキストページ/型NotationTextで、コンテキストがWikiCreoleなら===が見出しになる。それがMarkdownコンテキストでは###に変化。要素クラスで記法定義をしなくていい。記法→要素のときは「データコンテキスト」と呼んでいない?→パース?記法データコンテキストと別。記法データコンテキストNotationText」のときの更に細かい

例えば日付記法WikiCreoleでもMarkdownでもリスト記法が同じであるように、日付記法も同じ。
WikiCreoleでの日付記法と、Markdownでの日付記法で定義が重複する?定義は記法系別か要素別か?→記法別。1つの記号が記法によって異なる要素になり得るので。同じ定義が複数の記法にあっていい。

プラグイン要素の)記法定義は要素別に。要素はインストール/アンインストールするので。記法別だと要素の導入で記法クラスを書き換えなければならない。要素によっては対応できない記法があるので、「記法定義が無ければ汎用記法になる」…といった定義ができるように。

記法定義は双方向 Edit

  • 記法 → 要素クラス名とそのコンストラクターに渡すパラメーター
  • 要素インスタンス → パラメーター埋め込み済みテキスト
    …ができれば記法変換はできる。

リスト内の改行は…
オブジェクト→PukiWikiのときにPukiWikiの改行記法に置き換え。
オブジェクト→Markdownのときは改行文字に置き換え。
…なので、記法に依存。

リストの場合なので、要素クラスにも依存。

どの要素が×どの記法になるのか…に依存するということ。
どう定義するか?
→これまで通り、要素にToMarkdown()を定義。要素単位でインストール/アンインストールできるように。
入力…記法→オブジェクトも要素で。これまで通り。

要素を2系統に分ける Edit

  • DOMにある要素
  • DOMに無い要素
    • 日付とか
    • パラメーターが豊富
    • 記法系に左右されない
    • 汎用記法でも書く
    • 簡易マークアップ記法にない。合わせて使用しても競合せずに使用可能。
    • プラグインなので、要素ごと追加/削除したい。

記法はカスタマイズ可能に。
既存記法の無効化はどう行なうか?
→要素クラス別のページで正規表現を再定義。シンタックスシュガーもここで追加できる。ビルトイン記法を削除して、プラグインの要素の記法にするとかも。

カスタマイズを2系統に分けて考えると…
DOMにある要素の場合はインストールすることはない。記法系ごとに定義してチートシート風にできる。要素ごとでなくていい。
それ以外はインストール/アンインストールするけど記法系に依存せず常に同じ記法になるはず。インストールしやすくするため要素ごとに記法定義するけど、記法汎用記法1つでいい。設定で付け足すことができる。
記法系は後からでも増やせる。DOMにある要素の記法を増やせば足りるので可能。

それと…
記法→オブジェクトを定義するのはオブジェクト→記法と同じクラスで。

記法系ごとのクラスは必要 Edit

記法→オブジェクトでは要素クラスの優先順位と、要素クラス間の上下関係を規定する記法系クラス(例えばMarkdownを表すクラス)が要る。「この要素の下にあの要素は作れない」など。

記法系クラスは…
ビルトイン要素ではMarkdownなどといった記法系を表すクラス。
プラグイン要素では今のTokenize()をするクラス。

記法系を表すクラスは例えば…見出しクラスからRegexを得て、引用よりも後に評価するとか、マッチした部分を見出しのコンストラクターに渡し、その際に下位要素になり得る要素のクラス名を全て指定する…といったことをするクラス。

記法定義とデータコンテキストページ/型 Edit

ページ/要素が対応すべきデータコンテキスト Edit

どの記法系で出力するときもデータコンテキストでは同じ"NotationText"という。別のクエリーパラメーターで何記法かを指示される。どの記法でも同じ表記になるプラグイン要素にとっては「別のクエリーパラメーター」を無視して"NotationText"にさえ対応すればいいので好都合。

ほか Edit

CSVコンテキストでは最上位のみフィールド生成 Edit

コンテキストは下位要素に引き継がれるので、下位要素もフィールドを生成しそうになる。でもCSVはネストしないもの。
リクエストを直接受けた要素(クエリーパラメーターで指定された要素)では下位要素の生成したフィールドを平坦化(""でくくるだけ)。

他のコンテキストでも同様に。