目次 Edit

 
 

関連 Edit

 
 

検索:フレームワーク 検索:Webアプリケーション

 

フレームワーク/Webアプリケーション Edit

思い付き Edit

実装 Edit

→クラス

CSRF関連 Edit

設定項目にオプション

  • POSTリクエストのHTTP_REFERERが空でも問題視しない
    HTTP_REFERERがよそのドメインなのは常にブロック
  • POSTリクエストには事前に発行されたトークンが必要
    XSS対策を利用する方法なので二の次。
    ユーザーエージェントがwikiのドメイン内を読み書きできていることを確認。

設定はWikiページに書けない Edit

Wikiが動く以前に使うので。
ページにすると参照するためにWikiが必要。

MVC Edit

http://d.hatena.ne.jp/pmint/20110317/p1

Control→Model
Control→View->Control2→View2→Control3 ...

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

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

メモ化 Edit

同じクエリーを受けた場合、キャッシュしておいたHTMLを返せばいい。
何を同じだと見なすかはキャッシュの有効期限[?]に。

キャッシュの有効期限 Edit

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

エラーページにクエリーを Edit

エラーページには送られてきたURLクエリーを載せる。
再送信できるように。

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

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

再送するには再送ボタンかエラーページに再アクセスして再送ボタン。

やること Edit

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

競合問題 Edit

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

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

設計 Edit

クエリーにはユースケース名+ステップ名や番号を Edit

設計と実装を対応付けしやすいように、何かのフレームワークでのActionにあたるものをユースケース名とその中のステップ(サブユースケース名)で実現。
ユースケース名+ステップ名の対1つあたりに複数のビューが含まれる。(ログイン成功時/失敗時の2つが同じステップに含まれたり)
1つのビューには複数のビュー用クラス、そのクラスにはそれぞれMVCがある。

ビュー用クラスの設計 Edit

1つのHTMLページは複数のビュー用クラスで構成。
HTMLページになったときのの違いがクラスの違い。
ボタンやイメージを配置、それぞれのイベントハンドラーを記述するGUI設計に似た形で。
ビューに配置できるクラスはそれぞれがMVCを持つ1つのWebアプリになるように。連携はデータで。それと入れ子関係なら属性の参照ができるように。

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

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

図1 Edit

クラス図 Webアプリフレームワーク1.png

View配置がFactory Edit

View上にあるものを呼び出すという仕組み。WikiEngineのページ展開のように。
Xを呼び出す→View展開、展開に必要なものを呼び出す→その中でView展開が起きる→そこでまた必要なものを呼び出す。
Xフレームワークの機能を継承している。
下位のモノを展開するときに自身が持つデータを与える。というかグローバルなデータがX処理後のものになる。
モノとモノの間、縦のスコープで有効なデータ。

コード Edit

プロトタイピング[?]の実装。

擬似言語 Edit

[CGIから呼ばれて…]

  1. URLクエリーを得る。
  2. POSTされたデータを得る。
  3. クッキーを得る。
  4. セッションデータを復元する。
    1. クッキーにあるセッションIDを得る。
      セッションIDを使って、ファイルからセッションデータを復元する。
  5. セッションデータを更新する。
    URLクエリー、POSTされたデータ、クッキーをセッションデータに格納。
  6. フレームワーク/WikiEngineを呼ぶ。
  7. セッションデータをファイルに保存する。
    ファイル名はセッションIDによる。
  8. 出力にクッキーを付加。
  9. 出力。

Perl Edit

code*:357