05/12/15 03:28:55
>>841に対して、はじめは何言ってるんだろうこの人…と、>>842と
同じ気持ちでしたが、
URLﾘﾝｸ(www.microsoft.com)
ここを読んでみて>>841の言ってることがよくわかりました。
MVCの図にあるとおり
＞ビューとコントローラの両方がモデルに依存していることに注意してください。ただし、モデルはビューとコントローラのどちらにも依存していません。
モデルは両方に依存していないものなんだね。
そう考えるとたしかに>>839の言ってる図は話にならない。
でも、それを言い出すとAgaviの設計自体がおかしいことになるね。
856:839
05/12/15 03:51:45
>>855
たぶんUMLを見慣れてる人が多いんだろうから誤解を与えたかもしれないけど、>>839は「依存関係」を表してるつもりじゃなかったんだなぁorz
Controller→Action→Controller→Viewってのは制御が移る順番。
他の⇔はデータの受け渡しであって、基本的にはメソッドの呼び出し＋リターンなので制御が移る順番としても解釈できるかも。
>>855が依存関係の話を持ってきてくれたのでそれも考慮すると、⇔の矢印をすべて外側向きに変えたら少しはましになるかな？
矢印の意味は
・依存してる側→依存されてる側
・呼び出し側→呼び出される側
という関係で。（唯一Action→Controllerの部分だけリターンなので矢印の色でも変えてくださいｗ）
「ビジネスロジック」って言葉は俺も再考する必要があるかも。
>>846をもうちょっと咀嚼してみる。
857:nobodyさん
05/12/15 03:53:25
URLﾘﾝｸ(forum.mojavi.org)
こういうの見るとますますわからんくなる…
858:nobodyさん
05/12/15 04:01:35
そこまでごちゃごちゃ深いこと考えなくても、
保守性の高いコードってWebアプリケーションなら結構つくれちゃうからなぁ…
ビジネスロジック云々より、ビジネスや運営自体について考えてたほうがよっぽど金になる
859:839
05/12/15 04:09:49
>>858
俺的もそう思う。どっちでもいーじゃんおまいらｗ、と
でも「間違っている」というつっこみをたくさんいただいたので、ヘコみつつ悪戦苦闘中であります。
860:nobodyさん
05/12/15 04:22:02
>>855
マジでAgaviのView周りってModelに依存性あるの?
ステートレスなWebアプリでは切り離されてるのが当たり前だと思ってたけど。
アクティブモデルにせよオブザーバはかませるっしょ
861:nobodyさん
05/12/15 04:40:08
View生成はクライアントリクエストのみを起点にしているから、
コントローラかアクションにぶらさげることは出来るね
前者はコントローラがMediator（と言ってもモデルかアクションから
データを受け渡すだけ）となり、後者ではアクションはコマンドオブジェクト
（ビジネスロジックとViewの呼び出しをカプセル化したもの）ということになる
どっちもパターンとしてはMVCとは呼ばないんだろうけど
URLﾘﾝｸ(www.martinfowler.com)
Viewがモデルに依存したほうがいいかアクションに依存したほうがいいか
まとまった見解ってある？
862:nobodyさん
05/12/15 04:43:36
>>860
Agavi自体の仕様では依存性は発生しないよ。Modelは一つもなくても動くし。
でもModelを使った時点で依存はゼロではないと思われ。
「切り離す」ってのはいわゆる疎結合にするって意味だとは思うけど、元々依存してしまうものだからせめて疎結合にしましょうって感じじゃなかったっけ？
>>855の言ってるのは、逆向きの依存はゼロってことでしょう。
「Viewを変更したらModelが動かなくなりました」とかしゃれになんないし。
でもModelを変更したらViewに支障が出るのは仕方ない。
それでも最小限にしましょうってのが疎結合だと思う。
オブザーバはContextのことでおｋかな？
863:nobodyさん
05/12/15 05:25:53
依存性＝オブジェクトをNewするかパラメータに取ってメンバにアクセスすること
結合の程度というようなファジーなものは存在しない
Framework界隈で依存性といったらこれのことだと思う
864:nobodyさん
05/12/15 05:52:18
> 結合の程度というようなファジーなものは存在しない
疎結合って結合の程度がゆるいことじゃないの？
つーかどのレスに対してなのか反論なのか何なのかわからんな。
865:863
05/12/15 06:11:06
直上に対するレス
結合にはもちろん程度があるよ
しかし依存性にはそういうものは無くゼロイチだということを言ってみた
>>860と>>862の愛でどうも考えている依存性が違って
かみ合ってないように見えたので
866:nobodyさん
05/12/15 06:12:18
× 愛で
○ 間で
すまん
間違ったものを芽生えさせた
867:nobodyさん
05/12/15 06:12:22
>>860
Modelにするにせよ別もんにしてつくるにしても、
初期のViewだけじゃなにもできんじゃん。
ごてごてタグとテンプレートと定数混ぜることになってしまう。
その辺のモデルもつくるでしょ？ふつう
868:nobodyさん
05/12/15 06:16:08
いや、Mojaviだとビジネスロジックの呼び出しはアクションあたりに集約するのが一般的だと思う
ビュー内でモデルは呼び出したくない
869:nobodyさん
05/12/15 06:20:08
>>868
MVCはもともとそういうものだけどな。View - -> Model
870:862
05/12/15 06:21:54
>>865
そかそか。曖昧な言い方ですまんかった。
基本的には「依存性はゼロイチ」ってのは同意だよ。
だから>>860への答えはViewからModelへの依存性は「あり」。
ただ「切り離されてるのが当たり前」って表現をしてたので、862で「それは疎結合のことであって≠依存性だよね」っていう意味で言った。
>>868
実際にはそうだよなｗ
871:nobodyさん
05/12/15 06:23:49
>>869
パッシブモデルね
872:nobodyさん
05/12/15 09:58:57
モデルをフレームワークから独立させる派は
モデルからUserにアクセスする必要がある時はどうやってるの？
873:nobodyさん
05/12/15 10:10:17
>>872
モデルはフレームワークに依存していない設計なので、
モデルから User にアクセスする必要がない。
874:nobodyさん
05/12/15 10:21:58
extends Modelすらしないってこと？
875:nobodyさん
05/12/15 10:26:14
>>873
DBはどうしてる？
876:nobodyさん
05/12/15 11:14:48
Mojavi系の場合DBみたいな下層にも入ってくるから
フレームワークに依存しない設計がいまいちイメージしにくいな
877:nobodyさん
05/12/15 11:38:55
というか、一度 Mojavi を頭から追い出して一般的な設計の話をしろよｗ
もうあんな設計は古いって…。
878:nobodyさん
05/12/15 11:43:23
話変えたいなら自分から話題を提供すればいいのに
879:nobodyさん
05/12/15 11:51:42
スルーしとけ
880:nobodyさん
05/12/15 11:55:01
Mojaviはたたき台としてまだ価値あるだろ
影響受けてるフレームワークいっぱいあるしな
881:nobodyさん
05/12/15 14:16:48
rails!rails!
882:nobodyさん
05/12/15 15:21:47
PHP on TRAXときたか
883:nobodyさん
05/12/15 21:48:05
S2Baseがいいと思うんだけど、どう？
ValidateやらFilterは自作になるけど、結構いいと思う。
884:nobodyさん
05/12/15 23:18:51
S2PandNで出席者が質問してたが､S2やMapleのDIはどこまでパフォーマンスが出るか疑問｡
プロダクトとしてリリースするなら､自分のところできちんと性能評価をやった方がいいよ｡
885:nobodyさん
05/12/16 00:48:04
もうMojaviでいいや。
886:nobodyさん
05/12/16 01:35:11
S2をそのままPHPに移植してるのかな
887:768
05/12/16 09:02:11
zend framework待とうよ！
888:nobodyさん
05/12/16 09:14:05
末広がりget, zuzaa
889:nobodyさん
05/12/16 18:13:50
Mojavi初心者なんですが
エスパー募集してもよろしいでしょか？
890:nobodyさん
05/12/16 18:41:40
>>889
ここは語るスレだ。質問はスレ違い。
891:889
05/12/16 18:51:08
>>890
そうですか、失礼しました。(´･ω･｀)
892:nobodyさん
05/12/17 00:42:49
POSTされたデータをDBへupdateする場合はmodelでするの？
893:nobodyさん
05/12/17 01:13:05
>>890
多少質問あったほうが盛り上がるからいいんで内科医？
>>892
基本的にvalidationはactionでやり、DBの扱いはmodelでやってるけど、このスレ読んでたらもしかしたらactionでやったほうがいいのかな？とも思えてきた。
894:nobodyさん
05/12/17 01:30:36
>>893
エスパー募集な質問でもか？
895:nobodyさん
05/12/17 01:39:26
あー、エスパー募集はよろしくない罠ｗ
896:nobodyさん
05/12/17 01:50:31
>>892
modelを作るほど複雑でなく(単なるログとか)、
また他のアクションで同じ機能を利用しないならアクションで済ませてしまってもいいとは思う。
897:nobodyさん
05/12/17 02:02:35
>>896
modelでDBに登録するとしたらサニタイズもmodelでやるってことになる？
でないとmodelがactionに依存してしまう気がするんだけど。
898:nobodyさん
05/12/17 09:32:09
そしたら
サニタイズはactionでやるべきだね。
899:nobodyさん
05/12/17 09:36:15
アクション前にフィルタ処理は済んでるはず
モデルは自身のためのサニタイズは自身で持つ
いずれも定義は括りだす
900:nobodyさん
05/12/17 09:39:35
インプットフィルター → アクションDeバリデーション → モデルサニタイズ
てことか。
実際どこで何をやるんだろ。
901:nobodyさん
05/12/17 10:04:30
つーかModelでDBに書き込む場合、フィルタでサニタイズするのもおかしいじゃん。
てことはActionでDBに書き込むのが正しい？
902:nobodyさん
05/12/17 10:55:36
ありえなす
903:nobodyさん
05/12/17 11:29:14
俺はmodelからdbクラスいじってやってるけど。
904:nobodyさん
05/12/17 12:05:30
mojaviの質問はどこですればいい？
905:nobodyさん
05/12/17 12:12:34
ここですればいいよ
答えが返ってくる時もあれば返ってこない時もあるけど
906:nobodyさん
05/12/17 13:19:27
>>904
あなたの質問がこのスレの命運を決めるかもしれません。
慎重に質問してください。
907:nobodyさん
05/12/17 13:24:57
何のプレッシャーだよw
908:nobodyさん
05/12/17 19:16:29
おい、agaviのサイトがエラーですよ！
URLﾘﾝｸ(www.agavi.org)
909:nobodyさん
05/12/17 20:58:41
>>908
多分5.1にしたんじゃないか
910:nobodyさん
05/12/17 21:00:06
>>908
多分PHP5.1に変えたんだろ
timezone関係の警告でてるし
911:nobodyさん
05/12/17 22:24:03
バージョン上げてからチェックしないとはアホもいいとこだなｗ
912:nobodyさん
05/12/18 03:06:20
>>911
逆だろ
チェックしてからバージョン上げないなんてアホもいいとこだなｗ
913:nobodyさん
05/12/18 03:09:01
まあフレームワークのサイトが
危機管理意識なしでエラーメッセージ垂れ流しっていうのは
あまりよろしくないよなぁ。
そもそも確認すらしないのかと。
914:nobodyさん
05/12/18 06:17:14
あれ、こんなエラー自分の環境じゃ出なかったのに
915:nobodyさん
05/12/18 09:07:58
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のフォワード無限ループになります。
URLﾘﾝｸ(ozaki.kyoichi.jp)
ここのサイトではちゃんとできているようだけど、
同じようなトラブルにあっている方はいますか？
916:nobodyさん
05/12/18 11:43:36
そのドキュメントは古いよ
BasicSecurityFilterの使用はsettings.iniのUSE_SECURITYで決定する
filters.iniに設定する必要はないよ
917:nobodyさん
05/12/18 14:07:02
o
918:nobodyさん
05/12/18 21:17:43
>>916
ちがうでしょ。
controllerでは下のように条件分岐している。
if (USE_SECURITY && $actionInstance->isSecure()) {
919:nobodyさん
05/12/18 21:42:33
>>911-912
それがPHPクオリティ
920:nobodyさん
05/12/18 22:12:04
>>918
なにが違うんだ？
USE_SECURITY && $actionInstance->isSecure()で
filterChainにSecurityFilterが登録されるわけだが。
なんでfilter.iniで再登録する必要がある？
$actionInstance->isSecure()の意味解ってないだろ
921:nobodyさん
05/12/18 22:48:36
>>920
申し訳ございません。
私が間違ってました。
922:nobodyさん
05/12/18 23:39:16
俺も間違ってた・・・。
再登録以前に、filters.iniにBasicSecurityFilterを登録したら
未認証時に遷移するはずのLoginAction自体にもBasicSecurityFilterが適用されて強制無限ループ。
正確には、forwardが20回再帰すると例外投げるから無限ループにはならないみたいだけど。
すみませんでした。
923:nobodyさん
05/12/18 23:54:26
それそれ！
BasicSecurityFilterは$this->loadModuleFilters($filterChain);
でregistすると、ループする。
（Default_LoginActionにisSecure ()適用したと同等の現象）
いちいちactionでisSecure ()をtrueに書き直すのめんどくさい。
何とかなりませんか
924:nobodyさん
05/12/19 17:48:44
mojaviでadodb+DB_Object使ってる香具師いる?
925:nobodyさん
05/12/19 18:34:07
その組み合わせってなんか変じゃね？
926:nobodyさん
05/12/19 21:25:50
headerを出力したいんだけど、viewにそのまま書いていい？
927:nobodyさん
05/12/19 21:49:37
>>925
変だからやってる香具師いるかなぁと
普通ならPEAR::DB+DB_Objectだろうけど、PEAR::DBってadodbより遅いって言うし。
928:nobodyさん
05/12/19 21:53:15
そこでPDOですよ。
929:nobodyさん
05/12/19 22:05:31
>>925
viewに書くのか。
新しい考えだけど俺はactionに書いてる。
だってviewじゃないし。
930:nobodyさん
05/12/19 22:08:30
>>927
DB_DataObjectは確かに内部でDBを使っているが、
基本的に抽象レイヤーと組み合わせて使うもんじゃないぞ
DB_DataObjectのソースに手を入れるなら別だけど
931:nobodyさん
05/12/19 22:42:40
DB_DataObjectつかうならFlexyもどうぞ。
932:nobodyさん
05/12/20 00:41:08
>>931
Alanさん早くDBDOをFixしてください
933:nobodyさん
05/12/20 02:33:17
というよりみんなは何を使ってるの?
PDO使いたいけどPHP5.1で動かないアプリがあるからムリポ
DB_DataObjectで楽するかadodbで早さを取るか迷い中
934:nobodyさん
05/12/20 12:06:31
agaviサイトまだエラー直ってないじゃん
やる気ねーーー
935:nobodyさん
05/12/20 14:49:28
Mojavi2は PHP5で動作しますか？
936:nobodyさん
05/12/20 15:07:17
>>933
そもそも PHP を使ってない(ﾟДﾟ)
937:nobodyさん
05/12/20 16:02:57
コスモを感じる
938:nobodyさん
05/12/21 09:02:46
agavi直りますた。
939:nobodyさん
05/12/21 10:14:48
Mojavi < agavi < 江角 < Maple ?
今、Mojavi勉強中なんです。 ながら気になってます。
940:nobodyさん
05/12/21 11:02:52
mojavi以外ならどれでも自分が使いやすいのを使えばいいと思う｡
941:nobodyさん
05/12/21 15:41:11
ありがとう。Mojavi以外を考えたほうがいいのか？ Mojaviを習得するか？
Mojavi覚えるの大変なんですが、何日くらいで慣れますかね？
942:nobodyさん
05/12/21 18:11:03
>>940
なぜmojavi以外?
943:nobodyさん
05/12/21 19:57:44
M3かagaviをすすめる。
オブジェクトを理解するのにちょうど良い。
944:nobodyさん
05/12/21 21:52:51
M3とは？
945:nobodyさん
05/12/21 22:03:21
mojavi3
946:nobodyさん
05/12/21 22:51:55
あれ？ひょっとしてagavi0.10.0が出た話題出てない？
947:nobodyさん
05/12/21 23:05:54
そういえば出てないねぇ。ってかagavi自体の話もあんまり無いような・・・
948:nobodyさん
05/12/22 00:27:18
おお！agavi0.10.0がほんとにでとる！
アップデートしてそのまま使えるんか
949:nobodyさん
05/12/22 12:52:20
agavi Mojavi3 Ethmi Makiko
結局Mojavi2で落ち着きました。 その後はまた考えます。
950:nobodyさん
05/12/22 18:28:57
php4つかってんの？
後々のこと考えるとphp5とm3の方がいい。
951:nobodyさん
05/12/23 02:00:04
フレームワークを使うならPHP5＋なんかだろうね。
php4使うぐらいならフレームワーク使わないでいいと思う。
どうせ将来性ないし。
952:nobodyさん
05/12/23 04:49:25
まだまだPHP4が使われつづけると思う。
今のようなPHPの使われ方なら、PHP4で問題ない。
953:nobodyさん
05/12/23 10:19:22
プロシージャ系を想定してるんだろうけど
開発者の一人がもうphp4固有のバグなんかは直さないよというような
ものは使わないほうがいいと思う
954:nobodyさん
05/12/23 10:20:08
というか非OOのフレームワークって見たこと無いや
955:nobodyさん
05/12/23 12:21:16
agavi0.10.0使ってる人、レポよろ
956:nobodyさん
05/12/23 14:01:08
ジングルベルってこういう歌だったの！？
一回目は普通のジングルベルで終わった後、もう一回ボタンをおしてリバースすると・・・
聞こえにくい場合は音を少し大きめに。
URLﾘﾝｸ(media.spikedhumor.com)
957:nobodyさん
05/12/23 14:05:43
>>956
このｽﾚにまでそんなコピペが貼られるご時世かよ
958:nobodyさん
05/12/23 15:07:39
>>957
冬休みだしね
959:nobodyさん
05/12/23 18:02:33
>>958
クリスマス寂しいな
960:nobodyさん
05/12/23 18:02:45
>>955
初ﾌﾚｰﾑﾜｰｸにAgaviを選択してみました。
英語がさっぱりなので、ドキュメントもなんとなくしか
わからないのですけど、すごく良い感じですね。
日本語情報がすごい少ない以外は今のところ不都合ないです。
ってﾚﾎﾟになってないですね・・・。
961:nobodyさん
05/12/23 20:44:59
>>956
そういうさ、途中で叫び声入るようなドッキリ系張る奴って、そんなに驚いたのか？
叫ばれてもお前に腹立つだけで、広めようとかまったく思わなかったんだが。
962:nobodyさん
05/12/23 21:33:46
ちょｗｗｗ
今PHPのサイトもエラ－になってる
URLﾘﾝｸ(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さん
05/12/24 01:48:59
直ってる…
964:nobodyさん
05/12/24 02:58:29
非SQL型のアプローチって
逆に手間増える場合も多いね。
抽象化レイヤ一枚かぶせただけみたいな形になって
しかもインターフェイスを憶えにくいからコーディングがﾉﾛﾉﾛになった。
965:nobodyさん
05/12/24 10:57:47
非SQLていうと、ldapとか、XMLで問い合わせるDBとか?
べつにそういう印象はないけど、慣れの問題じゃない?
966:nobodyさん
05/12/24 13:22:47
いや、ldapとかXMLじゃなくて、
RDMSに対して生SQLを書かずにアクセスできる
ラッパークラスのアプローチ。
たしかに慣れたら速く書けるんだろうけど
ガンガン進みたい時に「あーｳｾﾞｰ！」ってなる。
967:nobodyさん
05/12/24 14:29:17
>>966
わーい、仲間発見
可読性上がるし、エスケープ忘れ無くなるので、
がんばってるけど、SQL直書きに比べるとめんどいよね
968:nobodyさん
05/12/24 14:37:36
そういえばcakeとかのactiveredord実装は面白い。
インターフェイスがとても簡単なのもあるけど、生SQLはほとんどLEFT JOIN一本槍で
もう効率とかギリギリまで行く必要ないじゃん? みたいな思想に萌える。
findBySql()で、カスタムなsqlを飛ばしても、簡単なルールさえ守れば
スムーズにModelフレームワークに組み込むことは出来るし、
その気になれば複雑なjoin条件をモデルに指定する事もできるようだ。ドキュメント無いけど。
さて、そろそろ布団から出て宴会に行く支度するか。
969:nobodyさん
05/12/24 16:08:37
> LEFT JOIN一本槍
あれMysql5系でどーすんだろ
970:nobodyさん
05/12/24 16:22:33
>>969
mysqlのleft joinに何か問題あるの?
971:nobodyさん
05/12/24 16:43:14
問題ない
972:nobodyさん
05/12/24 17:02:10
>>969
いやINNERJOIN＋WHERE句で結合だから
973:nobodyさん
05/12/24 21:23:54
MySQL5関連はサポートレベルではみんな困ってるみたいね。
JOIN関係で修正が必要になるのはON句でこじゃれたことしてる場合だけでいいの？
974:nobodyさん
05/12/26 12:06:40
valueクラスつくって（下記）ユーザの情報を入れるんだけど、
DBからユーザ情報をたくさん取得してこのオブジェクトにセットした場合
オーバーヘッドがすごいですよね。
複数のユーザ情報をvalueクラスにセットする場合ってどうやってますか？
class userValue {
private $userId;
private $name;
private $mail;
function getUserId() {
return $this->userId;
}
}
975:nobodyさん
05/12/26 13:36:57
>>974
いわゆるActiveRecordみたいなことをしたいなら、__getや__setをつかうのがよいかと。
つーかオーバーヘッドがすごいってどういうこっちゃ？
976:nobodyさん
05/12/26 13:43:14
連想配列使うのが速いに決まってるよな。
977:nobodyさん
05/12/26 15:46:26
俺はVOは基本連想配列使ってるなぁ。
場合に応じてValueListクラスを作ることもある。
978:nobodyさん
05/12/26 19:07:34
わかりました。
private $userId;
private $name;
private $mail;
private $userAR = array();
こうやって対応しました。
979:nobodyさん
05/12/27 00:06:55
>>978
PHPの場合連想配列があるから
こんな感じで作ったほうが使いやすくない？
private $_data = array();
function set($key, $value) {
$_data[$key] = $value;
}
function get($key) {
return $_data[$key];
}
980:nobodyさん
05/12/27 00:20:25
php5を使っているのならコレクションクラスはイテレータを使って上品にいきたいところだ。
981:nobodyさん
05/12/27 07:58:48
つーかZend Frameworkいつ出るか誰か知ってる？
Ruby on Railsに酷似しているという噂もあったり・・・？
あと誰か次スレ立てて。
982:nobodyさん
05/12/27 14:00:05
来年の今頃じゃない？勘だけど＞zendﾌﾚｰﾑﾜｰｸ
983:nobodyさん
05/12/27 17:40:49
来年の今頃出されてもPHP自体が終わってると思うよ。
984:nobodyさん
05/12/27 17:53:08
来年の今頃なんて、おいらプログラム書いてないかも知れないっスよ( ´･∀･`)
985:nobodyさん
05/12/27 18:52:11
>>982
そんな遅くないでしょ
この間のプレゼンでドキュメントを数週間以内に出すって言ってたけど
まだ出てないのかな
986:nobodyさん
05/12/28 00:22:05
こういうのは遅れるのがﾃﾞﾌｫだからなぁ。
987:nobodyさん
05/12/28 03:11:20
WEB+DB PRESSの新刊に
agaviの記事があったよ。
今回は他にもPHPの記事が結構あった。
988:nobodyさん
05/12/28 20:26:19
mojavi3で作ったアプリ HTMLのiframeからべつのphpファイルを指定し
そのphpファイルからmojaviで認証されたユーザー情報を参照したいのですが
どうすればいいでしょうか。
内緒なデータなので$_GETでは渡したくないです。
989:nobodyさん
05/12/29 00:19:22
>>988
別の人に仕事を委託する。
990:nobodyさん
05/12/29 01:30:04
mojaviなんですが、ファイルのアップロードとか自作クラスを何処においてますか？
普通、Lib/下に置くものなんですか？ opt/下に置くものなんですか？
991:nobodyさん
05/12/29 11:49:15
Smartyなど共通クラスはLib/下に置いてます。
992:nobodyさん
05/12/29 15:50:17
RubyがもっとしっかりしてくれたらPHPなんて使わずに済むのに
993:nobodyさん
05/12/29 16:11:46
Javaにしとけ
994:nobodyさん
05/12/29 16:27:46
>>993
スケーラビリティ糞
995:nobodyさん
05/12/29 17:00:29
まさかJavaよりRubyのほうがスケーラビリティ高いとか言わないよね？
そもそもPHPだって設計きちんとやれば見下ろすほど拡張性低くないのにね。
まあJavaは言語仕様自体が拡張性上げてるようなもんだし。
特異メソッドだの特異クラスだのクロージャだの溢れかえったRubyにスケーラビリティのスの字もないと思うけど。
拡張モジュールをCで書いたりなんてことになると、もうね。
それより、Zend FrameworkはPHPネイティブらしいし、スケーラビリティに関して少しは期待していいかと。
RoRと比べてどうかとかは出てからじゃないと何ともいえないけど。
996:988
05/12/29 17:02:56
これはセッションしかないなと思い、iframeに表示している別のphpファイルで
session_start();
してvar_dump($_SESSION);
しましたが、array(0) { }
となってしまいました。mojaviの$userValueオブジェクトが
セットされているのですがセットされていませんでした。
997:nobodyさん
05/12/29 17:37:04
次スレ立ててきます。
998:997
05/12/29 17:42:43
すまんむりだったorz フレームワーク一覧
Phrame
URLﾘﾝｸ(phrame.sourceforge.net)
Mojavi Project
URLﾘﾝｸ(www.mojavi.org)
Agavi
URLﾘﾝｸ(agavi.org)
[ 日本発 ] Maple Project
URLﾘﾝｸ(kunit.jp)
[ 日本発 ] Ethna -PHPウェブアプリケーションフレームワーク-
URLﾘﾝｸ(ethna.jp)
[ 日本発 ] guesswork
URLﾘﾝｸ(www.guesswork.jp)
Biscuit
URLﾘﾝｸ(bennolan.com)
PHP on TRAX
URLﾘﾝｸ(phpontrax.com)
Web Application Component Toolkit (WACT)
URLﾘﾝｸ(www.phpwact.org)
symfony
URLﾘﾝｸ(www.symfony-project.com)
XOAD
URLﾘﾝｸ(wiki.xoad.org)
[ 日本発 ] pokox
URLﾘﾝｸ(www.glamenv-septzen.net)
[ 日本発 ] 速構Web Framework
URLﾘﾝｸ(www.pm9.com)
999:nobodyさん
05/12/29 17:46:32
CakePHP
URLﾘﾝｸ(cakephp.org)
これも。
1000:nobodyさん
05/12/29 18:02:13
1000
1001:１００１
Over 1000 Thread
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。