引き続きPiece Frameworkについて
昨日書いたPiece Frameworkの作者は
iteman's blog
ここの人だったのか。
そんでNet_UserAgent_Mobileの作者だったのか。
そういえば何ヶ月か前に知り合いがPieceの作者と話したとか言ってた。めっちゃ聞き流してしまった。気さくな人だったとか。
前は画面遷移の把握をどうするかに悩んでた。
http://d.hatena.ne.jp/katase_n/searchdiary?word=%b2%e8%cc%cc%c1%ab%b0%dc
こんな風に。
コメントの
あらゆる処理は、登録・確認・実行なんて流れではなくて、
いきなり実行でも問題がないようになっていなければいけません。
この意見は古い？いきなり実行を不許可とするのが（Web限定ではなくて）一般的なアプリの動作じゃないかな。
ということで有限状態マシンというやつが何なのか知りたいんだが・・
http://piece-framework.com/docs/piece-framework-workshop3.pdf
うーん。オートマトンのことなのかな？それなら話は早い。
http://www-06.ibm.com/jp/developerworks/java/060412/j_j-cb03216.shtml
この辺も見ながら・・。
有限オートマトン - Wikipedia
決定性有限オートマトン - Wikipedia
うん、有限状態マシンと有限オートマトンは同じ意味になってるな。有限状態マシンの方が一般的なのかな？初めて聞いた。
図でオートマトンを書くのは分かり易くて良いんだけど、テキストだと分かり難いような気がする。
状態遷移の記述の仕方が思い付かなくて保留にしていたんだな確か。あと他のPHPフレームワークでの実装例が無かったのも大きいか。画面遷移の状態を持ち続けることが良いのか悪いのか判断できかなかった。
しかし画面遷移を管理したからと言って、例えば確認画面後の実行画面で入力チェックを省けるかというと、そんなことはない。確認画面に表示中の情報は絶対的なものだから。
- ユーザがネットショップの注文確認画面で新規ウィンドウを開いたとする
- そこで新たな商品を追加する
- しかし「やっぱり買うのやめよう」と思ってウィンドウを閉じる
- その後既に開いている確認画面でSubmitを行う
このとき、最も理解しやすい動作は何か。それは確認画面で表示中の情報のみ確実にコミットされることだ。という考え。だからオートマトンが保持している状態ではなくて表示中の画面のhidden要素を使っていきなり途中の処理から動作を再開させることも必要だ。
こういう動作を考えると状態遷移の管理は難しいんだよなー。そしてオートマトンの基礎を知らない人でもすらすら開発できるのかが私には分からない。
ということで、まだ保留。。
http://piece-framework.com/2006/10/post_11.html
これなんか普通のPHP開発者は分かるのかな。それに必須項目が多いなぁ。YAMLやXMLを使わないと書けないデータ構造を頭の中に入れるのも大変だ。
画像←→設定ファイル という変換が自動で出来ればかなり便利そうだがテキストで状態遷移はどうなんだろう。。
でも従来の有限オートマトンに対するエラー検出ツールを使えたら利点は大きいな。授業中にWebでも使えないかなーと考えてたけど・・詳細は忘れてしまった。
http://d.hatena.ne.jp/perezvon/20060903/1157290812
メモ。
http://d.hatena.ne.jp/perezvon/20060908/1157737973
あとこれを作らなきゃ。
今は
{outputJsonData}とだけ書いたテンプレートファイルを用意するというまどろっこしいことやってるからなぁ。。
でもこれってmapleとかでも普通に出来るんじゃないだろうか？自分のフレームワークでも出来る。エントリポイントを二つ作るのが嫌だから、ビューの生成を遅らせてアクションに対する設定で変更できるようにしよう。前はアクション終了後にビューを生成してたのにリファクタリングを繰り返してるといつの間にか初めの方で生成するようになっていた。。
