【PHP】フレームワークについて語るスレ【総合】

1 名前：nobodyさん [2005/08/10(水) 02:21:08 ID:CBjrwwHd] ※フレームワーク Phrame本家 phrame.sourceforge.net/ Mojavi Project www.mojavi.org/ mojavijapan mojavi.p0t.jp/ Agavi本家 agavi.org/ Agavi.JP agavi.jp/ [ 日本発 ] Maple Project kunit.jp/maple/ [ 日本発 ] Ethna -PHPウェブアプリケーションフレームワーク- ethna.jp/ethna-tutorial-startup-practice1.html ※関連スレ 【PHP】フレームワークMapleに舌鼓 pc8.2ch.net/test/read.cgi/php/1122105465/ 【PHPフレームワーク】Ethna【スケルトン自動作成】 pc8.2ch.net/test/read.cgi/php/1123070439/ PHPでオブジェクト指向プログラミング pc8.2ch.net/test/read.cgi/php/1113724557/ その他>>2-5参照汁 750 名前：nobodyさん mailto:sage [2005/12/07(水) 23:50:26 ID:???] >>749 英語のプレゼンだからサッパリわからんが PHPをﾋﾟｨﾁﾋﾟｰと発音することは分かった 751 名前：nobodyさん mailto:sage [2005/12/07(水) 23:53:53 ID:???] ははは もれもそれ思ったよ！これからﾋﾟｨﾁﾋﾟｰって言おう！ 752 名前：nobodyさん mailto:sage [2005/12/08(木) 06:40:50 ID:???] >749 これっていつごろできるの？ 753 名前：nobodyさん mailto:sage [2005/12/08(木) 08:49:04 ID:???] けっこうagaviに似てる気がする 754 名前：nobodyさん [2005/12/08(木) 18:17:58 ID:v7tgLnK2] >>741 じゃあdispatchからのforwardってなんなの？ 755 名前：nobodyさん mailto:sage [2005/12/08(木) 18:25:17 ID:???] >>754 「転送する」とか「回送する」とかの意味があるから、「処理をまわす」と いう意味合いじゃないの？ つか、ここは英語のスレじゃないんだが。 756 名前：nobodyさん mailto:sage [2005/12/08(木) 22:50:03 ID:???] Zendフレームワークっていつリリースか明記してある？ 757 名前：nobodyさん mailto:sage [2005/12/08(木) 23:13:00 ID:???] ±1.5ヶ月でね 758 名前：nobodyさん mailto:sage [2005/12/09(金) 12:10:21 ID:???] >>749 プレゼンが下手糞で途中で飽きた。 文章でまとまってるのないの？ 759 名前：nobodyさん mailto:sage [2005/12/09(金) 12:21:49 ID:???] 流行りだからって何でもかんでもPodcastすればいいってもんでもないよね｡ テキストなら大事なとこだけ拾い読みできるのに｡ 760 名前：nobodyさん mailto:sage [2005/12/09(金) 12:43:07 ID:???] メディアを云々する前にまずGoogleを覚えようぜ 761 名前：nobodyさん mailto:sage [2005/12/09(金) 14:16:53 ID:???] 誤爆ですか？ 762 名前：nobodyさん [2005/12/09(金) 17:59:40 ID:kJFA21a1] Decorator使ってる時にリダイレクトしたら、 サブテンプレート作成中に処理がブチギレるよね。 ポストフィルタでリダイレクトすべきなのか。 そのあたりどうしてる？ 763 名前：nobodyさん mailto:sage [2005/12/10(土) 14:39:54 ID:???] 質問です。 mojavi2でSmartyを使っています。 XOOPSのテーマを使っていてsmartyのデリミタが<{と}>です。 $lblocks = array(array('title' => 'エラー', 'content' => '<div><{$error}></div>')); $renderer->setAttribute('xoops_lblocks',$lblocks); すると<がサニタイズされて>に変換されて、html上表示されてしまいます。 サニタイズさせない方法ってあるでしょうか? 764 名前：nobodyさん mailto:sage [2005/12/10(土) 19:34:26 ID:???] >>763 $smarty->left_delimiter = '<{'; $smarty->right_delimiter = '}>'; てか、、マニュアル嫁 765 名前：nobodyさん mailto:sage [2005/12/10(土) 23:53:59 ID:???] >>764 >>763の >XOOPSのテーマを使っていてsmartyのデリミタが<{と}>です。 とあるように、その設定はXOOPSのテーマを使うために既にしています。 そのために<と>がサニタイズされて困っているんです。 その設定をしなければ、{と}だけで問題ないのです。 テーマ側に<{$error}>と書けば問題ないのですが、setAttributeで渡そうとすると サニタイズされてしまいます。 766 名前：764 mailto:sage [2005/12/11(日) 01:36:43 ID:???] >>763 >smartyのデリミタが<{と}>です。 これ読めてなかった…　すまん、763 767 名前：762 mailto:sage [2005/12/11(日) 11:51:35 ID:???] リダイレクト後にexitしてるのが問題だっただけだった。 リダイレクトっていっても ヘッダに出力するだけで、 処理が止まるわけじゃないんだよな。 768 名前：nobodyさん mailto:age [2005/12/12(月) 19:50:27 ID:???] mojavi3つかってます。 modelで$this->getContext()->getRequest();するのと、 actionで$this->getContext()->getRequest();してモデルに渡すのと どっちがmvc的に正しいですか？ 769 名前：nobodyさん mailto:sage [2005/12/12(月) 20:44:06 ID:???] >>768 モデルはコントローラやビューと結合していないのが理想なので、action で リクエストを取得して、それに応じて model に渡すのがよいと思う。 770 名前：nobodyさん mailto:sage [2005/12/12(月) 20:44:31 ID:???] 「結合してない」って言い方は悪いな。「疎結合」に言い替える。 771 名前：nobodyさん mailto:sage [2005/12/12(月) 20:44:42 ID:???] >>768 前者の方がmodelとactionの結合が疎になりやすい。 772 名前：768 mailto:sage [2005/12/12(月) 21:33:07 ID:???] どうもありがとうございました。 さっぱりしました。 773 名前：nobodyさん mailto:sage [2005/12/12(月) 23:43:46 ID:???] >>769 えええええええええええ？ だったらなんでmodelに $this->getContext()->getRequest(); できる機能わざわざつけてあるのさ。 actionもMVCのmodelに相当するんじゃないの？ model内で $this->getContext()->getRequest();とかやって、 actionでgetModelするのが普通だと思うが。 >>772よ。すっきりするのはまだ早い 774 名前：nobodyさん mailto:sage [2005/12/12(月) 23:50:24 ID:???] moja3て、Modelがあんだ〜 class HogeModel extends Model って感じ？ 775 名前：nobodyさん mailto:sage [2005/12/13(火) 00:06:36 ID:???] >>773 > actionもMVCのmodelに相当するんじゃないの？ 違うよ。controllerとmodelのアダプタ（アダプタパターンとは別の意味）。 controllerの一部をコマンドパターンとして抽出したとも見れる。 だから本当はactionはビジネスロジックを書くところじゃないんだけど、ロジックもそのまま書けてしまう手軽さは利点であり欠点でもあると思う。 requestをいじるのはcontrollerであるべきだと思うから俺はaction内でgetRequestして、相応のmodelを呼び出す派。 776 名前：768 mailto:sage [2005/12/13(火) 01:51:59 ID:???] やっぱり、model内で $this->getContext()->getRequest(); のはなんか気持ち悪い。 777 名前：nobodyさん mailto:sage [2005/12/13(火) 01:56:13 ID:???] 俺もactionでrequest派。 最初はmodelでやっていたが そうなると、起点となるactionを見ただけでは どんなパラメータをいじっているのかが分からず、 流れを把握しにくくなったから。 またリクエストパラメータはどちらかといえば プレゼンテーション層に属するものなので プレゼンテーション層であるactionで受け取るのが理にかなっている とも思う。 バリデーションやコンバートはactionでやってるんだから ノータッチでmodelに渡していても疎結合とは言えないのでは？ むしろactionで受け取ってmodelに渡すというレイヤパターンにした 方が疎結合といえる気がする。 778 名前：nobodyさん mailto:sage [2005/12/13(火) 10:18:09 ID:???] model で request 処理すると，model の unit test がやり辛くなると思う それって context と request の両方を外部に依存することになるし action で request を処理しちゃえば model は request の「値」のみに依存することになり より疎結合になる # なんてことを周囲に喋ると「日本語喋れ」とか言われる罠ｗ 779 名前：nobodyさん mailto:sage [2005/12/13(火) 11:29:59 ID:???] 記述が楽＝疎結合じゃないんだよね プロトコルを増やすわけだからむしろ記述は面倒くさくなりがち 780 名前：nobodyさん mailto:sage [2005/12/13(火) 14:13:53 ID:???] >>773 フレームワークが許容しているのと、理想的な設計との間には 隔たりがあるってことを理解するべき。 元の質問は > どっちがmvc的に正しいですか？ ‥なので、MVC 的には action に依存しない方が理想だろうね。 >>778 のいう「unit test がやり辛い」ってのは、model がフレームワークと 密接に結合していて使い勝手が悪い証拠。結合度が高いので、再利用しずらい (再利用する時に、間接的にフレームワークにも依存することになる)。 model と action を分離しておけば、例えば、Web アプリとは別に DB に対する バッチ処理を PHP で書く必要がでてきた時に model を流用できる。 ただ、理想的な設計が、即座に現場で適用されるべきかというと、それは また別問題だけどな。 781 名前：nobodyさん mailto:sage [2005/12/13(火) 18:51:28 ID:???] >>780 いや、疎結合とかはlib側で考えるもんなんじゃないの？ ＞フレームワークが許容しているのと、理想的な設計との間には ＞隔たりがあるってことを理解するべき。 許容じゃなくて、意図的に実装してるんだとおもうんだけど。 modelは明らかにactionと密接な連携を取るためのものだと思うし。 ＞model と action を分離しておけば、例えば、Web アプリとは別に DB に対する ＞バッチ処理を PHP で書く必要がでてきた時に model を流用できる。 その流用はlibでつくったもののがやりやすいよね。 782 名前：nobodyさん mailto:sage [2005/12/13(火) 18:54:29 ID:???] >>777 自分は逆にactionはどんなmodelを使ってるかの道しるべとして使ってるから 流れ把握は全然困らない。てかむしろしやすい。 783 名前：nobodyさん mailto:sage [2005/12/13(火) 18:59:51 ID:???] てか、そもそもlibの存在忘れて疎結合とか言ってない？ 784 名前：nobodyさん mailto:sage [2005/12/13(火) 19:08:07 ID:???] libって何さ、ライブラリ？ 785 名前：nobodyさん mailto:sage [2005/12/13(火) 19:10:01 ID:???] なにこの流れ。 スゴいお勉強になるんだけお。 786 名前：nobodyさん mailto:sage [2005/12/13(火) 19:11:38 ID:???] >>780の言う「許容」ってのはModel内で$this->getContext()->getRequest()できちゃうって話だよね？ >>781と微妙に噛み合ってないみたいだけど。 つーかMojaviに関して言えばContextに一貫性を持たせようとした結果、たまたまModelの中でもRequestが取得できてしまうとも見れると思う。 その意味ではMojaviの欠点の一つかもしれんな。 まあ>>773から反論がない限りはgetRequestはActionでやるべきってのは満場一致でしょ。 その結論に至る思考プロセスが個々人いろいろなのがおもしろいなｗ 787 名前：nobodyさん mailto:sage [2005/12/13(火) 19:18:52 ID:???] >>786 ん？かみ合ってないのか？ ＞つーかMojaviに関して言えばContextに一貫性を持たせようとした結果、たまたまModelの中でもRequestが取得できてしまうとも見れると思う。 つまり、Requestだけはmodelでやるべきではないってこと？getControllerやgetUserはありで？ だったらかみ合ってないてのはわかるんだけど。 >>784 いや、libはautoloadで定義するやつよ。 こいつにこそ疎結合を求めるもんだとおもうんだけど… 788 名前：nobodyさん mailto:sage [2005/12/13(火) 19:21:40 ID:???] >>786 ちなみにlibとmodelはどう区切ってる？ 789 名前：nobodyさん mailto:sage [2005/12/13(火) 19:34:56 ID:???] M2のactionChainがなくなったのも、デコレータだけじゃなくgetModelが 追加されたからなんだと思うし… 790 名前：786 mailto:sage [2005/12/13(火) 19:40:45 ID:???] >>787 いや、「かみ合ってない」って言葉が気に障ったなら気にしないでくれ。 疎結合の話に対してではなく、request云々の方で感じたこと。 > 許容じゃなくて、意図的に実装してるんだとおもうんだけど。 の部分ね。 modelとlibのどちらに疎結合を求めるかってのにはノーコメント。 俺の場合はlibにフレームワークのコンポーネントから外れた自分クラスとかは入れないんで。 多くはModelで、あとはSmartyの実装が微妙だったころに改造したViewとか。（最新バージョンがどうなってるのかはチェックしてない）。 > つまり、Requestだけはmodelでやるべきではないってこと？getControllerやgetUserはありで？ まあそういう風に見るとrequestとuserの非対称性が浮き彫りになるが、俺の場合は結果的にはそういう方針でやってるよ。 Modelの中でgetRequestを呼び出すのはせいぜいsetErrorするときだけだな。 >>788 前述の通り、俺的には「区切ってる」っていう感覚ではあまりない。 共通して使うものをlibに入れるだけ。 791 名前：nobodyさん mailto:sage [2005/12/13(火) 19:51:24 ID:???] フレームワークだから ある程度の自由度を残してるのは当然ともいえるし どっちもｱﾘっちゃｱﾘだな。 792 名前：nobodyさん mailto:sage [2005/12/13(火) 19:54:09 ID:???] >>790 なるほど、そういうことね。確かに勘違いだわ。 でも、 ＞まあそういう風に見るとrequestとuserの非対称性が浮き彫りになるが、俺の場合は結果的にはそういう方針でやってるよ。 getUserもmodel内で使ってるんだ？ ますますわからんくなってきた… ちなみに forum.mojavi.org/index.php?showtopic=1280&hl=getmodel ここにあるようなソースはアリなんだよね？ 793 名前：nobodyさん mailto:sage [2005/12/13(火) 19:56:03 ID:???] context自体を渡すことがおかしいって言ってるのかと勘違いしてた。 794 名前：nobodyさん mailto:sage [2005/12/13(火) 19:59:28 ID:???] どっちにしても、自分の場合、actionはアダプタじゃなくてmodelで、 action内が複雑になりそうなときmodelに助けを求めるって感じでやってるから。 例えmodel内でgetRequestしても自然なつもりなんだけどなぁ 795 名前：768 mailto:sage [2005/12/13(火) 20:11:31 ID:???] じつはagaviでした。 agaviだとみんな食いついてくれないと思ったので. 結果予想以上に皆さんの意見が聞けてよかった。 796 名前：nobodyさん mailto:sage [2005/12/13(火) 20:13:34 ID:???] >>792 うーん、そこのソースのマズイ部分ってとりあえずどこ？ｗ つーかgetUserをModelでやるのっておかしいかな？言われてみると少し迷うな。 ログインの処理をする専用のModelとかそのままsetAuthenticatedしてるのと、あとはaddCredentialみたいなのもModelの中でちらほらやってしまっている。 もろにビジネスロジックかと思うんだが。 >>794 まあどういう風にやっても間違いってことはないと思う。 Actionにビジネスロジックを書いても結果的には「ロジックとデザインの分離」っていう大元の目的は達成されてるわけだし。 797 名前：nobodyさん mailto:sage [2005/12/13(火) 20:28:15 ID:???] >>795 みなさんというか、２、３人だと思うけどね。自分含めてｗ 798 名前：nobodyさん mailto:sage [2005/12/13(火) 20:31:02 ID:???] >>797 まーこの板はそういうとこだよなｗ 799 名前：nobodyさん mailto:sage [2005/12/13(火) 20:34:29 ID:???] >>796 ＞うーん、そこのソースのマズイ部分ってとりあえずどこ？ｗ その感想自体が答えですｗ　さんきゅｗ ＞ログインの処理をする専用のModelとかそのままsetAuthenticatedしてるのと、あとはaddCredentialみたいなのもModelの中でちらほらやってしまっている。 まぁたしかにgetUserはその辺の機能があるからね。言われれば気持ちはわかる。 ちなみに開発人数はどれくらい？ 自分のとこの場合人数が5人で中途半端だから、下手に縛り設けようにもうまく機能しないことが多いんだよね… フレームワークで許されている権利は使ってよしってことにしてるからってのもあるかも。 800 名前：nobodyさん mailto:sage [2005/12/13(火) 20:35:06 ID:???] userをmodelでいじるのは全然おかしくないと思う つまるところセッションだし。 requestはブラウザから直接送られてくるデータだから、 いきなりmodelにいじらせるには生々しすぎる感じがするな。 801 名前：nobodyさん mailto:sage [2005/12/13(火) 20:40:49 ID:???] >>800 いや、それだと話がループする… 802 名前：nobodyさん mailto:sage [2005/12/13(火) 20:42:35 ID:???] >>800 そこはmodelで疎結合かどうかの話でしょ？ 803 名前：nobodyさん mailto:sage [2005/12/13(火) 20:45:33 ID:???] >>800 ＞requestはブラウザから直接送られてくるデータだから、 おいおい大事なget,setAttributeはどこいった？ 804 名前：nobodyさん mailto:sage [2005/12/13(火) 20:53:12 ID:???] ひょっとして、getRequest＝ブラウザからのデータで話進められてたの？ 805 名前：nobodyさん mailto:sage [2005/12/13(火) 21:18:59 ID:???] ああ、attribute忘れてたw 内部パラメータとしてのattributeならmodelでいじってもおかしくはないよね viewに渡すためのコンテナとしてなら、 modelから受け取ってactionでこめこめするのがいいと思う 806 名前：nobodyさん mailto:sage [2005/12/13(火) 21:31:18 ID:???] modelでごにょごにょしたものはactionにいくのか？ それともviewか？ 807 名前：nobodyさん mailto:sage [2005/12/13(火) 21:38:24 ID:???] >>792-793 model に context が渡ってること自体が気に入らない。理由は >>796 の人が 述べてる理由が近いかな。 >>805 attribute も model じゃ触らない。ビジネスロジックはコントローラに封じ込 めるべきってのは大体の人が賛成してくれると思うけど、attribute を ビジネスロジックに一切関係ない使用例を見たことがない。もしあるなら 示してくれると、すごく嬉しい。 一般的(≒ Java の世界)にはそういう流れになってない？ モデルは POJO (getter/setter だけのオブジェクト) にして、必要に応じて AOP でDAO や O/R マッピングしなさい、と。 808 名前：nobodyさん mailto:sage [2005/12/13(火) 21:51:40 ID:???] Javaとは言語仕様も実際の使われ方も違うのに、StrutsやIBMのホワイトペーパーと無理にあわせてもしょうがない。 809 名前：nobodyさん mailto:sage [2005/12/13(火) 21:55:50 ID:???] >>807 ＞model に context が渡ってること自体が気に入らない。 えぇ？なんで気に入らないのに >>796の人と同意なの？ 根本的におかしいぞそれ。 810 名前：nobodyさん mailto:sage [2005/12/13(火) 21:56:59 ID:???] >>807 つまり、>>792のソースもおかしいってことだよね？ 811 名前：nobodyさん mailto:sage [2005/12/13(火) 21:58:05 ID:???] >>806 actionにいってからviewじゃない？ 直接viewにいくのはなんか気持ち悪いな >>807 Model=POPOなの？ そこまで疎結合にするならModelをextendsする意味がないような… 俺はModel≒ビジネスロジックという認識だった。 812 名前：nobodyさん mailto:sage [2005/12/13(火) 22:00:37 ID:???] 一般的ではなくm3やagaviで開発する上での話をしているので、 >>807の話はお門違いなわけだが 813 名前：nobodyさん mailto:sage [2005/12/13(火) 22:04:25 ID:???] mvc的に正しいのはって聞いてるんだから御門違いじゃないだろう 814 名前：nobodyさん mailto:sage [2005/12/13(火) 22:05:40 ID:???] まぁ、お門違いじゃないにしてもおかしなこと言ってるのは確かだな 815 名前：nobodyさん mailto:sage [2005/12/13(火) 22:17:24 ID:???] 807は モデルはフレームワーク自体からも疎結合である方がいいって意味だよね。 考え方は分からないでもないけど そこまで疎にする必要がはたしてあるのか… そもそもフレームワークを採用する時点で 全面的な依存を選択しているわけで、 モデルだけを疎結合することにどれほどの意味があるのか 816 名前：nobodyさん mailto:sage [2005/12/13(火) 22:17:28 ID:???] javaが一般的ってのも今は大分微妙になってるけどなぁ 817 名前：nobodyさん mailto:sage [2005/12/13(火) 22:19:09 ID:???] そもそもMVCモデルってそれぞれが密接に関連してるよなぁ 疎を考えるんなら777の言うようにレイヤーパターンで考えたほうが良いと思う MVCパターンをレイヤーパターンに置き換えると VCがプレゼンテーション層 Mがドメイン層とデータソース層 それぞれの層は独立していて別の層を知らないのが理想 actionはドメイン層とプレゼンテーション層の中間層かな？ だからactionは プレゼンテーションからの入力（リクエストパラメータ）を受け取る ドメインロジックを呼び出す パラメータをドメインロジックに渡す ドメインロジックでゴニョゴニョした結果をプレゼンテーションロジックに渡す こんな流れがいいんじゃないかなぁ 結論、mojaviのModelクラスはｲﾗﾈ 818 名前：nobodyさん mailto:sage [2005/12/13(火) 22:19:56 ID:???] >>815 あぁ、激しく同意… 多分agaviも>>815みたいな思想があってああいう設計になってるんだと思う。 819 名前：nobodyさん mailto:sage [2005/12/13(火) 22:23:54 ID:???] >>817 それだとactionがちょっとややこしくなっちゃわない？ 820 名前：nobodyさん mailto:sage [2005/12/13(火) 22:33:04 ID:???] >>815 >>817 おまいらユニットテストしないんですか？ >>819 むしろすっきりする actionにロジック書くわけじゃないからね あくまでAPIを呼び出して使うだけ mojavi的にはこんな感じ $id = $request->getParameter('id'); $service =　new HogeService(); $hoge = $service->getHoge($id); $request->setAttribute('hoge', $hoge); 821 名前：nobodyさん mailto:sage [2005/12/13(火) 22:34:10 ID:???] >>817 最後の結論だけ良く分からない Model＝ドメインロジックで問題なくね？ 822 名前：nobodyさん mailto:sage [2005/12/13(火) 22:36:37 ID:???] >>820 autoload.iniが大変なことになりそうだ。 823 名前：nobodyさん mailto:sage [2005/12/13(火) 22:49:29 ID:???] >>820 それってデータベースコネクションはどこでどうやって呼出してんの？ 824 名前：nobodyさん mailto:sage [2005/12/13(火) 23:00:01 ID:???] autoload.iniの項目が多いとやっぱり遅くなるの？ おれはできるだけ使わんやつは消しとるよ。 825 名前：nobodyさん mailto:sage [2005/12/13(火) 23:04:08 ID:???] >>821 概念的にはその通りだけど mojaviのModelクラスに依存したくないという意味でｲﾗﾈということです >>822 それすごく悩んだけど 自前のクラスローダーで解決したお >>823 DB接続用クラスをSingletonで作成してどこからでも呼び出せるようにしてるよ DB::getConnection()みたいな感じで といってもどこからでも呼び出してるわけじゃないけどね 826 名前：nobodyさん mailto:sage [2005/12/13(火) 23:55:30 ID:???] >>825 なんかもうそれ自分ルールだらけじゃん… まぁ別にそれが悪いわけではないけど 827 名前：nobodyさん mailto:sage [2005/12/13(火) 23:58:11 ID:???] >>825 ＞自前のクラスローダーで解決したお それはautoload側をいじったのか、ロード関数みたいなのつくったのか 828 名前：nobodyさん mailto:sage [2005/12/14(水) 00:01:27 ID:???] 結論 >>825のやってることは、agaviのmodelで解決。 無駄な作業乙 829 名前：nobodyさん mailto:sage [2005/12/14(水) 00:34:57 ID:???] もしかしてSingletonModelってクラス？ Singletonごときでなんであんなものに頼らなきゃいけないのか疑問・・・。 しかもグローバルに呼び出しできなくなるし 830 名前：nobodyさん mailto:sage [2005/12/14(水) 00:41:56 ID:???] PHPでシングルトンってほぼ無意味だよな。 831 名前：nobodyさん mailto:sage [2005/12/14(水) 01:27:53 ID:???] >>830 まあどちらかと言うと、インスタンス２つ以上作ろうとする方が頭どうかしてるもんな。 Controllerとか。 832 名前：nobodyさん mailto:sage [2005/12/14(水) 01:43:05 ID:???] >>830 リクエスト毎にオブジェクトが生成->破棄されるという意味では無意味だな。 ログとかＤＢコネクションとかでは使えるけど、それもグローバル変数に入れとけばいいみたいな。 833 名前：nobodyさん mailto:sage [2005/12/14(水) 01:44:31 ID:???] HTTPリクエスト単位で記憶が失われるPHPでは シングルトンって「グローバル変数のオブジェクト指向版」みたいな意味しかない気がする 実際に役に立つのはDB接続みたいなリソース使いまわしくらいって印象が…… 834 名前：nobodyさん mailto:sage [2005/12/14(水) 01:46:05 ID:???] >>824 クラスが必要なときのみ読みこむようにその設定があるんだし、そんなに気にしなくてもいいのでは。 まぁ少ないほうが早いに決まってるけど。 835 名前：nobodyさん mailto:sage [2005/12/14(水) 03:49:22 ID:???] >>825=>817 そこまで行くとMojaviの理念から外れてるし、それはもうmojaviから派生した>817のフレームワークであって、 とても「mojaviを使っている」とはいえないと思うが。 なのでmojavi(agavi)でMVCどうやるのか(requestをどう扱うか)っていう話においては参考にならない。 >>820 も同様 ただ、ユニットテストはMojaviの致命的な欠点だとおもう。 本題の"request"の扱いについてはModelはＣontrollerを知るべきではない、 そして"request"はControllerである。よって"request"は"Model"で扱うべきではない。 とおもうが。 実際はModelでしかたなくrequest呼び出したことありますごめんなさい。 設計が悪かった。反省してます。 836 名前：nobodyさん mailto:sage [2005/12/14(水) 06:37:08 ID:???] オブジェクトの依存性の話なのか設計上の規約も含めるのか判らん 837 名前：nobodyさん mailto:sage [2005/12/14(水) 06:44:24 ID:???] 誰か両方の意見をまとめてくり 838 名前：nobodyさん mailto:sage [2005/12/14(水) 07:15:24 ID:???] いや、なんか感動。 疑問は晴れてないけど。 839 名前：nobodyさん mailto:sage [2005/12/14(水) 10:23:55 ID:???] 図にしてみたぞ♥ 　　　　　　　Controller 　　　　　　　　　↓ 　Request ⇔ Action ⇔ Model ⇔ User,Database 　　　　　　　　　↓ 　　　　　　　Controller 　　　　　　　　　↓ 　Request ⇔　View　⇔ Model 　　　　　　　　　　　　　 | 　　　　　　　　　　　 ←｜→ 　　　プレゼンテー　　｜　　　ドメイン層、データソース層 　　　ション層　　　　　｜ 　　　　　　　　　　　　　 | 俺にとってActionとはControllerの一部であり、Requestの受付とModelの呼び出し以外のことはしない。 Action::executeすげーｼﾝﾌﾟﾙｳﾏｰ（AAry）。>>820、>>835と基本的に同じ。 俺にとってModelとはMojavi内で唯一ビジネスロジックを担当する部分である。 ちなみにModel以外はデータ層に触りません！ 840 名前：nobodyさん mailto:sage [2005/12/14(水) 11:25:24 ID:???] Modelはどうまとめてる？ 俺はOO的にうまいことまとまらない場合は 似たような関数をまとめてお茶を濁してる。 841 名前：nobodyさん mailto:sage [2005/12/14(水) 11:38:43 ID:???] >>839 Model にビジネスロジック入れたら駄目じゃん。話にならん。 842 名前：nobodyさん mailto:sage [2005/12/14(水) 11:44:42 ID:???] >>841 839じゃないけど 俺もModelはビジネスロジックを担当する部分という認識なんだが きみのいうModelって何？ 843 名前：839 mailto:sage [2005/12/14(水) 11:46:02 ID:???] >>840 たしかに関数の入れ物に過ぎないModelができちゃうこともあるかもｗ 俺の場合はSean KerrのAction::executeのコメントで、 * Execute any application/business logic for this action. * * In a typical database-driven application, execute() handles application * logic itself and then proceeds to create a model instance. Once the model * instance is initialized it handles all business logic for the action. * * A model should represent an entity in your application. This could be a * user account, a shopping cart, or even a something as simple as a * single product. っていうやつ（mojavi/action/Action.class.php）をけっこう意識しながらやってる。 Modelはentityを表すってのけっこうしっくりきてるかも。 つーか今読み返してみたら、Sean Kerr的にはActionでビジネスロジックもありっていうスタンスっぽいなｗ ただ、基本はModel＝ビジネスロジックでしょ。 844 名前：nobodyさん mailto:sage [2005/12/14(水) 12:08:56 ID:???] 訳： Actionに対するアプリケーションロジック・ビジネスロジックの実行をします。 よくあるデータベースを用いたアプリケーションでは、execute()の中でアプリケーションロジックを扱い、続いてModelのインスタンスを生成します。 Modelの初期化をしたら後はその中で全てのビジネスロジックを扱います。 Modelはアプリケーション内のエンティティを表すようにすると良いでしょう。 例えば、ユーザーアカウント、ショッピングカートであったり、時には個々の製品といったシンプルなものであることもあるでしょう。 845 名前：nobodyさん mailto:sage [2005/12/14(水) 12:12:22 ID:???] >>844 そうそう。 やっぱり841はビジネスロジックの定義を勘違いしてないか？ エンティティーのメソッドはすなわちビジネスロジックだし。 Model＝ValueObjectと勘違いしてる気がする。 846 名前：nobodyさん mailto:sage [2005/12/14(水) 14:28:05 ID:???] みんな言葉の定義が微妙に違ってるだけだと思う。 というか、レイヤとモデルを微妙に混同してるのかも。 ドメイン層のレイヤにビジネスロジックがあって、 そこで操作されるものがドメインモデル（エンティティ）。 これをそのまま実装に反映させるなら、 ドメインモデルとビジネスロジックは別クラスにするのが自然。 だけどケースバイケースで、ドメインモデルのクラスが ビジネスロジックのメソッドを持つ実装にするのもあり。 どちらがいいかは一概には言えないと思う。 >>845 それは違うよ。 ValueObjectはどちらかというとドメインモデルではなく プレゼンテーションモデル。 ドメインモデルをそのままプレゼンテーション層まで引きずってくる 設計方針ならValueObjectぽっく見えるかもしれないけど、 プレゼンテーションモデルをきっちりわける設計方針なら >>841の言ってるモデルはドメイン層で閉じてるはず。 847 名前：nobodyさん mailto:sage [2005/12/14(水) 15:10:04 ID:???] 俺定義で議論してないでPoEAAを読め、ってことだ。 848 名前：nobodyさん mailto:sage [2005/12/14(水) 16:18:44 ID:???] 高いから譲ってくれ 849 名前：nobodyさん mailto:sage [2005/12/14(水) 16:45:40 ID:???] O'ReillyのSafari Bookshelfに入れば$19.95で読めるよ。 850 名前：nobodyさん mailto:sage [2005/12/14(水) 17:12:47 ID:???] 日本語訳本買ったけど読んでねーや ValueObjectがプレゼンテーションモデルってどゆ意味？ 単に値を持たせるオブジェクトだから どんな層にでも入ってくる汎用的なパターンだと思うんだが 851 名前：nobodyさん mailto:sage [2005/12/14(水) 21:59:44 ID:???] > 単に値を持たせるオブジェクト 自説を立てるときはそれなりの手順を踏襲してほしい 852 名前：nobodyさん mailto:sage [2005/12/15(木) 02:19:59 ID:???] >>839 >>843を意識してるんなら、Actionはドメイン層、データソース層に入ることもあるだろ 853 名前：nobodyさん mailto:sage [2005/12/15(木) 02:23:24 ID:???] trac.agavi.org/trac.cgi/wiki/HowToSetupBasicAuthentication この公式サンプルも、全然>>839みたいな定義になってねぇし 854 名前：839 mailto:sage [2005/12/15(木) 03:13:21 ID:???] >>852 たしかにそうだね。それが > つーか今読み返してみたら、Sean Kerr的にはActionでビジネスロジックもありっていうスタンスっぽいなｗ と言った理由なんだけど。 ただ、俺自身はドメイン層の処理はModelでやる方針でやってるって話。 Actionでドメイン層・データソース層に手を出すのも利点があるなら大いに結構だとは思うよ。 >>853 えーっと一応言っておくけど>>839は設計（or実装）方針の話ね。 （それまでの議論の内容も多少加味したつもりなんだが偏見もあるかも・・・） あと、そこのサンプルは>>844の「ユーザーアカウント」にあたるものをModelとして抽出せずにActionで済ませちゃってるんだね。 だから839と違って見えるってのも無理はないかも。 まあロジックが複雑になってきたらそんなことは言ってられないので俺は認証用に作ったModelを再利用してるよ。 必要ならそのModelをもう一段継承してカスタマイズとかできるのでそこそこ便利だし。 855 名前：nobodyさん mailto:sage [2005/12/15(木) 03:28:55 ID:???] >>841に対して、はじめは何言ってるんだろうこの人…と、>>842と 同じ気持ちでしたが、 www.microsoft.com/japan/msdn/practices/type/Patterns/enterprise/DesMVC.asp ここを読んでみて>>841の言ってることがよくわかりました。 MVCの図にあるとおり ＞ビューとコントローラの両方がモデルに依存していることに注意してください。ただし、モデルはビューとコントローラのどちらにも依存していません。 モデルは両方に依存していないものなんだね。 そう考えるとたしかに>>839の言ってる図は話にならない。 でも、それを言い出すとAgaviの設計自体がおかしいことになるね。 856 名前：839 mailto:sage [2005/12/15(木) 03:51:45 ID:???] >>855 たぶんUMLを見慣れてる人が多いんだろうから誤解を与えたかもしれないけど、>>839は「依存関係」を表してるつもりじゃなかったんだなぁorz Controller→Action→Controller→Viewってのは制御が移る順番。 他の⇔はデータの受け渡しであって、基本的にはメソッドの呼び出し＋リターンなので制御が移る順番としても解釈できるかも。 >>855が依存関係の話を持ってきてくれたのでそれも考慮すると、⇔の矢印をすべて外側向きに変えたら少しはましになるかな？ 矢印の意味は ・依存してる側→依存されてる側 ・呼び出し側→呼び出される側 という関係で。（唯一Action→Controllerの部分だけリターンなので矢印の色でも変えてくださいｗ） 「ビジネスロジック」って言葉は俺も再考する必要があるかも。 >>846をもうちょっと咀嚼してみる。 857 名前：nobodyさん mailto:sage [2005/12/15(木) 03:53:25 ID:???] forum.mojavi.org/index.php?showtopic=1281 こういうの見るとますますわからんくなる… 858 名前：nobodyさん mailto:sage [2005/12/15(木) 04:01:35 ID:???] そこまでごちゃごちゃ深いこと考えなくても、 保守性の高いコードってWebアプリケーションなら結構つくれちゃうからなぁ… ビジネスロジック云々より、ビジネスや運営自体について考えてたほうがよっぽど金になる 859 名前：839 mailto:sage [2005/12/15(木) 04:09:49 ID:???] >>858 俺的もそう思う。どっちでもいーじゃんおまいらｗ、と でも「間違っている」というつっこみをたくさんいただいたので、ヘコみつつ悪戦苦闘中であります。 860 名前：nobodyさん mailto:sage [2005/12/15(木) 04:22:02 ID:???] >>855 マジでAgaviのView周りってModelに依存性あるの? ステートレスなWebアプリでは切り離されてるのが当たり前だと思ってたけど。 アクティブモデルにせよオブザーバはかませるっしょ 861 名前：nobodyさん mailto:sage [2005/12/15(木) 04:40:08 ID:???] View生成はクライアントリクエストのみを起点にしているから、 コントローラかアクションにぶらさげることは出来るね 前者はコントローラがMediator（と言ってもモデルかアクションから データを受け渡すだけ）となり、後者ではアクションはコマンドオブジェクト （ビジネスロジックとViewの呼び出しをカプセル化したもの）ということになる どっちもパターンとしてはMVCとは呼ばないんだろうけど www.martinfowler.com/eaaCatalog/applicationController.html Viewがモデルに依存したほうがいいかアクションに依存したほうがいいか まとまった見解ってある？ 862 名前：nobodyさん mailto:sage [2005/12/15(木) 04:43:36 ID:???] >>860 Agavi自体の仕様では依存性は発生しないよ。Modelは一つもなくても動くし。 でもModelを使った時点で依存はゼロではないと思われ。 「切り離す」ってのはいわゆる疎結合にするって意味だとは思うけど、元々依存してしまうものだからせめて疎結合にしましょうって感じじゃなかったっけ？ >>855の言ってるのは、逆向きの依存はゼロってことでしょう。 「Viewを変更したらModelが動かなくなりました」とかしゃれになんないし。 でもModelを変更したらViewに支障が出るのは仕方ない。 それでも最小限にしましょうってのが疎結合だと思う。 オブザーバはContextのことでおｋかな？ 863 名前：nobodyさん mailto:sage [2005/12/15(木) 05:25:53 ID:???] 依存性＝オブジェクトをNewするかパラメータに取ってメンバにアクセスすること 結合の程度というようなファジーなものは存在しない Framework界隈で依存性といったらこれのことだと思う 864 名前：nobodyさん mailto:sage [2005/12/15(木) 05:52:18 ID:???] > 結合の程度というようなファジーなものは存在しない 疎結合って結合の程度がゆるいことじゃないの？ つーかどのレスに対してなのか反論なのか何なのかわからんな。 865 名前：863 mailto:sage [2005/12/15(木) 06:11:06 ID:???] 直上に対するレス 結合にはもちろん程度があるよ しかし依存性にはそういうものは無くゼロイチだということを言ってみた >>860と>>862の愛でどうも考えている依存性が違って かみ合ってないように見えたので 866 名前：nobodyさん mailto:sage [2005/12/15(木) 06:12:18 ID:???] × 愛で ○ 間で すまん 間違ったものを芽生えさせた 867 名前：nobodyさん mailto:sage [2005/12/15(木) 06:12:22 ID:???] >>860 Modelにするにせよ別もんにしてつくるにしても、 初期のViewだけじゃなにもできんじゃん。 ごてごてタグとテンプレートと定数混ぜることになってしまう。 その辺のモデルもつくるでしょ？ふつう 868 名前：nobodyさん mailto:sage [2005/12/15(木) 06:16:08 ID:???] いや、Mojaviだとビジネスロジックの呼び出しはアクションあたりに集約するのが一般的だと思う ビュー内でモデルは呼び出したくない 869 名前：nobodyさん mailto:sage [2005/12/15(木) 06:20:08 ID:???] >>868 MVCはもともとそういうものだけどな。View - -> Model 870 名前：862 mailto:sage [2005/12/15(木) 06:21:54 ID:???] >>865 そかそか。曖昧な言い方ですまんかった。 基本的には「依存性はゼロイチ」ってのは同意だよ。 だから>>860への答えはViewからModelへの依存性は「あり」。 ただ「切り離されてるのが当たり前」って表現をしてたので、862で「それは疎結合のことであって≠依存性だよね」っていう意味で言った。 >>868 実際にはそうだよなｗ 871 名前：nobodyさん mailto:sage [2005/12/15(木) 06:23:49 ID:???] >>869 パッシブモデルね 872 名前：nobodyさん mailto:sage [2005/12/15(木) 09:58:57 ID:???] モデルをフレームワークから独立させる派は モデルからUserにアクセスする必要がある時はどうやってるの？ 873 名前：nobodyさん mailto:sage [2005/12/15(木) 10:10:17 ID:???] >>872 モデルはフレームワークに依存していない設計なので、 モデルから User にアクセスする必要がない。 874 名前：nobodyさん mailto:sage [2005/12/15(木) 10:21:58 ID:???] extends Modelすらしないってこと？ 875 名前：nobodyさん mailto:sage [2005/12/15(木) 10:26:14 ID:???] >>873 DBはどうしてる？ 876 名前：nobodyさん mailto:sage [2005/12/15(木) 11:14:48 ID:???] Mojavi系の場合DBみたいな下層にも入ってくるから フレームワークに依存しない設計がいまいちイメージしにくいな 877 名前：nobodyさん mailto:sage [2005/12/15(木) 11:38:55 ID:???] というか、一度 Mojavi を頭から追い出して一般的な設計の話をしろよｗ もうあんな設計は古いって…。 878 名前：nobodyさん mailto:sage [2005/12/15(木) 11:43:23 ID:???] 話変えたいなら自分から話題を提供すればいいのに 879 名前：nobodyさん mailto:sage [2005/12/15(木) 11:51:42 ID:???] スルーしとけ 880 名前：nobodyさん mailto:sage [2005/12/15(木) 11:55:01 ID:???] Mojaviはたたき台としてまだ価値あるだろ 影響受けてるフレームワークいっぱいあるしな 881 名前：nobodyさん mailto:sage [2005/12/15(木) 14:16:48 ID:???] rails!rails! 882 名前：nobodyさん mailto:sage [2005/12/15(木) 15:21:47 ID:???] PHP on TRAXときたか 883 名前：nobodyさん mailto:sage [2005/12/15(木) 21:48:05 ID:???] S2Baseがいいと思うんだけど、どう？ ValidateやらFilterは自作になるけど、結構いいと思う。 884 名前：nobodyさん mailto:sage [2005/12/15(木) 23:18:51 ID:???] S2PandNで出席者が質問してたが､S2やMapleのDIはどこまでパフォーマンスが出るか疑問｡ プロダクトとしてリリースするなら､自分のところできちんと性能評価をやった方がいいよ｡ 885 名前：nobodyさん mailto:sage [2005/12/16(金) 00:48:04 ID:???] もうMojaviでいいや。　 886 名前：nobodyさん mailto:sage [2005/12/16(金) 01:35:11 ID:???] S2をそのままPHPに移植してるのかな 887 名前：768 mailto:sage [2005/12/16(金) 09:02:11 ID:???] zend framework待とうよ！ 888 名前：nobodyさん mailto:sage [2005/12/16(金) 09:14:05 ID:???] 末広がりget, zuzaa 889 名前：nobodyさん mailto:sage [2005/12/16(金) 18:13:50 ID:???] Mojavi初心者なんですが エスパー募集してもよろしいでしょか？ 890 名前：nobodyさん mailto:sage [2005/12/16(金) 18:41:40 ID:???] >>889 ここは語るスレだ。質問はスレ違い。 891 名前：889 mailto:sage [2005/12/16(金) 18:51:08 ID:???] >>890 そうですか、失礼しました。(´･ω･｀) 892 名前：nobodyさん mailto:age [2005/12/17(土) 00:42:49 ID:???] POSTされたデータをDBへupdateする場合はmodelでするの？ 893 名前：nobodyさん mailto:sage [2005/12/17(土) 01:13:05 ID:???] >>890 多少質問あったほうが盛り上がるからいいんで内科医？ >>892 基本的にvalidationはactionでやり、DBの扱いはmodelでやってるけど、このスレ読んでたらもしかしたらactionでやったほうがいいのかな？とも思えてきた。 894 名前：nobodyさん mailto:sage [2005/12/17(土) 01:30:36 ID:???] >>893 エスパー募集な質問でもか？ 895 名前：nobodyさん mailto:sage [2005/12/17(土) 01:39:26 ID:???] あー、エスパー募集はよろしくない罠ｗ 896 名前：nobodyさん mailto:sage [2005/12/17(土) 01:50:31 ID:???] >>892 modelを作るほど複雑でなく(単なるログとか)、 また他のアクションで同じ機能を利用しないならアクションで済ませてしまってもいいとは思う。 897 名前：nobodyさん mailto:sage [2005/12/17(土) 02:02:35 ID:???] >>896 modelでDBに登録するとしたらサニタイズもmodelでやるってことになる？ でないとmodelがactionに依存してしまう気がするんだけど。 898 名前：nobodyさん mailto:age [2005/12/17(土) 09:32:09 ID:???] そしたら サニタイズはactionでやるべきだね。 899 名前：nobodyさん mailto:sage [2005/12/17(土) 09:36:15 ID:???] アクション前にフィルタ処理は済んでるはず モデルは自身のためのサニタイズは自身で持つ いずれも定義は括りだす 900 名前：nobodyさん mailto:sage [2005/12/17(土) 09:39:35 ID:???] インプットフィルター → アクションDeバリデーション → モデルサニタイズ てことか。 実際どこで何をやるんだろ。 901 名前：nobodyさん mailto:sage [2005/12/17(土) 10:04:30 ID:???] つーかModelでDBに書き込む場合、フィルタでサニタイズするのもおかしいじゃん。 てことはActionでDBに書き込むのが正しい？ 902 名前：nobodyさん mailto:sage [2005/12/17(土) 10:55:36 ID:???] ありえなす 903 名前：nobodyさん mailto:sage [2005/12/17(土) 11:29:14 ID:???] 俺はmodelからdbクラスいじってやってるけど。 904 名前：nobodyさん mailto:sage [2005/12/17(土) 12:05:30 ID:???] mojaviの質問はどこですればいい？ 905 名前：nobodyさん mailto:sage [2005/12/17(土) 12:12:34 ID:???] ここですればいいよ 答えが返ってくる時もあれば返ってこない時もあるけど 906 名前：nobodyさん mailto:sage [2005/12/17(土) 13:19:27 ID:???] >>904 あなたの質問がこのスレの命運を決めるかもしれません。 慎重に質問してください。 907 名前：nobodyさん mailto:sage [2005/12/17(土) 13:24:57 ID:???] 何のプレッシャーだよw 908 名前：nobodyさん mailto:sage [2005/12/17(土) 19:16:29 ID:???] おい、agaviのサイトがエラーですよ！ www.agavi.org/ 909 名前：nobodyさん mailto:sage [2005/12/17(土) 20:58:41 ID:???] >>908 多分5.1にしたんじゃないか 910 名前：nobodyさん mailto:sage [2005/12/17(土) 21:00:06 ID:???] >>908 多分PHP5.1に変えたんだろ timezone関係の警告でてるし 911 名前：nobodyさん mailto:sage [2005/12/17(土) 22:24:03 ID:???] バージョン上げてからチェックしないとはアホもいいとこだなｗ 912 名前：nobodyさん mailto:sage [2005/12/18(日) 03:06:20 ID:???] >>911 逆だろ チェックしてからバージョン上げないなんてアホもいいとこだなｗ 913 名前：nobodyさん mailto:sage [2005/12/18(日) 03:09:01 ID:???] まあフレームワークのサイトが 危機管理意識なしでエラーメッセージ垂れ流しっていうのは あまりよろしくないよなぁ。 そもそも確認すらしないのかと。 914 名前：nobodyさん mailto:sage [2005/12/18(日) 06:17:14 ID:???] あれ、こんなエラー自分の環境じゃ出なかったのに 915 名前：nobodyさん mailto:age [2005/12/18(日) 09:07:58 ID:???] isSecure() return true と filters.iniで以下設定 [BasicSecurityFilter] class = "BasicSecurityFilter" param.comment = "On" と挙動が違う。 filters.iniで設定すると、controllerの$this->loadModuleFilters($filterChain); でBasicSecurityFilterがregistされ BasicSecurityFilterクラスの$controller->forward(LOGIN_MODULE, LOGIN_ACTION); でLOGIN_MODULEのフォワード無限ループになります。 ozaki.kyoichi.jp/mojavi3/authfilter.html ここのサイトではちゃんとできているようだけど、 同じようなトラブルにあっている方はいますか？ 916 名前：nobodyさん mailto:sage [2005/12/18(日) 11:43:36 ID:???] そのドキュメントは古いよ BasicSecurityFilterの使用はsettings.iniのUSE_SECURITYで決定する filters.iniに設定する必要はないよ 917 名前：nobodyさん mailto:sage [2005/12/18(日) 14:07:02 ID:???] o 918 名前：nobodyさん mailto:age [2005/12/18(日) 21:17:43 ID:???] >>916 ちがうでしょ。 controllerでは下のように条件分岐している。 if (USE_SECURITY && $actionInstance->isSecure()) { 919 名前：nobodyさん mailto:sage [2005/12/18(日) 21:42:33 ID:???] >>911-912 それがPHPクオリティ 920 名前：nobodyさん mailto:sage [2005/12/18(日) 22:12:04 ID:???] >>918 なにが違うんだ？ USE_SECURITY && $actionInstance->isSecure()で filterChainにSecurityFilterが登録されるわけだが。 なんでfilter.iniで再登録する必要がある？ $actionInstance->isSecure()の意味解ってないだろ 921 名前：nobodyさん mailto:sage [2005/12/18(日) 22:48:36 ID:???] >>920 申し訳ございません。 私が間違ってました。 922 名前：nobodyさん mailto:sage [2005/12/18(日) 23:39:16 ID:???] 俺も間違ってた・・・。 再登録以前に、filters.iniにBasicSecurityFilterを登録したら 未認証時に遷移するはずのLoginAction自体にもBasicSecurityFilterが適用されて強制無限ループ。 正確には、forwardが20回再帰すると例外投げるから無限ループにはならないみたいだけど。 すみませんでした。 923 名前：nobodyさん mailto:sage [2005/12/18(日) 23:54:26 ID:???] それそれ！ BasicSecurityFilterは$this->loadModuleFilters($filterChain); でregistすると、ループする。 （Default_LoginActionにisSecure ()適用したと同等の現象） いちいちactionでisSecure ()をtrueに書き直すのめんどくさい。 何とかなりませんか 924 名前：nobodyさん mailto:sage [2005/12/19(月) 17:48:44 ID:???] mojaviでadodb+DB_Object使ってる香具師いる? 925 名前：nobodyさん mailto:sage [2005/12/19(月) 18:34:07 ID:???] その組み合わせってなんか変じゃね？ 926 名前：nobodyさん mailto:age [2005/12/19(月) 21:25:50 ID:???] headerを出力したいんだけど、viewにそのまま書いていい？ 927 名前：nobodyさん mailto:sage [2005/12/19(月) 21:49:37 ID:???] >>925 変だからやってる香具師いるかなぁと 普通ならPEAR::DB+DB_Objectだろうけど、PEAR::DBってadodbより遅いって言うし。 928 名前：nobodyさん mailto:sage [2005/12/19(月) 21:53:15 ID:???] そこでPDOですよ。 929 名前：nobodyさん mailto:sage [2005/12/19(月) 22:05:31 ID:???] >>925 viewに書くのか。 新しい考えだけど俺はactionに書いてる。 だってviewじゃないし。 930 名前：nobodyさん mailto:sage [2005/12/19(月) 22:08:30 ID:???] >>927 DB_DataObjectは確かに内部でDBを使っているが、 基本的に抽象レイヤーと組み合わせて使うもんじゃないぞ DB_DataObjectのソースに手を入れるなら別だけど 931 名前：nobodyさん mailto:sage [2005/12/19(月) 22:42:40 ID:???] DB_DataObjectつかうならFlexyもどうぞ。 932 名前：nobodyさん mailto:sage [2005/12/20(火) 00:41:08 ID:???] >>931 Alanさん早くDBDOをFixしてください 933 名前：nobodyさん mailto:sage [2005/12/20(火) 02:33:17 ID:???] というよりみんなは何を使ってるの? PDO使いたいけどPHP5.1で動かないアプリがあるからムリポ DB_DataObjectで楽するかadodbで早さを取るか迷い中 934 名前：nobodyさん mailto:sage [2005/12/20(火) 12:06:31 ID:???] agaviサイトまだエラー直ってないじゃん やる気ねーーー 935 名前：nobodyさん mailto:sage [2005/12/20(火) 14:49:28 ID:???] Mojavi2は　PHP5で動作しますか？ 936 名前：nobodyさん mailto:sage [2005/12/20(火) 15:07:17 ID:???] >>933 そもそも PHP を使ってない(ﾟДﾟ) 937 名前：nobodyさん mailto:sage [2005/12/20(火) 16:02:57 ID:???] コスモを感じる 938 名前：nobodyさん mailto:sage [2005/12/21(水) 09:02:46 ID:???] agavi直りますた。 939 名前：nobodyさん mailto:sage [2005/12/21(水) 10:14:48 ID:???] Mojavi < agavi < 江角　< Maple　? 今、Mojavi勉強中なんです。　ながら気になってます。 940 名前：nobodyさん mailto:sage [2005/12/21(水) 11:02:52 ID:???] mojavi以外ならどれでも自分が使いやすいのを使えばいいと思う｡ 941 名前：nobodyさん mailto:sage [2005/12/21(水) 15:41:11 ID:???] ありがとう。Mojavi以外を考えたほうがいいのか？　Mojaviを習得するか？ Mojavi覚えるの大変なんですが、何日くらいで慣れますかね？ 942 名前：nobodyさん mailto:sage [2005/12/21(水) 18:11:03 ID:???] >>940 なぜmojavi以外? 943 名前：nobodyさん mailto:sage [2005/12/21(水) 19:57:44 ID:???] M3かagaviをすすめる。 オブジェクトを理解するのにちょうど良い。 944 名前：nobodyさん mailto:sage [2005/12/21(水) 21:52:51 ID:???] M3とは？ 945 名前：nobodyさん mailto:sage [2005/12/21(水) 22:03:21 ID:???] mojavi3 946 名前：nobodyさん mailto:sage [2005/12/21(水) 22:51:55 ID:???] あれ？ひょっとしてagavi0.10.0が出た話題出てない？ 947 名前：nobodyさん mailto:sage [2005/12/21(水) 23:05:54 ID:???] そういえば出てないねぇ。ってかagavi自体の話もあんまり無いような・・・ 948 名前：nobodyさん mailto:sage [2005/12/22(木) 00:27:18 ID:???] おお！agavi0.10.0がほんとにでとる！ アップデートしてそのまま使えるんか 949 名前：nobodyさん mailto:sage [2005/12/22(木) 12:52:20 ID:???] agavi Mojavi3 Ethmi Makiko 結局Mojavi2で落ち着きました。 その後はまた考えます。 950 名前：nobodyさん mailto:age [2005/12/22(木) 18:28:57 ID:???] php4つかってんの？ 後々のこと考えるとphp5とm3の方がいい。 951 名前：nobodyさん mailto:sage [2005/12/23(金) 02:00:04 ID:???] フレームワークを使うならPHP5＋なんかだろうね。 php4使うぐらいならフレームワーク使わないでいいと思う。 どうせ将来性ないし。 952 名前：nobodyさん mailto:sage [2005/12/23(金) 04:49:25 ID:???] まだまだPHP4が使われつづけると思う。 今のようなPHPの使われ方なら、PHP4で問題ない。 953 名前：nobodyさん mailto:sage [2005/12/23(金) 10:19:22 ID:???] プロシージャ系を想定してるんだろうけど 開発者の一人がもうphp4固有のバグなんかは直さないよというような ものは使わないほうがいいと思う 954 名前：nobodyさん mailto:sage [2005/12/23(金) 10:20:08 ID:???] というか非OOのフレームワークって見たこと無いや 955 名前：nobodyさん mailto:sage [2005/12/23(金) 12:21:16 ID:???] agavi0.10.0使ってる人、レポよろ 956 名前：nobodyさん mailto:sage [2005/12/23(金) 14:01:08 ID:???] ジングルベルってこういう歌だったの！？ 一回目は普通のジングルベルで終わった後、もう一回ボタンをおしてリバースすると・・・ 聞こえにくい場合は音を少し大きめに。 media.spikedhumor.com/8944/Jingle_Bells_Reversed.swf 957 名前：nobodyさん mailto:sage [2005/12/23(金) 14:05:43 ID:???] >>956 このｽﾚにまでそんなコピペが貼られるご時世かよ 958 名前：nobodyさん mailto:sage [2005/12/23(金) 15:07:39 ID:???] >>957 冬休みだしね 959 名前：nobodyさん mailto:sage [2005/12/23(金) 18:02:33 ID:???] >>958 クリスマス寂しいな 960 名前：nobodyさん mailto:sage [2005/12/23(金) 18:02:45 ID:???] >>955 初ﾌﾚｰﾑﾜｰｸにAgaviを選択してみました。 英語がさっぱりなので、ドキュメントもなんとなくしか わからないのですけど、すごく良い感じですね。 日本語情報がすごい少ない以外は今のところ不都合ないです。 ってﾚﾎﾟになってないですね・・・。 961 名前：nobodyさん mailto:sage [2005/12/23(金) 20:44:59 ID:???] >>956 そういうさ、途中で叫び声入るようなドッキリ系張る奴って、そんなに驚いたのか？ 叫ばれてもお前に腹立つだけで、広めようとかまったく思わなかったんだが。 962 名前：nobodyさん mailto:sage [2005/12/23(金) 21:33:46 ID:???] ちょｗｗｗ 今PHPのサイトもエラ−になってる www.php.net/ Fatal error: Call to a member function on a non-object in /local/Web/sites/phpweb/include/ip-to-country.inc on line 65 963 名前：nobodyさん mailto:sage [2005/12/24(土) 01:48:59 ID:???] 直ってる… 964 名前：nobodyさん mailto:sage [2005/12/24(土) 02:58:29 ID:???] 非SQL型のアプローチって 逆に手間増える場合も多いね。 抽象化レイヤ一枚かぶせただけみたいな形になって しかもインターフェイスを憶えにくいからコーディングがﾉﾛﾉﾛになった。 965 名前：nobodyさん mailto:sage [2005/12/24(土) 10:57:47 ID:???] 非SQLていうと、ldapとか、XMLで問い合わせるDBとか? べつにそういう印象はないけど、慣れの問題じゃない? 966 名前：nobodyさん mailto:sage [2005/12/24(土) 13:22:47 ID:???] いや、ldapとかXMLじゃなくて、 RDMSに対して生SQLを書かずにアクセスできる ラッパークラスのアプローチ。 たしかに慣れたら速く書けるんだろうけど ガンガン進みたい時に「あーｳｾﾞｰ！」ってなる。 967 名前：nobodyさん mailto:sage [2005/12/24(土) 14:29:17 ID:???] >>966 わーい、仲間発見 可読性上がるし、エスケープ忘れ無くなるので、 がんばってるけど、SQL直書きに比べるとめんどいよね 968 名前：nobodyさん mailto:sage [2005/12/24(土) 14:37:36 ID:???] そういえばcakeとかのactiveredord実装は面白い。 インターフェイスがとても簡単なのもあるけど、生SQLはほとんどLEFT JOIN一本槍で もう効率とかギリギリまで行く必要ないじゃん? みたいな思想に萌える。 findBySql()で、カスタムなsqlを飛ばしても、簡単なルールさえ守れば スムーズにModelフレームワークに組み込むことは出来るし、 その気になれば複雑なjoin条件をモデルに指定する事もできるようだ。ドキュメント無いけど。 さて、そろそろ布団から出て宴会に行く支度するか。 969 名前：nobodyさん mailto:sage [2005/12/24(土) 16:08:37 ID:???] > LEFT JOIN一本槍 あれMysql5系でどーすんだろ 970 名前：nobodyさん mailto:sage [2005/12/24(土) 16:22:33 ID:???] >>969 mysqlのleft joinに何か問題あるの? 971 名前：nobodyさん mailto:sage [2005/12/24(土) 16:43:14 ID:???] 問題ない 972 名前：nobodyさん mailto:sage [2005/12/24(土) 17:02:10 ID:???] >>969 いやINNERJOIN＋WHERE句で結合だから 973 名前：nobodyさん mailto:sage [2005/12/24(土) 21:23:54 ID:???] MySQL5関連はサポートレベルではみんな困ってるみたいね。 JOIN関係で修正が必要になるのはON句でこじゃれたことしてる場合だけでいいの？ 974 名前：nobodyさん mailto:sage [2005/12/26(月) 12:06:40 ID:???] valueクラスつくって（下記）ユーザの情報を入れるんだけど、 DBからユーザ情報をたくさん取得してこのオブジェクトにセットした場合 オーバーヘッドがすごいですよね。 複数のユーザ情報をvalueクラスにセットする場合ってどうやってますか？ class userValue { private $userId; private $name; private $mail; function getUserId() { return $this->userId; } } 975 名前：nobodyさん mailto:sage [2005/12/26(月) 13:36:57 ID:???] >>974 いわゆるActiveRecordみたいなことをしたいなら、__getや__setをつかうのがよいかと。 つーかオーバーヘッドがすごいってどういうこっちゃ？ 976 名前：nobodyさん mailto:sage [2005/12/26(月) 13:43:14 ID:???] 連想配列使うのが速いに決まってるよな。 977 名前：nobodyさん mailto:sage [2005/12/26(月) 15:46:26 ID:???] 俺はVOは基本連想配列使ってるなぁ。 場合に応じてValueListクラスを作ることもある。 978 名前：nobodyさん mailto:sage [2005/12/26(月) 19:07:34 ID:???] わかりました。 private $userId; private $name; private $mail; private $userAR = array(); こうやって対応しました。 979 名前：nobodyさん mailto:sage [2005/12/27(火) 00:06:55 ID:???] >>978 PHPの場合連想配列があるから こんな感じで作ったほうが使いやすくない？ private $_data = array(); function set($key, $value) { $_data[$key] = $value; } function get($key) { return $_data[$key]; } 980 名前：nobodyさん mailto:sage [2005/12/27(火) 00:20:25 ID:???] php5を使っているのならコレクションクラスはイテレータを使って上品にいきたいところだ。 981 名前：nobodyさん mailto:sage [2005/12/27(火) 07:58:48 ID:???] つーかZend Frameworkいつ出るか誰か知ってる？ Ruby on Railsに酷似しているという噂もあったり・・・？ あと誰か次スレ立てて。 982 名前：nobodyさん mailto:sage [2005/12/27(火) 14:00:05 ID:???] 来年の今頃じゃない？勘だけど＞zendﾌﾚｰﾑﾜｰｸ 983 名前：nobodyさん mailto:sage [2005/12/27(火) 17:40:49 ID:???] 来年の今頃出されてもPHP自体が終わってると思うよ。 984 名前：nobodyさん mailto:sage [2005/12/27(火) 17:53:08 ID:???] 来年の今頃なんて、おいらプログラム書いてないかも知れないっスよ(　´･∀･`) 985 名前：nobodyさん mailto:sage [2005/12/27(火) 18:52:11 ID:???] >>982 そんな遅くないでしょ この間のプレゼンでドキュメントを数週間以内に出すって言ってたけど まだ出てないのかな 986 名前：nobodyさん mailto:sage [2005/12/28(水) 00:22:05 ID:???] こういうのは遅れるのがﾃﾞﾌｫだからなぁ。 987 名前：nobodyさん mailto:sage [2005/12/28(水) 03:11:20 ID:???] WEB+DB PRESSの新刊に agaviの記事があったよ。 今回は他にもPHPの記事が結構あった。 988 名前：nobodyさん mailto:age [2005/12/28(水) 20:26:19 ID:???] mojavi3で作ったアプリ HTMLのiframeからべつのphpファイルを指定し そのphpファイルからmojaviで認証されたユーザー情報を参照したいのですが どうすればいいでしょうか。 内緒なデータなので$_GETでは渡したくないです。 989 名前：nobodyさん mailto:sage [2005/12/29(木) 00:19:22 ID:???] >>988 別の人に仕事を委託する。 990 名前：nobodyさん mailto:sage [2005/12/29(木) 01:30:04 ID:???] mojaviなんですが、ファイルのアップロードとか自作クラスを何処においてますか？ 普通、Lib/下に置くものなんですか？　opt/下に置くものなんですか？ 991 名前：nobodyさん mailto:sage [2005/12/29(木) 11:49:15 ID:???] Smartyなど共通クラスはLib/下に置いてます。 992 名前：nobodyさん mailto:sage [2005/12/29(木) 15:50:17 ID:???] RubyがもっとしっかりしてくれたらPHPなんて使わずに済むのに 993 名前：nobodyさん mailto:sage [2005/12/29(木) 16:11:46 ID:???] Javaにしとけ 994 名前：nobodyさん mailto:sage [2005/12/29(木) 16:27:46 ID:???] >>993 スケーラビリティ糞 995 名前：nobodyさん mailto:sage [2005/12/29(木) 17:00:29 ID:???] まさかJavaよりRubyのほうがスケーラビリティ高いとか言わないよね？ そもそもPHPだって設計きちんとやれば見下ろすほど拡張性低くないのにね。 まあJavaは言語仕様自体が拡張性上げてるようなもんだし。 特異メソッドだの特異クラスだのクロージャだの溢れかえったRubyにスケーラビリティのスの字もないと思うけど。 拡張モジュールをCで書いたりなんてことになると、もうね。 それより、Zend FrameworkはPHPネイティブらしいし、スケーラビリティに関して少しは期待していいかと。 RoRと比べてどうかとかは出てからじゃないと何ともいえないけど。 996 名前：988 mailto:age [2005/12/29(木) 17:02:56 ID:???] これはセッションしかないなと思い、iframeに表示している別のphpファイルで session_start(); してvar_dump($_SESSION); しましたが、array(0) { } となってしまいました。mojaviの$userValueオブジェクトが セットされているのですがセットされていませんでした。 997 名前：nobodyさん mailto:sage [2005/12/29(木) 17:37:04 ID:???] 次スレ立ててきます。 998 名前：997 mailto:sage [2005/12/29(木) 17:42:43 ID:???] すまんむりだったorz　フレームワーク一覧 Phrame phrame.sourceforge.net/ Mojavi Project www.mojavi.org/ Agavi agavi.org/ [ 日本発 ] Maple Project kunit.jp/maple/ [ 日本発 ] Ethna -PHPウェブアプリケーションフレームワーク- ethna.jp/ethna-tutorial-startup-practice1.html [ 日本発 ] guesswork www.guesswork.jp/ Biscuit bennolan.com/biscuit/ PHP on TRAX phpontrax.com/ Web Application Component Toolkit (WACT) www.phpwact.org/ symfony www.symfony-project.com/ XOAD wiki.xoad.org/index.php?title=Wiki_Home [ 日本発 ] pokox www.glamenv-septzen.net/pukiwiki/index.php?pokox [ 日本発 ] 速構Web Framework www.pm9.com/newpm9/itbiz/php/framework/ 999 名前：nobodyさん mailto:sage [2005/12/29(木) 17:46:32 ID:???] CakePHP cakephp.org/ これも。 1000 名前：nobodyさん mailto:sage [2005/12/29(木) 18:02:13 ID:???] 1000 1001 名前：１００１ [Over 1000 Thread] このスレッドは１０００を超えました。 もう書けないので、新しいスレッドを立ててくださいです。。。

---

---

[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef