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 参照汁
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 まあどちらかと言うと、インスタンス2つ以上作ろうとする方が頭どうかしてるもんな。 Controllerとか。
832 名前:nobodyさん mailto:sage [2005/12/14(水) 01:43:05 ID:???] >>830 リクエスト毎にオブジェクトが生成->破棄されるという意味では無意味だな。 ログとかDBコネクションとかでは使えるけど、それもグローバル変数に入れとけばいいみたいな。
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はControllerを知るべきではない、 そして"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ができちゃうこともあるかもw 俺の場合は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でビジネスロジックもありっていうスタンスっぽいなw ただ、基本は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でビジネスロジックもありっていうスタンスっぽいなw と言った理由なんだけど。 ただ、俺自身はドメイン層の処理は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の部分だけリターンなので矢印の色でも変えてくださいw) 「ビジネスロジック」って言葉は俺も再考する必要があるかも。 >>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 俺的もそう思う。どっちでもいーじゃんおまいらw、と でも「間違っている」というつっこみをたくさんいただいたので、ヘコみつつ悪戦苦闘中であります。
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のことでおkかな?
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 実際にはそうだよなw
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 を頭から追い出して一般的な設計の話をしろよw もうあんな設計は古いって…。
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:???] あー、エスパー募集はよろしくない罠w
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:???] バージョン上げてからチェックしないとはアホもいいとこだなw
912 名前:nobodyさん mailto:sage [2005/12/18(日) 03:06:20 ID:???] >>911 逆だろ チェックしてからバージョン上げないなんてアホもいいとこだなw
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()の意味解ってないだろ