フレームワーク/Webアプリケーションの実装案。
やること †
フレームワーク/Webアプリケーション †
- -
これから考えること †
フレームワークの役割をフレームワーク/Webアプリケーションとフレームワーク/WikiEngineで分担。
MVC †
ユースケース †
ユースケースは機能拡張の中にもあるクラス。
プラグインの呼び出しに権限判定を付けるならユースケースクラスも必要。
ユースケース内で権限判定をするのでページを扱うということ。ページの扱いはフレームワーク/WikiEngineでやること。
→ユースケースはフレームワーク/WikiEngineでもある。
:i/ユースケーススコープ †
Controller = Usecase
その中だけで有効なデータ。
クライアントからのリクエストを処理 †
リクエスト †
†:i/クラス別のセッションデータ
:i/ユースケースチェイン[?] †
†:i/選べるビュー[?]
リクエストとレスポンスの分離。
…を一般化して複数のユースケースを連鎖させられるように。
変形MVC †
docs.google.com
設定方法を用意 †
:i/Webアプリの設定はWikiページに書けない †
エラー対処 †
:i/リクエスト再送はフレームワークで †
利用者の情報損失を防ぐ。リトライ可能に。使いにくくなるのを防ぐ。
:i/エラーメッセージにクラス名 †
:i/エラーページにクエリーを †
HTTPのGETメソッドのときは…URLをデコードして表示するなら意味がある。
セッションの用意 †
ページ/要素その他が扱うセッションを用意。
最適化 †
メモ化 †
多段メモ化。
リクエストとレスポンス †
全てURIで †
ページ名と要素部分はフレームワーク/WikiEngineでやること。
それ以前のドメインとWikiの指定までを受け持つ。
ここで行うのはそれ以前まで。
フレームワーク/WikiEngine呼び出し †
リクエストをフレームワーク/WikiEngineに渡す。
リクエストをフレームワーク/WikiEngineに渡す †
レスポンス †
ログイン→HTTP_REFERERにリダイレクト †
ログイン後はHTTP_REFERRERのページへ。リファラーが同一ドメインでないなら既定のURIへ。 → :i/フレームワークの実装案
:i/フレームワーク/WikiEngineからの出力をレスポンスにする †
認証 †
ログイン/ログアウト †
オープン認証なんかはWikiEngineよりもこちらで。→WikiEngineは外からユーザーオブジェクトを受け入れることになる。
ログアウトも?
認証とユーザーオブジェクトの用意 †
ユーザー認証をして、認証済みユーザーオブジェクトを作る。作るのと破棄だけ。
一般的な情報…IDやパスワードはある。その他の内容はフレームワーク/WikiEngineが与える。内容がページになっているので。
:i/アカウントの有効期限 †
ユーザーオブジェクトの用意 †
認証済みユーザーオブジェクトを作る。作るのと破棄だけ。
内容はフレームワーク/WikiEngineが与える。内容がページになっているので。
:i/アカウントの有効期限 †
セッションの維持・管理 †
その他、実装上の細かいこと †
フレームワーク/WikiEngineの実装案より †
WikiEngineではなくこちらで。
セッションを用意。
ページ/要素その他からのアクセスに応える。
エラー対処 †
- ログイン→HTTP_REFERERにリダイレクト
- アクセスログはページに残す
→フレームワーク/Webアプリケーションのログファイルと、フレームワーク/WikiEngineのページに残すログは別。
5xx Internal Errorの対処も。
:i/疑似言語とPerlでフレームワーク[?] †
:i/リクエスト再送はフレームワークで †
利用者の情報損失を防ぐ。リトライ可能に。使いにくくなるのを防ぐ。
:i/エラーメッセージにクラス名 †
:i/エラーページにクエリーを †
HTTPのGETメソッドのときは…URLをデコードして表示するなら意味がある。
:i/出力の統合はどうやるか?[?] †
フレームワーク/WikiEngineから呼ばれて †
設定 †
:i/Webアプリの設定はWikiページに書けない †
ログ †
- アクセスログはページに残す
フレームワーク/Webアプリケーションのログファイルと、フレームワーク/WikiEngineのページに残すログは別。
→ :i/フレームワークの実装案
最適化 †
メモ化 †
ページ/要素それぞれでメモ化すればいいのでは??