【PHP】Phrameを使う【フレームワーク】

MojaviはActionからViewに成果を引き渡すのにもRequestを使っている。
その役目を果たすコンテナとしてResultって話。

ｵﾘﾌﾚにしたら速度3倍くらいになった。
てかSmarty遅っ！！
遅いとは思っていたが数字で比較すると遅さを再確認した。
キャッシュ以前に、オブジェクトとしてデカすぎるもんな。

>>940
何からオリフレにしたの？M2?

ちっこいプレゼンテーションロジックオブジェクトを
テンプレートの荒野に解き放てば
一寸法師も真っ青な獅子奮迅の大活躍をしてくれるわけで。
Smartyなんていらねーんだよディック野郎(　ﾟдﾟ)､ﾍﾟｯ

>>941
M2+Smarty

caching ≠ compile
Smartyスレで暴れてたやつか？

オレは速度を最優先するならフレームワークなんか使わない。

>943
Smartyやめて自前でテンプレートシステム書いたんですか?

DB処理 > Smartyのオーバーヘッド　ならキャッシュ使えば体感は早いよ。

キャッシュ処理自体を自前で書けばもっと早いだろうけど、めんどくさ。

キャッシュとかサブテンプレートとか
Smartyの特徴的な機能って
自分でやってみればわりと簡単に実装できるよ
もともとphpに、出力をバッファリングしたり
それを変数に入れたりするコマンドがあるからね。
既製品は多くの人の要請に答えざるを得ないから、
宿命的に重くなっていく。
イラナイ機能のためにオーバーヘッドが生まれるのは
俺は好きくないな。
ただ間違いなく勉強にはなるので、やっておいて損はないとは思うが。

>>946
Cache::Liteとか使うとラクだよ。

つーか、数十万アクセス/dayのサイトをM2+smarty+adodbで作っても大して重くならないのに
オーバーヘッドがとか軽くとか言ってる方っていったいどれだけ大規模な案件を抱えていらっしゃるんですか？

Smartyのマニュアルのキャッシュの項読んでみなよ。
あれ自分で実装するの？メンテも自分で？勘弁してよ。

>949
それは君の組み方が上手いのもあると思う｡
他にデータ量とか､マシンスペックとかによっても体感の重さは変わってくるし。

いろいろ実装していった結果…
非SmartyはSmartyの10％程度しか速くならないことが分かった
結局Smartyに戻したよ　orz

テンプレートだけ速くしても他は変わらんからね。
個人でやるならオレオレフレームワーク+オレオレテンプレートエンジンで
カリカリにチューニングして自己満足も良いけど
保守性を考えたら出来合いのある程度普及してるやつ使った方が吉。
多くの場合、いちばんコストがかかるのはビジネスロジックなんだし。

サーバや回線のスペックは富豪的に解決する方向で。

富豪マインド(･∀･)ｲｲ!

確かに、
金かけるだけでいい部分は、金出しときゃいいんだよな。

一番コストがかかるのは教育/学習だったりな

このスレももうすぐ終わりだな。
次スレはここがﾓｼﾞｬｽﾚになるのかな。

ツーか俺様テンプレートとか俺様フレームワークって根本的に意味無い。
俺様しか使わないなら普通に書きまくったほうが早いに決まってる。

まあフレームワークは他人に使ってもらうことを前提としたものだが
フレームワーク的な手法（フロントコントローラパターン、MVCパターン等）は
保守性を桁違いに上げるから無意味とは言えないだろう。

>959
そうだね。
でも速度重視で俺様やるくらいなら、Cで書いたほうがよっぽど良い。
そんな俺はCなんてここ数年触ってない。
学生時代は気が狂ったようにCでガリガリコーディングしてたのに。

>>960
> でも速度重視で俺様やるくらいなら、Cで書いたほうがよっぽど良い。

CでCGI書いちゃったら結局はモジュール版より遅くなりそう。
PHPはZend Optimizer使うとさらに速くなるのかな？よく知らないけど。
ま、アルゴリズムが複雑になってくるとCの方が圧倒的に速いだろうけど、所詮Webだしなぁ。

>>959は同意。

>>958の言ってるのは、実行速度が速いんじゃなくって、開発速度のことだろ。

http://agavi.org/
これ結構よさげ

>>963
どういうところをよさげだと思ったのかぐらい書いてくれよー

次スレどうすんの？
PHPフレームワーク総合？
テンプレ作成よろ＞１

>>964
http://angelicwing.net/diary/4069.html

>>965
�d
たしかによさげだね

>>961
> CでCGI書いちゃったら結局はモジュール版より遅くなりそう。

つ [ FastCGI ]

>>963
お、いいねぇ！
さようならM3・・・

フレームワークの質問ってここでもいいんでしょうか？
Ethnaで認証を作ってるんですけど、

コントローラ→アクション→処理クラス→アクション→ビューという
遷移ですよね？
アクションの中で具体的な処理を書くのはダメみたいなので、
処理クラスを作ってそこで認証の処理をしてるんですけど
そこで、認証してユーザIDを表示したいときには、
呼び出し元のアクションクラス内でSmarty用の値設定をするのか
処理クラスのところで、Smarty用の値設定をするのかどちらが
いいのでしょうか？

PHP自体もよくわかってないところが結構あるので、
くだ質の方のネタかもしれませんけど、よろしくお願いします<m(＿)m>

アガビのAPI見たらM3とほとんど同じに見えるけど
アドバンテージって何？
開発停止していたM3の続きを作ったってことかい？

そろそろM3+PHP5以降するかと考えてたから助かった。

>>970
ほとんど同じなのもメリットのひとつだし、細かいところ良くなってるよ。
例えば、今までたびたび問題になってたクラスの2重定義の問題も、モジュール名を頭につけることで解決されてる。
ファイル名にはつけなくて済むので名前はそこまで長くならないし。
でもやっぱり一番いいのは、Ｍ３と違って「ちゃんと開発進める気がある」ということ。

俺はまだオリフレでいいや
今はどれも依存できる程熟成してないから
考え方をパクってスキルだけ付けといて

俺はagaviでいいや
自分で作ってたら、あとでいいものが出回ったとき効率悪いし

agaviは名前が良くないな。
Mojaviが広まったのは名前の良さもあると思う。

Smarty と Flexyどっちが早いんだ？

>>969
Ethna使ってないけどアクションクラス（かビュー）で設定するもんじゃないのかな。
よく知らないけどEthnaはアクションフォームとかを使うんじゃないの？
リクエストパラメータしか使えないのかな。

>>975
AgaviとMojaviを比べたときに、Mojaviはそんなに良い名前なのか・・・？

「jav」あたりがJavaっぽくて、JavaにあこがれるPHP使いの心をわしづかみ！

Javaにあこがれるくらいなら覚えたら済む話ジャマイカ
どうせデザパタやらはPHP5でこれから必須になるだろうし。

いやPHP5が必須じゃないから。

Mojaviでグローバルフィルタを実行したくない時は
どうすりゃいいの？
Ajax用のJSを吐く時等
ExecutionTimeFilterとかは実行したくないんだけど

>>982
そもそも実行したくない場合があるものをグローバルフィルタにしてること自体おかしいのだが

オリフレでActionとVIewを一つのファイルにまとめて
Viewをなくしたらかなり楽ちんになったよ
ビジネスロジックはLogicが担当するし
同じプレゼンテーション層のActionとViewを分けるのは
冗長と思う。
ビジネスロジックをActionに書くやり方なら
きっちり分けないと気持ち悪いけど。
あとMapleのConverterも取り入れてこれまた便利。
ConverterもValidatorも、Actionからは
設定の連想配列を返せばいいだけ。
後はContorollerの方で各オブジェクトを勝手に作ってくれる。
こんなことが出来るのもオリフレだけ。
オリフレ最高。

うｐきぼｎ

>>977
レス�dクス。
じゃあ処理クラスのところでゲットした値を何かの変数に
いれといて、Viewで設定がいいのかな

>>982
ExecutionTimeFilterを実行したくないならwebapp/config/filters.iniの該当項目をコメントアウトしたら？
自作フィルタで特定のアクション等に対して実行したくないものは、そのフィルタの中でふるいわけるとか。
そもそもExecutionTimeFilterって、「フィルタの使い方のお手本」的な存在だと思ってた。
まあ時間測定もそれなりの意味はあるけど。

>>987
やっぱりフィルタ内で判断するのがいいかな。
ExecutionFilterは処理ごとの重さが判断できるから
開発中は付けてるよ。
DB接続のコストって結構高いんだなーとか思いながら見てる。