シリーズ「ZendにおけるMVC(Javaフレームワークとの違い)」の続き
前回は、Zendの画面構成を書きました。
で、そこでの問題点として、
つまり、入力内容の判定をする前に、次の画面の行き先を指定する・・・ということは無茶なので(入力値を元にDBを検索して次の画面遷移が決まることもある。会員のランクによって画面が違うようなケース)、何とかしたい。この問題解決方法について考えるのが、今日の御題
■問題点と解決策について
結局、イベント処理部分と次の画面遷移が分離してないことが問題なので、
無理やり分離する。
その場合、次の画面名(コントローラー名)がわかっていないと書けない。
こんな規則を導入する。
そして、画面でボタンをクリックすると、イベントが発生する。
このとき起動されるアクションは、Formタグのactionで指定されることになる。
こうすると、きれいにいく。
■サンプル
今、2つの画面がある。
・はじめに、この画面が表示される。
これを、画面名indexとしよう
そして、この画面のボタンを、kotaeという名前にする。
・上記の画面のボタンが押されると、この画面が表示される。
これを、画面名ansとしよう
そして、この画面のボタンを、topという名前にする。
■規約を適用した場合のサンプル構成
画面index,ansそれぞれに、コントローラーをつくり、
画面をindex.phtmlに書く、
すなわちViewは、index/index.phtmlとans/index.phtmlの2つ
コントローラーは、IndexController.phpとAnsController.phpの2つで、
indexActionと、ボタンに対するactionができる。
そうすると、ファイル構成としては、こんな感じになる。
具体的な、ファイルの中身などは、次回以降にみていく。
前回は、Zendの画面構成を書きました。
で、そこでの問題点として、
例えば、現在表示している画面が、index/index.phtml画面だったとする。 この中のフォームタグのactionの指定が、 ans/kotae だったとすると、 AnsController.phpのAnsControllerクラス内のkotaeメソッドが呼ばれ、 次に表示される画面は、 ans/kotae.phtml となる。 |
つまり、入力内容の判定をする前に、次の画面の行き先を指定する・・・ということは無茶なので(入力値を元にDBを検索して次の画面遷移が決まることもある。会員のランクによって画面が違うようなケース)、何とかしたい。この問題解決方法について考えるのが、今日の御題
■問題点と解決策について
結局、イベント処理部分と次の画面遷移が分離してないことが問題なので、
無理やり分離する。
|
その場合、次の画面名(コントローラー名)がわかっていないと書けない。
こんな規則を導入する。
|
そして、画面でボタンをクリックすると、イベントが発生する。
このとき起動されるアクションは、Formタグのactionで指定されることになる。
|
こうすると、きれいにいく。
■サンプル
今、2つの画面がある。
・はじめに、この画面が表示される。
これを、画面名indexとしよう
そして、この画面のボタンを、kotaeという名前にする。
・上記の画面のボタンが押されると、この画面が表示される。
これを、画面名ansとしよう
そして、この画面のボタンを、topという名前にする。
■規約を適用した場合のサンプル構成
画面index,ansそれぞれに、コントローラーをつくり、
画面をindex.phtmlに書く、
すなわちViewは、index/index.phtmlとans/index.phtmlの2つ
コントローラーは、IndexController.phpとAnsController.phpの2つで、
indexActionと、ボタンに対するactionができる。
そうすると、ファイル構成としては、こんな感じになる。
|
具体的な、ファイルの中身などは、次回以降にみていく。