• 追加された行はこの色です。
  • 削除された行はこの色です。
RIGHT:&tag(フレームワーク,実装,設計,コード,目次);

*目次 [#c729b3ae]
#contents
#br
#lsx(new=true);
#br

*関連 [#s02572b1]
#related
#br
#lsx(tag=フレームワーク,new=true,except=^フレームワーク/Webアプリケーション(/.*)?$)
#br
[[検索:フレームワーク]] [[検索:Webアプリケーション]]
#br
----
*フレームワーク/Webアプリケーション [#n2fa1fa2]
RIGHT:[[:t/Webアプリケーション]]


*思い付き [#o853ebd0]


*実装 [#f4432ed2]

**MVC [#d706a84c]
[[http://d.hatena.ne.jp/pmint/20110317/p1>http://d.hatena.ne.jp/pmint/20110317/p1]]

Control→Model
Control→View->Control2→View2→Control3 ...
**%%出力の統合はどうやるか?%% [#v39f55ec]
%%→順位付きで出力。同順位同士では後に追加。%%
%%順位には複数に分かれたHTMLヘッダー領域も含まれる。%%
**メモ化[#s9415e95]
同じクエリーを受けた場合、キャッシュしておいたHTMLを返せばいい。
何を同じだと見なすかは[[キャッシュの有効期限]]に。

RIGHT:[[:t/キャッシュ]]


***キャッシュの有効期限 [#sc78dd1c]
サーバー側キャッシュデータの有効期限は基本値に設定値を加えた物にする。
この設定値はWiki上で
ページの属性(RegExp)→値(負の値でも可)
という形で定義。
RegExpはページの属性どれにでも当てはめられるように。

RIGHT:[[:t/キャッシュ]] [[:t/RegExp]]
**エラーページにクエリーを [#fe39b237]
エラーページには送られてきたURLクエリーを載せる。
再送信できるように。

さらに、コピペで保存できるように。

エラーページへのURLを示す。
ページ内のテキストで。
このときのURLはエラーページのものではないからブラウザーのアドレス欄には出ない。ページ内のテキストでやる必要有り。

再送するには再送ボタンかエラーページに再アクセスして再送ボタン。
**やること [#pd759be6]
-入力
入力からセッションデータ保存まで。
-アプリケーション呼び出し
エントリーポイントは1つでいい。
-出力
出力するHTMLを受けて、
代替文字列の置き換え(セッションデータに置き換える)まで。
-エラー処理
-ファイルのオブジェクト化
ファイルはFlyweightであるべき。


**競合問題 [#r5cb4138]
複数のファイルをロックするため、WikiEngineの冒頭で必要なファイル全てにロックをかけられるかどうか知りたい。
FlyweightFactoryが一度呼び出されるだけで複数のFileを生成できると便利。
Fileを生成してしまっていい。ロック済みのFileが要求通りに返せたことが分かればいい。
要求が1つでも叶えられなかったらFileを全て破棄。

確実にロックするため、ブロッキングモードでロック試行する。
そのため、FlyweightFactoryではロック数を参考にして、ロック処理をするかどうか判断。

1プロセスが1トランザクションのようなもの。
アトミックに。
*設計 [#cf7dbd20]

**クエリーにはユースケース名+ステップ名や番号を [#c68bdee8]
設計と実装を対応付けしやすいように、何かのフレームワークでのActionにあたるものをユースケース名とその中のステップ(サブユースケース名)で実現。
ユースケース名+ステップ名の対1つあたりに複数のビューが含まれる。(ログイン成功時/失敗時の2つが同じステップに含まれたり)
1つのビューには複数のビュー用クラス、そのクラスにはそれぞれMVCがある。
**ビュー用クラスの設計 [#uf199e46]
1つのHTMLページは複数のビュー用クラスで構成。
HTMLページになったときの型の違いがクラスの違い。
ボタンやイメージを配置、それぞれのイベントハンドラーを記述するGUI設計に似た形で。
ビューに配置できるクラスはそれぞれがMVCを持つ1つのWebアプリになるように。連携はデータで。それと入れ子関係なら属性の参照ができるように。

PukiWikiの閲覧ページなら…ヘッダー、サイドバー、本文エリアなどを区切るコンテナーが1つのクラス。3区分とも同じクラス(ページ)を含む。
Wikiの場合はどれもページ。その中のプラグインで要素が配置されるのでフレームワークの効果は薄い。
閲覧ページ自体も設定ページで定義されるので、結局みんなページとその中のプラグイン。ビュー用クラスはページだけでいい。→ページが持っているビューだけでいい。

-ビュー用の各クラスはChain of Responsibility駆動
クエリーの中で自身が解釈できるものを解釈。
Webアプリは一問一答ばかりなので、これを一問二答/三答にできれば尚可に。

RIGHT:[[:t/Chain of Responsibility]]
**図1 [#w73c0570]
&ref(:Image/クラス図 Webアプリフレームワーク1.png);


*コード [#ue3e33c5]

[[プロトタイピング]]の実装。
**擬似言語 [#m4d3809a]
[CGIから呼ばれて…]
+URLクエリーを得る。
+POSTされたデータを得る。
+クッキーを得る。
+セッションデータを復元する。
++クッキーにあるセッションIDを得る。
セッションIDを使って、ファイルからセッションデータを復元する。
+セッションデータを更新する。
URLクエリー、POSTされたデータ、クッキーをセッションデータに格納。
+フレームワーク/WikiEngineを呼ぶ。
+セッションデータをファイルに保存する。
ファイル名はセッションIDによる。
+出力にクッキーを付加。
+出力。


**Perl [#p0794bac]
[[code*:357]]