[PHP]フレームワークについて語るｽﾚ２[総合]
1 ：nobodyさん：
::フレームワーク一覧::
■Phrame
http://phrame.sourceforge.net/
■Mojavi Project
http://www.mojavi.org/
■Agavi
http://agavi.org/
■[ 日本発 ] Maple Project
http://kunit.jp/maple/
■[ 日本発 ] Ethna -PHPウェブアプリケーションフレームワーク-
http://ethna.jp/ethna-tutorial-startup-practice1.html
■[ 日本発 ] guesswork
http://www.guesswork.jp/
■Biscuit
http://bennolan.com/biscuit/
■PHP on TRAX
http://phpontrax.com/
■Web Application Component Toolkit (WACT)
http://www.phpwact.org/
■symfony
http://www.symfony-project.com/
■XOAD
http://wiki.xoad.org/index.php?title=Wiki_Home
■[ 日本発 ] pokox
http://www.glamenv-septzen.net/pukiwiki/index.php?pokox
■[ 日本発 ] 速構Web Framework
http://www.pm9.com/newpm9/itbiz/php/framework/
■CakePHP
http://cakephp.org/
■Phrame
http://phrame.sourceforge.net/
■Mojavi Project
http://www.mojavi.org/
■Agavi
http://agavi.org/
■[ 日本発 ] Maple Project
http://kunit.jp/maple/
■[ 日本発 ] Ethna -PHPウェブアプリケーションフレームワーク-
http://ethna.jp/ethna-tutorial-startup-practice1.html
■[ 日本発 ] guesswork
http://www.guesswork.jp/
■Biscuit
http://bennolan.com/biscuit/
■PHP on TRAX
http://phpontrax.com/
■Web Application Component Toolkit (WACT)
http://www.phpwact.org/
■symfony
http://www.symfony-project.com/
■XOAD
http://wiki.xoad.org/index.php?title=Wiki_Home
■[ 日本発 ] pokox
http://www.glamenv-septzen.net/pukiwiki/index.php?pokox
■[ 日本発 ] 速構Web Framework
http://www.pm9.com/newpm9/itbiz/php/framework/
■CakePHP
http://cakephp.org/
|
|
|
前スレ貼っとくか
【PHP】フレームワークについて語るスレ【総合】
http://pc8.2ch.net/test/read.cgi/php/1123608068/
>>1
ｽﾚ立て乙
前>>997-999
リンク追加乙
【PHP】フレームワークについて語るスレ【総合】
http://pc8.2ch.net/test/read.cgi/php/1123608068/
>>1
ｽﾚ立て乙
前>>997-999
リンク追加乙
>>1
乙よ乙
乙よ乙
乙ｶﾚｰ
■PHOCOA
http://phocoa.com/
> inspired by Apple's Cocoa and WebObjects technologies.
だそうでMacユーザとしては気になるところ
http://phocoa.com/
> inspired by Apple's Cocoa and WebObjects technologies.
だそうでMacユーザとしては気になるところ
MojaviもAgaviも使う気にならん。
デファクトというにはどちらもまだまだ。
デファクトというにはどちらもまだまだ。
まあ別に無理して使う物でもないしな。
8 ：nobodyさん：2005/12/30(金) 11:45:44 ID:EXAn/jES
agavi は 0.1 が出たのか？
触ってみた人いる？
触ってみた人いる？
MojaviとAgaviが合体する話はどうなったの？
んで、どれを使うといいの？
ドキュメント読んでビビっときたものを使え
今、PHPには使うべきフレームワークというのが無いよね。
JavaにおけるStrutsのような。
PHP5は流行らない・スタンダードとなるフレームワークが
登場しないとくればPHPはかなり苦境だな。
JavaにおけるStrutsのような。
PHP5は流行らない・スタンダードとなるフレームワークが
登場しないとくればPHPはかなり苦境だな。
なんかPHPとJavaが対決してどちらかが勝たねばならないかのような前提で喋る人って多いのね
PHPが流行ってくれないと苦境かもね。
PHPだけで食っていこうとするなら。
PHPだけで食っていこうとするなら。
>>15
PHPだけで食っていく人って給料どれくらいなの？
PHPだけで食っていく人って給料どれくらいなの？
>>16
それを聞いて何と比較するの？
それを聞いて何と比較するの？
>>16
月収50万円程度じゃね？
月収50万円程度じゃね？
PHPだけしかできないようなPGだと、月50は無理でしょ。業務委託だとしても。
まさかJavaよりRubyのほうがスケーラビリティ高いとか言わないよね？
そもそもPHPだって設計きちんとやれば見下ろすほど拡張性低くないのにね。
まあJavaは言語仕様自体が拡張性上げてるようなもんだし。
特異メソッドだの特異クラスだのクロージャだの溢れかえったRubyにスケーラビリティのスの字もないと思うけど。
拡張モジュールをCで書いたりなんてことになると、もうね。
それより、Zend FrameworkはPHPネイティブらしいし、スケーラビリティに関して少しは期待していいかと。
RoRと比べてどうかとかは出てからじゃないと何ともいえないけど。
↑なんかこいつ根本的に勘違いしてるな
そもそもPHPだって設計きちんとやれば見下ろすほど拡張性低くないのにね。
まあJavaは言語仕様自体が拡張性上げてるようなもんだし。
特異メソッドだの特異クラスだのクロージャだの溢れかえったRubyにスケーラビリティのスの字もないと思うけど。
拡張モジュールをCで書いたりなんてことになると、もうね。
それより、Zend FrameworkはPHPネイティブらしいし、スケーラビリティに関して少しは期待していいかと。
RoRと比べてどうかとかは出てからじゃないと何ともいえないけど。
↑なんかこいつ根本的に勘違いしてるな
22 ：nobodyさん：2005/12/31(土) 07:42:47 ID:/O+wCTfO
そもそも PHP は言語仕様が…。
>>24
年間3000円以下でJavaが動く鯖を教えてください
年間3000円以下でJavaが動く鯖を教えてください
agaviはアクションに階層持たせられるようになったのが良
QuickStart Movieにあったようなコマンドラインから実行するやつのwindows版もついてきたね。
前からcygwin経由で使ってたから個人的にはあまり恩恵ないけど、
windowsであれをやってみたかった人は結構いるかも知れない。
前からcygwin経由で使ってたから個人的にはあまり恩恵ないけど、
windowsであれをやってみたかった人は結構いるかも知れない。
>>25
嫌です
嫌です
>>25
年間 3000 円どころか、フリーであるけど。よく探せよ。
年間 3000 円どころか、フリーであるけど。よく探せよ。
新年早々どうでもいいよそんなこと。
34 ：nobodyさん：2006/01/01(日) 07:08:28 ID:WHqdtVTb
>>30
3000円もフリーも大して変わんねぇよ、貧乏人。
3000円もフリーも大して変わんねぇよ、貧乏人。
>>26
agaviってモジュールの方は階層持たせられるっけ？
agaviってモジュールの方は階層持たせられるっけ？
フリーを除いて、年間3000円以下でJava使える鯖ってあるのか？
まぁ、レン鯖板で聞けって話か
まぁ、レン鯖板で聞けって話か
どうしてスレ違いのネタを引き伸ばそうとするの？
安上がりでJava使いたいのは結構だけど、お前の居場所はこのスレじゃない。
安上がりでJava使いたいのは結構だけど、お前の居場所はこのスレじゃない。
JavaにはStrutsやJSFなどのスタンダードとなるフレームワークがあるのに
PHPにはそれがないねぇ。
PHPにはそれがないねぇ。
速構Web Framework は目からうろこでした。
わたくしは一生をささげます。Mojavi よさらば。
わたくしは一生をささげます。Mojavi よさらば。
商用利用時のライセンスがややこしそうだけど、そこさえクリアできればよさそうだね。
PHPはクラスライブラリが整備されないからね。いつまでたっても。
43 ：nobodyさん：2006/01/02(月) 03:33:36 ID:I7zXcpPd
>>40
どのへんが画期的だったのか良ければ教えて
どのへんが画期的だったのか良ければ教えて
そんなどこの馬の骨かもわからないフレームワークなんか
誰も使わないと思うよ。
誰も使わないと思うよ。
って、PHP-Screw出してるとこだろ?
zend frameworkの公式ページってどこよ?
検索しても出てこないのだが
検索しても出てこないのだが
たぶんここが一番それっぽいかな
http://www.zend.com/collaboration
ZPFのまとめページみたいのも用意されてるけど、まだこの前のwebcastの要約程度の内容しかないよ。
http://www.zend.com/collaboration
ZPFのまとめページみたいのも用意されてるけど、まだこの前のwebcastの要約程度の内容しかないよ。
ドキュメント出すとか言ってたのに全然ださねーな
Zend Frameworkの開発に関わっているのが以下の企業だよね?
IBM, Oracle, MySQL, Intel, Actuate, ADP, FileMaker, Schematic,
StepUp Commerce, OmniTI, 100days.de, SugarCRM, bebe.com,
and Marco Tabini, publisher of PHP Architect Magazine
日本の企業が全く入っていないな…
中小企業でもはいっとけばいいのに
Zend Frameworkの開発に関わっているのが以下の企業だよね?
IBM, Oracle, MySQL, Intel, Actuate, ADP, FileMaker, Schematic,
StepUp Commerce, OmniTI, 100days.de, SugarCRM, bebe.com,
and Marco Tabini, publisher of PHP Architect Magazine
日本の企業が全く入っていないな…
中小企業でもはいっとけばいいのに
チケット、トークンシステムってどうしてる?
50 ：nobodyさん：2006/01/04(水) 12:13:25 ID:ST4/dfIz
ウェブ開発のフレームワークに、そんな大企業がウジャウジャ一緒に開発してるわけないじゃん。
なんだかんだで、まだMojavi。
アガビがいいー
アガビがいいけど、はやらない。
Zend Frameworkははやるかな？
現状だとやっぱAgaviかな。
使いやすいよ。
使いやすいよ。
agaviでググってもほとんど情報が無いんだが。。。
日本人向きだとmaple ethnaあたりがよさそうかねぇ。
日本人向きだとmaple ethnaあたりがよさそうかねぇ。
Agavi使うくらいなら、Symfonyのほうがドキュメントも充実しているしよさげ。
mojaviでsmarty使う時、action filterでregistしてる? Viewをextendしてる?
Viewをextendかな。
かなりぴったりハマるしこれでいいやって思ってたけど、action filterでregistってのはどういうことなの？
かなりぴったりハマるしこれでいいやって思ってたけど、action filterでregistってのはどういうことなの？
Mojavi以外を使う勇気が欲しい
mojaviを使った勇気が欲しい・・・
mojaviなら誰でも使えるよ。 ググッて、がんがれ。
母｢おい、おまいら！！あすたからフレームワーク使いまつ。勉強しる｣
父｢ﾈﾀ詳細ｷﾎﾞﾝﾇ！｣
母｢mojaviですが、何か?｣
兄｢ｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━！！！｣
妹｢ｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━！！！｣
姉｢＞兄＞妹 ｹｺｰﾝ｣
兄｢＞妹(;´Д｀)ﾊｧﾊｧ…｣
妹｢ｷﾓｲﾖ━！！｣
姉｢ﾊﾞ㌍ﾀ逝ってよし｣
母｢オマエモナー｣
父｢--------終了-------｣
兄｢--------再開-------｣
妹｢再開すな！ｳﾞｫｹが！！それより情報うpｷﾎﾞﾝ｣
母｢URLうp｣
兄｢guesswork age｣
母｢↑誤爆ｽﾏｿ｣
兄｢guesswork age｣
父｢ほらよ＞プロジェクトメンバー｣
妹｢神降臨！！｣
兄｢guesswork age｣
妹｢肉ねーよ！！｣
兄｢guesswork age｣
父｢肉ねーよ！！｣
兄｢guesswork age｣
母｢ｼﾞｻｸｼﾞｴﾝｶｺﾜﾙｲ｣
兄｢guesswork age｣
姉｢guesswork age厨uzeeeeeeeeeeee！！｣
母｢ageっていれればあがると思ってるヤシはﾄﾞｷｭｿ｣
爺｢mojaviは日本語サイトがないと(mojaviを美味しく食べるのは)難しい｣
ｾｰﾙｽ｢ｲﾀｲ リーダーがいるのはこのプロジェクトですか?｣
兄｢guesswork age｣
妹｢兄必死だな(w｣
父｢ﾈﾀ詳細ｷﾎﾞﾝﾇ！｣
母｢mojaviですが、何か?｣
兄｢ｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━！！！｣
妹｢ｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━！！！｣
姉｢＞兄＞妹 ｹｺｰﾝ｣
兄｢＞妹(;´Д｀)ﾊｧﾊｧ…｣
妹｢ｷﾓｲﾖ━！！｣
姉｢ﾊﾞ㌍ﾀ逝ってよし｣
母｢オマエモナー｣
父｢--------終了-------｣
兄｢--------再開-------｣
妹｢再開すな！ｳﾞｫｹが！！それより情報うpｷﾎﾞﾝ｣
母｢URLうp｣
兄｢guesswork age｣
母｢↑誤爆ｽﾏｿ｣
兄｢guesswork age｣
父｢ほらよ＞プロジェクトメンバー｣
妹｢神降臨！！｣
兄｢guesswork age｣
妹｢肉ねーよ！！｣
兄｢guesswork age｣
父｢肉ねーよ！！｣
兄｢guesswork age｣
母｢ｼﾞｻｸｼﾞｴﾝｶｺﾜﾙｲ｣
兄｢guesswork age｣
姉｢guesswork age厨uzeeeeeeeeeeee！！｣
母｢ageっていれればあがると思ってるヤシはﾄﾞｷｭｿ｣
爺｢mojaviは日本語サイトがないと(mojaviを美味しく食べるのは)難しい｣
ｾｰﾙｽ｢ｲﾀｲ リーダーがいるのはこのプロジェクトですか?｣
兄｢guesswork age｣
妹｢兄必死だな(w｣
責任転嫁してますよ
mojaviが主流で、割とユーザー数多そうなmaple あたりかな。
今後もこの流れだと思う。
今後もこの流れだと思う。
>>69
あーM2の話だったのか。
M2だとSmartyRendererが用意されてるから、その初期化をfilterでやるのが普通なのかも（俺はM2経験ない）。
M3の場合だとSmartyViewっていうのが入ってるけど、まだ中身が何も実装されてない状態だったから自分で書いた。
基本的にM2のSmartyRendererと一緒で、$smarty->assignとかのラッパを書いたってだけの話だけど。
Agaviでは実装済みだね。
要は>>61の質問は結局はM2かM3かって話になると思う。
あーM2の話だったのか。
M2だとSmartyRendererが用意されてるから、その初期化をfilterでやるのが普通なのかも（俺はM2経験ない）。
M3の場合だとSmartyViewっていうのが入ってるけど、まだ中身が何も実装されてない状態だったから自分で書いた。
基本的にM2のSmartyRendererと一緒で、$smarty->assignとかのラッパを書いたってだけの話だけど。
Agaviでは実装済みだね。
要は>>61の質問は結局はM2かM3かって話になると思う。
HTML_QuickFromのフォーム関連の処理はどこへ置いていますか?
forms/ 以下にまとめているものをよくありますがactionsでかいちゃう人もいるようです。
僕はmodelの下で executeForm()で処理させようかと思っていますがどうでしょうか?
forms/ 以下にまとめているものをよくありますがactionsでかいちゃう人もいるようです。
僕はmodelの下で executeForm()で処理させようかと思っていますがどうでしょうか?
73 ：nobodyさん：2006/01/08(日) 02:44:47 ID:MOiqJ8HA
eZ systemsってどうよ？
Zend PHP Frameworkの一番の宿敵になりそうって言われてるけど。
http://ez.no/
mod_rewrite使ってるのあたりが個人的に微妙。
eZ publishはドキュメントとかやたら張り切って書いてあるわりにサンプルコードが少なくて、結局使い方がイマイチわからなかったよ・・・。
機能が豊富そうっていう印象はあったけど。
eZ componentsは要はクラスライブラリ群？
Zend PHP Frameworkの一番の宿敵になりそうって言われてるけど。
http://ez.no/
mod_rewrite使ってるのあたりが個人的に微妙。
eZ publishはドキュメントとかやたら張り切って書いてあるわりにサンプルコードが少なくて、結局使い方がイマイチわからなかったよ・・・。
機能が豊富そうっていう印象はあったけど。
eZ componentsは要はクラスライブラリ群？
>>72
モノは良いと思うんだけど……
とにかくドキュメントやサンプルが不足すぎて手を出しにくいこと、
作者がアレコレ色々なものに手を出していて完成品が全然出てこないこと、
利用者コミュニティがブログ周辺で完結してしまっていて参加しにくいこと、
などなどから、利用者はさほど多くない雰囲気。
気に入らないコードを自分でばんばん書き換えちゃえるくらいだと
けっこう良いフレームワークだと思う。
モノは良いと思うんだけど……
とにかくドキュメントやサンプルが不足すぎて手を出しにくいこと、
作者がアレコレ色々なものに手を出していて完成品が全然出てこないこと、
利用者コミュニティがブログ周辺で完結してしまっていて参加しにくいこと、
などなどから、利用者はさほど多くない雰囲気。
気に入らないコードを自分でばんばん書き換えちゃえるくらいだと
けっこう良いフレームワークだと思う。
仕事で使ってるけど、良く出来てると思うよ。
ドキュメントないからソース読めないと困るかもしれないけど。
ドキュメントないからソース読めないと困るかもしれないけど。
ソースを読まないとどうにも進まないのは大抵のフレームワークに言えるねぇ。
良いものでも、「Hello world を出力してみよう」ってくらいで・・・
良いものでも、「Hello world を出力してみよう」ってくらいで・・・
フレームワークって楽に開発するための物なんだから、少なくとも
ソースを読むことが必須な状態からは脱却してほしい。
いろんなレベルの人と協業するのに今の状態では辛すぎる。
ソースを読むことが必須な状態からは脱却してほしい。
いろんなレベルの人と協業するのに今の状態では辛すぎる。
ドキュメント化しよう、とは思わないんだね
>>79
誰に向かっての発言なのかわからん
誰に向かっての発言なのかわからん
ZPFが出れば流れも変わるんじゃない？
Extreme Simplicityとか謳ってるくらいだし。
.NET、Struts、RoRのパクリがほとんどで真新しいものはないけど、逆にPHPでそれらが全て利用可能になるってのは大きいんじゃないかな。
PHPらしく多くをベタ書きで書きつつ自然にフレームワークの恩恵に与れるっていう形になるんじゃないかと。
今あるフレームワークはどれも癖のあるクラス設計を強いられるから、PHPらしくないんだよね。
Extreme Simplicityとか謳ってるくらいだし。
.NET、Struts、RoRのパクリがほとんどで真新しいものはないけど、逆にPHPでそれらが全て利用可能になるってのは大きいんじゃないかな。
PHPらしく多くをベタ書きで書きつつ自然にフレームワークの恩恵に与れるっていう形になるんじゃないかと。
今あるフレームワークはどれも癖のあるクラス設計を強いられるから、PHPらしくないんだよね。
Zendフレームワークって
ｴｸｽﾊﾟﾝｼｮﾝなのかなあ？
ｴｸｽﾊﾟﾝｼｮﾝなのかなあ？
>>81
Zendのフレームワークも、べた書きなんてありえないバリバリのOOデザイン
だとおもうよ。なにせあのPHP5を作ったZendだからね...
>>82
PHPの拡張ってこと?
そうすっと今度は微妙な振る舞いをCソースがよめないせいで確認できなくて
困る人が多発する気が...
Zendのフレームワークも、べた書きなんてありえないバリバリのOOデザイン
だとおもうよ。なにせあのPHP5を作ったZendだからね...
>>82
PHPの拡張ってこと?
そうすっと今度は微妙な振る舞いをCソースがよめないせいで確認できなくて
困る人が多発する気が...
Zendのフレームワークみたら、PEARとか全然生かしてなさそうだね。
>>82
ｴｸｽﾊﾟﾝｼｮﾝ == extension ?
Webcastでは全てPHPでオープンソースで書くって言ってた希ガス
>>83
そうかなぁ。
フレームワークのコード自体はOOで書いてあっても、我々ユーザにはOOの設計を強要しないって感じになってもらえるとありがたいんだけど（つまりOOは「使う」だけであって「作る」必要がないって感じ）。
フレームワークのコンポーネントを最小限の部分だけ継承して２～３行ちょろっと書いとけばあとは勝手に動いてくれる、みたいな。
>>84
Pearはおろか既存のものはSmartyなども含めて一切使わない方針で、完全に独自の設計になるらしい。
テンプレートも独自のものみたいだし。
そこに批判もけっこうあるみたいだけど。
ｴｸｽﾊﾟﾝｼｮﾝ == extension ?
Webcastでは全てPHPでオープンソースで書くって言ってた希ガス
>>83
そうかなぁ。
フレームワークのコード自体はOOで書いてあっても、我々ユーザにはOOの設計を強要しないって感じになってもらえるとありがたいんだけど（つまりOOは「使う」だけであって「作る」必要がないって感じ）。
フレームワークのコンポーネントを最小限の部分だけ継承して２～３行ちょろっと書いとけばあとは勝手に動いてくれる、みたいな。
>>84
Pearはおろか既存のものはSmartyなども含めて一切使わない方針で、完全に独自の設計になるらしい。
テンプレートも独自のものみたいだし。
そこに批判もけっこうあるみたいだけど。
ちょっとしたもんに使える、手軽な奴ってない？
使ったことないけどguessworkとかCakePHPとか。
フレームワークとか使ったことなくて、
とりあえずmaple見てみたんだけど、なんかディレクトリ深すぎない？
設定とかで変えれるのかも知れないが、
あっち行ったりこっち行ったり面倒なような。
どんな環境でどのくらいのファイル数になるのを想定してるのかな…。
とりあえずmaple見てみたんだけど、なんかディレクトリ深すぎない？
設定とかで変えれるのかも知れないが、
あっち行ったりこっち行ったり面倒なような。
どんな環境でどのくらいのファイル数になるのを想定してるのかな…。
補足。特に批難とかしたい訳じゃなくて、
単にああいう構成になってる理由が疑問って話。
他のは違うのかもしれんが…。
単にああいう構成になってる理由が疑問って話。
他のは違うのかもしれんが…。
>>88
少ないディレクトリにファイルがゴッソリあるよりマシ。
少ないディレクトリにファイルがゴッソリあるよりマシ。
agavi
UPDATE 2005-01-08: 0.10.1b has been released!
UPDATE 2005-01-08: 0.10.1b has been released!
>>86
cakeの場合、データ構造が単純ならscaffoldingが使えるから、死ぬほどお手軽。
cakeの場合、データ構造が単純ならscaffoldingが使えるから、死ぬほどお手軽。
Mapleは
ｵﾚｵﾚフレームワークのたたき台を目指してるみたいだね。
標準になるべくZendフレームワークが出てきたので
戦略的に正しいと思う。
ｵﾚｵﾚフレームワークのたたき台を目指してるみたいだね。
標準になるべくZendフレームワークが出てきたので
戦略的に正しいと思う。
>>92
いや、88ともダブるんだけどさ、なんかみんな大げさすぎない？
そういうのが必要な場合があるってのは分かるんだけどさ、、
ちょっとしたもん書く時にさ、ベタで書くより
なんちゃってMVCにしとけば、楽じゃん？みたいな感じなのないかな。
逆流してる？
いや、88ともダブるんだけどさ、なんかみんな大げさすぎない？
そういうのが必要な場合があるってのは分かるんだけどさ、、
ちょっとしたもん書く時にさ、ベタで書くより
なんちゃってMVCにしとけば、楽じゃん？みたいな感じなのないかな。
逆流してる？
カウンター作成専用のフレームワークつーのには興味無いな。
そのフレームワークが対象とするもののうち一番大掛かりなものになるのは当然と思われ。
そのフレームワークが対象とするもののうち一番大掛かりなものになるのは当然と思われ。
フレームワークはリロード対策とかしれくれないのか？
>>96
MapleにはTokenフィルタってのがあるね
MapleにはTokenフィルタってのがあるね
mojaviのaction.class.phpの上にあるライセンス表示って別に残さなくてもいいんだよね?
>>98
mojaviを改造でもしてんの？そうでなかったら編集する必要すらないと思うけど。
一応LGPLだしランセンス表示を含めどんな改変をしても構わないけど、改変後のプログラムはGPLかLGPLのもとでオープンソースとして再頒布しなきゃいけないんじゃないかな。
間違ってたら訂正よろ。
mojaviを改造でもしてんの？そうでなかったら編集する必要すらないと思うけど。
一応LGPLだしランセンス表示を含めどんな改変をしても構わないけど、改変後のプログラムはGPLかLGPLのもとでオープンソースとして再頒布しなきゃいけないんじゃないかな。
間違ってたら訂正よろ。
LGPL表記と著作権表示を削るのは多分よくないでしょう。空のファイルでもLGPL配布物の一部ならば。
ここは堂々と著作権者に自分の名前を追記して配布汁。
頒布っていうか、べつに広く配布する必要は無いし、ソースを売って金にしてもいいけど、
そのソースコードをもらった人にLGPLによるソース再配布の権利を認めないといけない。
だからLGPLコードを暗号化して顧客に納品しちゃダメ
...て感じだと思う。
ここは堂々と著作権者に自分の名前を追記して配布汁。
頒布っていうか、べつに広く配布する必要は無いし、ソースを売って金にしてもいいけど、
そのソースコードをもらった人にLGPLによるソース再配布の権利を認めないといけない。
だからLGPLコードを暗号化して顧客に納品しちゃダメ
...て感じだと思う。
>>100
なるほど。フォローサンクス。
ちょっと気になったけど、LGPLはソース保持者が配布することができる「権利」ではなくて、（要望があれば必ず）配布しなければならないことを使用条件とする（というか強要する）ものじゃないかな。
だから売って金にするってのはまずいのでは？
なるほど。フォローサンクス。
ちょっと気になったけど、LGPLはソース保持者が配布することができる「権利」ではなくて、（要望があれば必ず）配布しなければならないことを使用条件とする（というか強要する）ものじゃないかな。
だから売って金にするってのはまずいのでは？
成果物(ソフトウェア)の所有者にのみソース公開の義務が生じるだけだから、
広く一般に公開する必要は必ずしもあるわけじゃない。どんな高い金で売ってもOK
ただし、ソースをもらった方はLGPLに基づきいくらでも再配布出来る。そしてそれを縛ることはできない。
広く一般に公開する必要は必ずしもあるわけじゃない。どんな高い金で売ってもOK
ただし、ソースをもらった方はLGPLに基づきいくらでも再配布出来る。そしてそれを縛ることはできない。
LGPLで言う所の、"work based on the library(ライブラリを基にした著作物)" と
"work that uses the library(ライブラリを利用した著作物)"は違うから、
mojavi部分と独自のビジネスロジック部分とを分離して独自部分を配布する場合は
LGPLの範疇にならないんじゃないかなぁ。
まぁ、>>98のライセンス表示削除は確実にアウトですが。。。
"work that uses the library(ライブラリを利用した著作物)"は違うから、
mojavi部分と独自のビジネスロジック部分とを分離して独自部分を配布する場合は
LGPLの範疇にならないんじゃないかなぁ。
まぁ、>>98のライセンス表示削除は確実にアウトですが。。。
mojaviをフレームワークとして通常の利用する分には今の話の流れとは関係ないよ（GPLではないのでこれらは売ろうが隠蔽しようが公開しようが自由だと思う）。
飽くまでmojaviを改変した場合の話。
ライセンス表示は削除したとしても、新たにLGPLの全文か全文へのポインタ相当のものを示せばいいんじゃないの？
著作者の表示に関しては、元の著作者（mojaviの場合Sean Kerr）を載せる必要ってあったっけ？
PHP Licenseだとそういうのは明示的に書かなきゃダメってなってるけどLGPLはそういう項目ある？
飽くまでmojaviを改変した場合の話。
ライセンス表示は削除したとしても、新たにLGPLの全文か全文へのポインタ相当のものを示せばいいんじゃないの？
著作者の表示に関しては、元の著作者（mojaviの場合Sean Kerr）を載せる必要ってあったっけ？
PHP Licenseだとそういうのは明示的に書かなきゃダメってなってるけどLGPLはそういう項目ある？
変更する場合は変更箇所の明示と著作権の追加をすべしっていう項があった気がする。
ライセンスはどうか知らないけど、ファイル中の著作権表記の削除はGPL以前に著作権的によくないと思う。
あと、一緒に配布するかぎりはLGPLでもGPL的縛りを逃れられないような...
このへんの成果物の扱いはGPL/LGPLで記憶も理解も混乱しているのでよくわからん。
ライセンスはどうか知らないけど、ファイル中の著作権表記の削除はGPL以前に著作権的によくないと思う。
あと、一緒に配布するかぎりはLGPLでもGPL的縛りを逃れられないような...
このへんの成果物の扱いはGPL/LGPLで記憶も理解も混乱しているのでよくわからん。
というかMojaviを改変したわけでなく、新しくLoginAction.class.phpなどを
自分で作ったのです。
それの著作権は自分にあるのでサンプルにあるような著作権表示は削除しても
いいと思っていたのですがどうですか?
または、Mojaviからextendsしたファイルとかはどうなるんでしょうかね。
要らないと思っていたんですが、違うのかな。
自分で作ったのです。
それの著作権は自分にあるのでサンプルにあるような著作権表示は削除しても
いいと思っていたのですがどうですか?
または、Mojaviからextendsしたファイルとかはどうなるんでしょうかね。
要らないと思っていたんですが、違うのかな。
>>106
たしかに著作権の表記を削除ってのは仁義的にもよろしくないな。
なんかpublic domainとか著作権放棄とかの話がごっちゃになってた。
GPLかLGPLかはwork that uses the libraryにも同じ制限が課されるかってのがあると思った。
LGPLの場合はmojaviを使用するだけなら、その使用したコードにはLGPLの制限は一切かからないんじゃないかな。
以下はLGPLのTERMS AND CONDITIONS ～ から一部抜粋。
> 5. A program that contains no derivative of any portion of the Library, but is
> designed to work with the Library by being compiled or linked with it, is
> called a "work that uses the Library". Such a work, in isolation, is not a
> derivative work of the Library, and therefore falls outside the scope of this
> License.
コンパイルやリンクってPHPには適用しづらいけど、include/require等によって使うことと考えて差し支えないと思う。
たしかに著作権の表記を削除ってのは仁義的にもよろしくないな。
なんかpublic domainとか著作権放棄とかの話がごっちゃになってた。
GPLかLGPLかはwork that uses the libraryにも同じ制限が課されるかってのがあると思った。
LGPLの場合はmojaviを使用するだけなら、その使用したコードにはLGPLの制限は一切かからないんじゃないかな。
以下はLGPLのTERMS AND CONDITIONS ～ から一部抜粋。
> 5. A program that contains no derivative of any portion of the Library, but is
> designed to work with the Library by being compiled or linked with it, is
> called a "work that uses the Library". Such a work, in isolation, is not a
> derivative work of the Library, and therefore falls outside the scope of this
> License.
コンパイルやリンクってPHPには適用しづらいけど、include/require等によって使うことと考えて差し支えないと思う。
と思ったけど、「in isolation」ってなってるな・・・。
mojavi使って作ったソースって、GPL/LGPLを明記する義務があって且つ再配布されても文句言えないってこと？
なんかわからなくなってきた。
mojavi使って作ったソースって、GPL/LGPLを明記する義務があって且つ再配布されても文句言えないってこと？
なんかわからなくなってきた。
work と Library を まじぇまじぇして配布するなってことでしょ？
まじぇまじぇさえしなければLGPLの呪縛から完全に逃れられるってこと？（mojavi本体がLGPLなことは除いて）
Mojaviみたいなフレームワークの場合、APIのみ同じであるようなフレームワークを
自分であらたに開発すればいいので、それを使うスクリプトは独立しているとみなしていいはず。
だから、自分の製品の一部に組み込んでmojaviを配布する場合はLGPL縛りで、
独立したものとして配布する場合のライセンスは自由なんじゃないかな。
スクリプトの場合、全部のファイルが独立しているという見方も出来るから、
このへんは難しいとこだとおもうけど。
自分であらたに開発すればいいので、それを使うスクリプトは独立しているとみなしていいはず。
だから、自分の製品の一部に組み込んでmojaviを配布する場合はLGPL縛りで、
独立したものとして配布する場合のライセンスは自由なんじゃないかな。
スクリプトの場合、全部のファイルが独立しているという見方も出来るから、
このへんは難しいとこだとおもうけど。
紛らわしいこと書いて失礼・・・
> Such a work, in isolation, is not a derivative work
ってのはmojaviを使った著作物「単体」では派生物と見なさない（つまり著作物＋mojaviをひっくるめて「派生物と見なさない」わけではないってことをin isolationで単に明示してる）って意味っぽい。
つまりmojaviを使用することを前提にしてつくったActionとかViewとかModelとかはLGPLの影響は一切ないってことかな。
>>107
というわけで自分で作ったActionにはLGPLやSean Kerrは必要ないと思う。
> Such a work, in isolation, is not a derivative work
ってのはmojaviを使った著作物「単体」では派生物と見なさない（つまり著作物＋mojaviをひっくるめて「派生物と見なさない」わけではないってことをin isolationで単に明示してる）って意味っぽい。
つまりmojaviを使用することを前提にしてつくったActionとかViewとかModelとかはLGPLの影響は一切ないってことかな。
>>107
というわけで自分で作ったActionにはLGPLやSean Kerrは必要ないと思う。
ActionとModelの違いって何？
Action＝親方
Model＝作業員
Model＝作業員
116 ：nobodyさん：2006/01/11(水) 02:52:36 ID:0BNMEQyQ
フレームワークで作ってたら、
どこか変更する必要がある時、
「どのファイルをいじったらいいのか？」が
パッとイメージしにくくない？
とりあえずAction開いて、
そこから読んでるけど。
何かいい方法ないかなぁ…。
どこか変更する必要がある時、
「どのファイルをいじったらいいのか？」が
パッとイメージしにくくない？
とりあえずAction開いて、
そこから読んでるけど。
何かいい方法ないかなぁ…。
フレームワークで分けられてるだけマシだと思ってやってる。
118 ：nobodyさん：2006/01/11(水) 07:49:18 ID:SLuQbgaX
>>116
保守性を考えるならまともな仕様書/設計書を残しておけ。
保守性を考えるならまともな仕様書/設計書を残しておけ。
>>114
共通点のほうが見つからないじゃん
共通点のほうが見つからないじゃん
>>119
それぞれの役割は何か答えよ。
それぞれの役割は何か答えよ。
122 ：nobodyさん：2006/01/11(水) 22:58:55 ID:0mCKrO3o
agavi使ってるんだけど、エラー処理どうしてる？
action の initialize で false を返すとexception投げて来るんだけど、
どこでどうやって捕捉すればいいのかわかんね。
action の initialize で false を返すとexception投げて来るんだけど、
どこでどうやって捕捉すればいいのかわかんね。
123 ：nobodyさん：2006/01/11(水) 23:01:22 ID:SURfFh1U
>>115
ﾜﾛﾀ
ﾜﾛﾀ
124 ：nobodyさん：2006/01/12(木) 09:51:00 ID:9A+OuFoz
Agaviサイトが…
ttp://agavi.org/
ParseException
Message: Configuration file "/var/www/sites/agavi.org/webapp/config/autoload.ini"
specifies class "MailAppender" with nonexistent or unreadable file
"/var/www/agavi/logging/MailAppender.class.php"
Code: N/A
Class: AutoloadConfigHandler
File: /var/www/agavi/config/AutoloadConfigHandler.class.php
Line: 7
ttp://agavi.org/
ParseException
Message: Configuration file "/var/www/sites/agavi.org/webapp/config/autoload.ini"
specifies class "MailAppender" with nonexistent or unreadable file
"/var/www/agavi/logging/MailAppender.class.php"
Code: N/A
Class: AutoloadConfigHandler
File: /var/www/agavi/config/AutoloadConfigHandler.class.php
Line: 7
mojavi2でのポストフィルタの使い方がわかりません。
GlobalFilterでregistして、executeのあとに処理を書けばいいんでしょうか?
googleで3時間程検索しましたが全然出てきませんでした。
よろしくお願いします。
GlobalFilterでregistして、executeのあとに処理を書けばいいんでしょうか?
googleで3時間程検索しましたが全然出てきませんでした。
よろしくお願いします。
>>126
こんな感じになるんじゃないかな。
<filter>.class.php
class <filter名> extends Filter{
function execute(&$filterChain,&$controller,&$request,&$user){
static $loaded;
// ActionChainやAction::forwardを使った時にフィルタが複数回適用されるのを防ぐ
if($loaded == NULL){
$loaded = TRUE;
// 前処理フィルタ
...
// filter chain の次のフィルタを実行
// pre-filterとpost-filterの分岐点
$filterChain->execute($controller,$request,$user);
// 後処理フィルタ
...
}else{
$filterChain->execute($controller,$request,$user);
}
}
}
こんな感じになるんじゃないかな。
<filter>.class.php
class <filter名> extends Filter{
function execute(&$filterChain,&$controller,&$request,&$user){
static $loaded;
// ActionChainやAction::forwardを使った時にフィルタが複数回適用されるのを防ぐ
if($loaded == NULL){
$loaded = TRUE;
// 前処理フィルタ
...
// filter chain の次のフィルタを実行
// pre-filterとpost-filterの分岐点
$filterChain->execute($controller,$request,$user);
// 後処理フィルタ
...
}else{
$filterChain->execute($controller,$request,$user);
}
}
}
128 ：nobodyさん：2006/01/12(木) 16:47:35 ID:9A+OuFoz
>>127,128
ありがとうございます。
Googleでも同じようなことが書いてあったのですがそれでもよくわからないの
です。
> $filterChain->execute($controller,$request,$user);
> // 後処理フィルタ
この後に処理を書いたものが「Viewの後に」実行されるという認識であってますか?
何個もFilterを使っている場合、どのフィルタの中で処理を書けばいいかが
わからないです。
最後に処理されるフィルタのところで書くような気がするのですが、そのような
記述をしているところがありませんでした。
ありがとうございます。
Googleでも同じようなことが書いてあったのですがそれでもよくわからないの
です。
> $filterChain->execute($controller,$request,$user);
> // 後処理フィルタ
この後に処理を書いたものが「Viewの後に」実行されるという認識であってますか?
何個もFilterを使っている場合、どのフィルタの中で処理を書けばいいかが
わからないです。
最後に処理されるフィルタのところで書くような気がするのですが、そのような
記述をしているところがありませんでした。
>>129
前スレあたりに書いたのにちょっと手を加えたものを再掲すると、
個々のフィルタには前処理・後処理という2段階の実行順序があって、
登録した順に前処理が全て実行されてから、今度は逆順に後処理が実行される。
Actionの実行部分もフィルタの一種として扱われていて(ExecutionFilter)、
全てのフィルタの登録後に登録されている。
Viewの実行(View::execute())はExecutionFilterの中で実行されている。
結果、登録順に1,2...の番号を付けた時に、
1. GlobalFilterのpre-filter1,pre-filter2...を実行
2. moduleFilterのpre-filter1,pre-filter2...を実行
3. ExecutionFilterを実行(認証や特権の判定、action処理)
4. Viewの実行
5. moduleFilterの...post-filter2,post-filter1を実行
6. GlobalFilterの...post-filter2,post-filter1を実行
という順番で処理されることになる。
前スレあたりに書いたのにちょっと手を加えたものを再掲すると、
個々のフィルタには前処理・後処理という2段階の実行順序があって、
登録した順に前処理が全て実行されてから、今度は逆順に後処理が実行される。
Actionの実行部分もフィルタの一種として扱われていて(ExecutionFilter)、
全てのフィルタの登録後に登録されている。
Viewの実行(View::execute())はExecutionFilterの中で実行されている。
結果、登録順に1,2...の番号を付けた時に、
1. GlobalFilterのpre-filter1,pre-filter2...を実行
2. moduleFilterのpre-filter1,pre-filter2...を実行
3. ExecutionFilterを実行(認証や特権の判定、action処理)
4. Viewの実行
5. moduleFilterの...post-filter2,post-filter1を実行
6. GlobalFilterの...post-filter2,post-filter1を実行
という順番で処理されることになる。
>>130
詳しい説明ありがとうございます。
動作順序がよくわかりました
なんでそういう複雑な感じになってるかはよくわかりませんがw
検索用用語
プリフィルタ ポストフィルタ prefilter postfilter mojavi2
詳しい説明ありがとうございます。
動作順序がよくわかりました
なんでそういう複雑な感じになってるかはよくわかりませんがw
検索用用語
プリフィルタ ポストフィルタ prefilter postfilter mojavi2
132 ：nobodyさん：2006/01/12(木) 21:57:58 ID:9A+OuFoz
>>131
>検索用用語
>プリフィルタ ポストフィルタ prefilter postfilter mojavi2
mojavi filter だけである程度答えでてくるよ。
ttp://www.google.co.jp/search?hl=ja&c2coff=1&q=mojavi+filter&btnG=Google+%E6%A4%9C%E7%B4%A2&lr=lang_ja
>検索用用語
>プリフィルタ ポストフィルタ prefilter postfilter mojavi2
mojavi filter だけである程度答えでてくるよ。
ttp://www.google.co.jp/search?hl=ja&c2coff=1&q=mojavi+filter&btnG=Google+%E6%A4%9C%E7%B4%A2&lr=lang_ja
mojaviのlibとoptに入れるものってどうやって分けるの?
>>135
それは君が決めること。
ExecutionTimeFilter.class.php(配布物に含まれる実行時間を計測するやつ)の場合、
ob_start();
... // GlobalFilterに使った場合、一番最初に呼び出される。タイマー初期化
$filterChain->execute($controller, $request, $user);
... // Glo(ry 。実行時間を計算。
ob_clean();
echo "～"; // ob_*でバッファに取り込んだものと、計算した実行時間を合わせて出力
ってな感じで使っている。
それは君が決めること。
ExecutionTimeFilter.class.php(配布物に含まれる実行時間を計測するやつ)の場合、
ob_start();
... // GlobalFilterに使った場合、一番最初に呼び出される。タイマー初期化
$filterChain->execute($controller, $request, $user);
... // Glo(ry 。実行時間を計算。
ob_clean();
echo "～"; // ob_*でバッファに取り込んだものと、計算した実行時間を合わせて出力
ってな感じで使っている。
137 ：nobodyさん：2006/01/15(日) 03:11:54 ID:/IaCdmhr
フレームワーク使ってると
仕込む場所と
使う場所が離れてるから、
知らないうちに使われない変数やオブジェクトが
増えて行ったりしない？
あといつの間にか使わなくなった関数とかも増えがちだ。
仕込む場所と
使う場所が離れてるから、
知らないうちに使われない変数やオブジェクトが
増えて行ったりしない？
あといつの間にか使わなくなった関数とかも増えがちだ。
誰か俺に一からフレームワーｋとオブジェクト指向について教えろ！
本でも読め
>>137
つ転職
つ転職
いや
1:テンプレートにassign
2:テンプレート側の変更で使わなくなる
3:assignはされたまま
みたいなことないかい？
1:テンプレートにassign
2:テンプレート側の変更で使わなくなる
3:assignはされたまま
みたいなことないかい？
あと使わなくなったリクエストパラメータの
バリデータが残りっぱなしみたいなこととか。
バリデータが残りっぱなしみたいなこととか。
>>142
俺もあると思うよ
俺もあると思うよ
145 ：324：2006/01/16(月) 01:05:52 ID:VcFB/Doi
>142
すごい巨大な配列とかなら気にするけど、
普通のデータだったら、いちいちそんな細かい事気にしてられません。
すごい巨大な配列とかなら気にするけど、
普通のデータだったら、いちいちそんな細かい事気にしてられません。
>>147
テンプレートで使わない変数は渡さないって考え自体が分離を阻害している希ガス。
テンプレートで使わない変数は渡さないって考え自体が分離を阻害している希ガス。
使わない変数は渡さないのは
防御的プログラミングの基本じゃない？
でも一括で渡すフレームワークもあったっけ。
防御的プログラミングの基本じゃない？
でも一括で渡すフレームワークもあったっけ。
今までActionを記述する時は
initialize,execute,getDefaultViewとかの主要メソッドを前において
ﾊﾞﾘﾃﾞｰｼｮﾝとかｺﾝﾊﾞｰﾀとかgetRequestMethodsとかのｻﾌﾞ的なメソッドは
後に詰めてたんだけど、
サブ的なメソッドの中にこそゴミがたまりがちなので、
上の方に置くことにしてみたよ。
視界に晒されることで整理整頓が促されるかなと。
initialize,execute,getDefaultViewとかの主要メソッドを前において
ﾊﾞﾘﾃﾞｰｼｮﾝとかｺﾝﾊﾞｰﾀとかgetRequestMethodsとかのｻﾌﾞ的なメソッドは
後に詰めてたんだけど、
サブ的なメソッドの中にこそゴミがたまりがちなので、
上の方に置くことにしてみたよ。
視界に晒されることで整理整頓が促されるかなと。
クラスファイルは大文字から始めるのがPHP風だけど
テンプレートのファイル名は
大文字から始めてる？小文字から始めてる？
テンプレートのファイル名は
大文字から始めてる？小文字から始めてる？
俺は大文字から始めてるな。どっちでも良いと思うけど何となく
そんな複数の変数をテンプレートに渡すのが普通なんですか？
おいら、Viewでまとめてから、テンプレートに送ってんですが、
この下記かたはありですか？
おいら、Viewでまとめてから、テンプレートに送ってんですが、
この下記かたはありですか？
ViewでHelperに変数をセットしてから
Helperだけassignとかもやるお。
Helperだけassignとかもやるお。
PEAR コーディング・スタイルで書けばいいのに。
PEAR コーディング・スタイルって、どんなん？
こーでぃんぐきやく
>>149
今は攻撃的プログラミングが基本です
今は攻撃的プログラミングが基本です
PEARのコーディング規約をeclipseでどう設定するのでしょうか?
とりあえずタブが空白4文字でなく\tになってるのをどーにかしたいのですが…
とりあえずタブが空白4文字でなく\tになってるのをどーにかしたいのですが…
>>145
Smarty使っているのなら、{debug}で送られている変数全てを確認してみればｲｲのでは？
Smarty使っているのなら、{debug}で送られている変数全てを確認してみればｲｲのでは？
Zend Framework まだ？
あとちょっと
Zend FrameworkってPHP5専用？
今出ました
ＡｇａｖｉのUnitTestはどうやって行うんですかね？
testsフォルダに生成された各TESTファイルにTESTケースを
記述し、「agavi test」をプロジェクトルートで実行しても、
実行されたのは0で、エラーも0・・・。
どうやったらTESTが実行されるのですか・・・。
Tutorialは抜けてますし。
testsフォルダに生成された各TESTファイルにTESTケースを
記述し、「agavi test」をプロジェクトルートで実行しても、
実行されたのは0で、エラーも0・・・。
どうやったらTESTが実行されるのですか・・・。
Tutorialは抜けてますし。
zendが出たら俺の計画が始まるのに
Ajaxベース・・・、面白いけど誰も使わなそうだ
皆フレームワーク作るのが好きなんだなｗ
一ユーザからするとその熱意を既存のフレーム
ワークのブラッシュアップに使ってほしいものだが。
そのうちフレームワークを作るためのフレームワークが
出てきたりしてなｗ
一ユーザからするとその熱意を既存のフレーム
ワークのブラッシュアップに使ってほしいものだが。
そのうちフレームワークを作るためのフレームワークが
出てきたりしてなｗ
現状mojaviがそれにあたる。
mapleかなんかも作者がそんなこと言ってなかったっけか。
うろ覚えだけど。
うろ覚えだけど。
AgaviってPHP4版もあるの？
あるのかよ・・・orz
>>178
だめです
だめです
まあMojavi知っておけば
他もだいたい対応可能だろう
他もだいたい対応可能だろう
Phrameじゃないの？
国内ならmojaviかEthnaジャマイカと。
>>181
よくもまぁあんなキモいフレームワークを使う気になれますよね。
よくもまぁあんなキモいフレームワークを使う気になれますよね。
>>181
作者があっちこっち出没していろんなものの良い所を取り込もうとしている、という意味では活発だけど、
中途半端だし、ユーザーが活発かというと微妙。
でも期待はしているので、ユーザーが増えて、使い方のノウハウや
ドキュメントが増えて来ればいいなと思います。
作者があっちこっち出没していろんなものの良い所を取り込もうとしている、という意味では活発だけど、
中途半端だし、ユーザーが活発かというと微妙。
でも期待はしているので、ユーザーが増えて、使い方のノウハウや
ドキュメントが増えて来ればいいなと思います。
>>184
どんなところがキモいと思う？
どんなところがキモいと思う？
zend frameworkはいつなのよ。
Mapleは中身は全然見たことないのだが、
作者の周りに結構（俺から見たら）すごい人がいるし、
>>185が言ってる他言語の良いところを取り込もうとしてる
ところがいいんじゃないかと。生涯PHPだけって人にはいらん
機能かもしれないがな。
前にドキュメント強化月間かなんかやってた気がするが、
全然ダメだったの？
やっぱZend FrameWorkが出たらそれ使うだろうなぁ～。
今はAgavi使ってる。
作者の周りに結構（俺から見たら）すごい人がいるし、
>>185が言ってる他言語の良いところを取り込もうとしてる
ところがいいんじゃないかと。生涯PHPだけって人にはいらん
機能かもしれないがな。
前にドキュメント強化月間かなんかやってた気がするが、
全然ダメだったの？
やっぱZend FrameWorkが出たらそれ使うだろうなぁ～。
今はAgavi使ってる。
zendがんばれ
ちょーがんばれ
ちょーがんばれ
>>188
全然ダメだった。ひとっつも強化されずアウトプットは何もなかったｗ
全然ダメだった。ひとっつも強化されずアウトプットは何もなかったｗ
>>186
リクエストデータ毎にセッター・ゲッター作るところ。
リクエストデータ毎にセッター・ゲッター作るところ。
ゲッターは必ずしも必要じゃない。が、DIコンテナとか、PHPには無駄にヘビーなだけだと思うね。
まぁ土方用言語だしな。
DIはいらないけど、PHP4でAOPって実現できるの？
私も agavi使ってます。
mojaviと大して変わらないから覚えるの楽だし、それほど不満はないな。
mojaviと大して変わらないから覚えるの楽だし、それほど不満はないな。
197 ：nobodyさん：2006/01/23(月) 04:26:26 ID:sSJ3Zalm
入力フォーム作る時って
入力・確認・登録全部一つのActionに入れる？
入力・確認 / 登録
に分ける？
入力・確認・登録全部一つのActionに入れる？
入力・確認 / 登録
に分ける？
あとモバイル対応する時って
Actionから別にする？
Actionは共用でテンプレートだけ分ける？
あるいは両方（共用可能な場合のみ共用）？
Actionから別にする？
Actionは共用でテンプレートだけ分ける？
あるいは両方（共用可能な場合のみ共用）？
あとうんこする時って
便座あげてからズボン脱ぐ？
ズボン脱いでから便座あげる？
あるいは同時？
便座あげてからズボン脱ぐ？
ズボン脱いでから便座あげる？
あるいは同時？
>>197->>198
はっきりこれと言う回答は無いよ。
アプリケーション内で統一すべきケースもあれば、画面ごとにバラバラにするケースもあり
もっというならパフォーマンス重視なのか
パフォーマンスを犠牲にしてでも実装しなければならない機能があるかとか
コーディング規約として統一する場合もあるだろうし
ActionとViewの切り分けなんて優先度的にはかなり後のほうだと思う
もっと柔軟に考えたほうがいい
MVCの概念やフレームワークにとらわれすぎてやしないかね
はっきりこれと言う回答は無いよ。
アプリケーション内で統一すべきケースもあれば、画面ごとにバラバラにするケースもあり
もっというならパフォーマンス重視なのか
パフォーマンスを犠牲にしてでも実装しなければならない機能があるかとか
コーディング規約として統一する場合もあるだろうし
ActionとViewの切り分けなんて優先度的にはかなり後のほうだと思う
もっと柔軟に考えたほうがいい
MVCの概念やフレームワークにとらわれすぎてやしないかね
>>197
HTML_QuickFormを使ってれば全部一箇所になるでしょ
Model内で全部やっているけど。
>>198
個人的にはURLとActionを全部一緒にしているが認証関係をさせるなら
PCの場合でも負荷がかかるということに後で気づいた。
毎回IPチェックとか必要だからね。
HTML_QuickFormを使ってれば全部一箇所になるでしょ
Model内で全部やっているけど。
>>198
個人的にはURLとActionを全部一緒にしているが認証関係をさせるなら
PCの場合でも負荷がかかるということに後で気づいた。
毎回IPチェックとか必要だからね。
おっとすまん。>>199 の間違い
さらにすまん。
名前欄の198は202な～
名前欄の198は202な～
俺が地雷を踏んでしまったために、
Mapleスレでもドキュメントの話が出たみたいだなぁ・・・。
Maple関連の上位ｴﾛの人のサイトで
「「Mapleはアウトプットが出てこない」と叩かれていたりするし（笑）。」
とか書かれちゃった・・・。すまんこってす。
やる気を削いでしまったのなら本当に申し訳ない。
かなり参考にしているサイトなので、これからも頑張ってﾎｽｨ。
関係ないけど、その上位ｴﾛの人って、実はMaple作者とあんま仲良くない？
て思うんだけどどうだろ・・・。微妙にﾄｹﾞを感じたのだが、気のせいかな・・・。
Mapleスレでもドキュメントの話が出たみたいだなぁ・・・。
Maple関連の上位ｴﾛの人のサイトで
「「Mapleはアウトプットが出てこない」と叩かれていたりするし（笑）。」
とか書かれちゃった・・・。すまんこってす。
やる気を削いでしまったのなら本当に申し訳ない。
かなり参考にしているサイトなので、これからも頑張ってﾎｽｨ。
関係ないけど、その上位ｴﾛの人って、実はMaple作者とあんま仲良くない？
て思うんだけどどうだろ・・・。微妙にﾄｹﾞを感じたのだが、気のせいかな・・・。
UPDATE 2005-01-08: 0.10.1b has been released!
>>206
なにいきなりそんな古い情報を・・・
なにいきなりそんな古い情報を・・・
agaviのトップページの記述が間違ってるってことだべ。 >>91あたりでも言ってる人いるなぁ。
ここに書くより、本家に言った方がいいのに。
ここに書くより、本家に言った方がいいのに。
「上位ｴﾛ」って何？
>>209
普通に、上位のエロの人だと思うが・・・。
普通に、上位のエロの人だと思うが・・・。
わからんて
はっきり書け
はっきり書け
上の位にいるエロの人だよ
つまりMapleはエロエロってことか
>>211
もっと２ちゃん来い
もっと２ちゃん来い
どっかの会社みたいに社員そうでで売名や貶めるのは好きじゃないなあ。
板違い
日経システム構築にPHPフレームワークの記事が少し載っていたが
Mojaviに「もじゃび」ってフリガナがふってあったw
Mojaviに「もじゃび」ってフリガナがふってあったw
>>217
正しい
正しい
本来はﾓﾊﾋﾞじゃなかったっけ？
だがしかし、俺はモジャビと読むからな！
Jalapeno ハラペーニョ（辛いやつ）
Fajita ファヒータ（メキシコ料理）
Mojave モハーベ（砂漠の名前らしい）
やっぱりモハービかな・・・
Jalapeno ハラペーニョ（辛いやつ）
Fajita ファヒータ（メキシコ料理）
Mojave モハーベ（砂漠の名前らしい）
やっぱりモハービかな・・・
>>217
ちなみに著者は？
ちなみに著者は？
俺もﾓｼﾞｬﾋﾞって呼んでるけどね。
おれも心の中では mojavi はモジャビだし GIF はギフだ
PHPで、どのフレームワークが一番？
ttp://phpspot.org/blog/archives/2006/01/php_30.html
ttp://phpspot.org/blog/archives/2006/01/php_30.html
227 ：nobodyさん：2006/01/26(木) 19:03:08 ID:Eur2xnDy
cakeは最近、開発早いと思うけど
228 ：nobodyさん：2006/01/26(木) 23:36:11 ID:P4JZCK77
mojaviで module=Defaultなしで index.php?action=Hoge ってやるとエラーになるのは
仕様?
仕様?
>>229
Mojaviって2？３？
Mojaviって2？３？
>>229
agaviではエラーにならないよ
agaviではエラーにならないよ
仕様ってそうなることを意図して作った場合に使う言葉じゃないの？
単なるバグでいいと思うけど。
単なるバグでいいと思うけど。
>>229
で、これ直した人いる?
で、これ直した人いる?
238 ：nobodyさん：2006/01/29(日) 09:48:17 ID:aQNUYPH4
バリデーションを済ませた
Requestをテンプレートにassign
→テンプレートから
getParameterあるいはgetError
これってアリ？ナシ？
Requestをテンプレートにassign
→テンプレートから
getParameterあるいはgetError
これってアリ？ナシ？
>>237
M2を使ったことはないけど、mojavi-all-classes.phpの385行目、
$modName = $request->getParameter(MODULE_ACCESSOR);
のセミコロンの直前に、
or $modName = DEFAULT_MODULE
を加えるとか。
mojavi-all-classes.phpをいじりたくないなら、index.phpの最後dispatchの行を、
$modName = $controller->getRequest()->getParameter(MODULE_ACCESSOR))
or $modName = DEFAULT_MODULE;
$controller->dispatch($modName);
に変えるとか（ちなみにこれだとaction名に関する整合性が少し保てなくなる）。
M2を使ったことはないけど、mojavi-all-classes.phpの385行目、
$modName = $request->getParameter(MODULE_ACCESSOR);
のセミコロンの直前に、
or $modName = DEFAULT_MODULE
を加えるとか。
mojavi-all-classes.phpをいじりたくないなら、index.phpの最後dispatchの行を、
$modName = $controller->getRequest()->getParameter(MODULE_ACCESSOR))
or $modName = DEFAULT_MODULE;
$controller->dispatch($modName);
に変えるとか（ちなみにこれだとaction名に関する整合性が少し保てなくなる）。
>>240
ざっとみたけど、どのへんがおもしろいの？
ざっとみたけど、どのへんがおもしろいの？
ローマ字のところじゃないか？
ローマ字ページつくれ。世界に発信しろ。
ローマ字じゃ世界には発信できんだろ w
アニオタ外人ならなんとか。
SJISなのに文字エンコードに関する情報がHTML内に無いのがーおもしろいね
そーゆーぺーじは多いがー外人SJIS読めんよ
そーゆーぺーじは多いがー外人SJIS読めんよ
稀に見る幼稚な文章だな。。。
そういう話はWeb製作板でやるべきだしな
まぁ面白いところといえば
<!-- *********************************************************************** -->
<!-- <HEAD> -->
<!-- *********************************************************************** -->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Frameset//EN"
"http://www.w3.org/TR/REC-html40/frmeset.dtd">
じゃないか
<!-- *********************************************************************** -->
<!-- <HEAD> -->
<!-- *********************************************************************** -->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Frameset//EN"
"http://www.w3.org/TR/REC-html40/frmeset.dtd">
じゃないか
Zend Frameworkはまだ～
もしかしてあの発表は世界規模の集団幻覚？
もしかしてあの発表は世界規模の集団幻覚？
>>250
来年まで待ちましょう。
来年まで待ちましょう。
>>251
まだ今年はじまったばかりなのに来年かよ（ ﾟДﾟ）
まだ今年はじまったばかりなのに来年かよ（ ﾟДﾟ）
でも本当にそれくらいになりそうだね。
とにかく変化がなさすぎる。
とにかく変化がなさすぎる。
agavi.jp終わってるな・・・
Symfony 0.6 is out!
Agavi使おうか、Symfony使おうか悩む・・・。
Symfonyは使った事がないのですけども、強みはAjax？
Agaviと比較するとここが勝ってる、または負けてる
っていう点があれば教えて下さい。
Symfonyは使った事がないのですけども、強みはAjax？
Agaviと比較するとここが勝ってる、または負けてる
っていう点があれば教えて下さい。
ttp://www.minfish.jp/blog/archives/2006/01/phpsymfonyweb1.html
に軽く書いてあるね。AgaviのSmarty組み込みでNGってどこが躓いたんだろ？
どこでNGか書いてくれたらコメント出来たんだけどな。
このスレでは何使ってる人が一番多いんだろ？
やっぱMojavi2かな？
に軽く書いてあるね。AgaviのSmarty組み込みでNGってどこが躓いたんだろ？
どこでNGか書いてくれたらコメント出来たんだけどな。
このスレでは何使ってる人が一番多いんだろ？
やっぱMojavi2かな？
agaviはいいよ。不満はない。
Symfony 0.6 の Sandboxは良いね。
ダウンロードしたのを展開すれば、空のプロジェクトが出来るので、
導入の敷居が、かなり低くなる。
ダウンロードしたのを展開すれば、空のプロジェクトが出来るので、
導入の敷居が、かなり低くなる。
Ruby on Railsって何が良いの?
何か作った気になれるとこ
一過性流行なところ
>>262
インフルエンザだな。
インフルエンザだな。
Zendフレームワークはいつくらいになりそう？
おまいらagaviは0.10.1b使ってるのか？
Mojavi4はいつ出るんだ？
>>267
今確認したんだけど、agavi-current.tgzは展開するとagavi-0.10.1bが出来るけど
0.10.0(stable)だね＞version.php
ﾃﾞｨﾚｸﾄﾘ名とversion.phpの表記が違ってるのが不明・・
ｿｰｽの更新日付的には>>268が最新です
今確認したんだけど、agavi-current.tgzは展開するとagavi-0.10.1bが出来るけど
0.10.0(stable)だね＞version.php
ﾃﾞｨﾚｸﾄﾘ名とversion.phpの表記が違ってるのが不明・・
ｿｰｽの更新日付的には>>268が最新です
MojaviやAgavi系がPHPのフレームワークの
デファクトと考えて差し支えないでしょうか？
デファクトと考えて差し支えないでしょうか？
>>271
半年前はそうだった。 今は混沌
半年前はそうだった。 今は混沌
Zend Frameworkが出ればデファクトになります。
出るのは来年だけどね。
出るのは来年だけどね。
新しいZendStudioの出来が良かったから
密かにZFも期待してる
密かにZFも期待してる
>>272
別に混沌というほどでもないだろ。
別に混沌というほどでもないだろ。
>>271
差し支えはないと思われ
差し支えはないと思われ
ViewってActionの成果物をテンプレートにAssignするだけのいらない子と思ってたけど
主機能はむしろViewHelperで、
テンプレートから呼び出されるメソッドを保持する偉い子だったんだな。
主機能はむしろViewHelperで、
テンプレートから呼び出されるメソッドを保持する偉い子だったんだな。
>>277
web開発における MVCﾓﾃﾞﾙ そのものを勉強しろと小一時間・・
web開発における MVCﾓﾃﾞﾙ そのものを勉強しろと小一時間・・
プレゼンテーション層に主軸をおいたStruts系の場合
M=Model及びAction
V=Action及びView
C=Controller
だから明確な区別は難しいんだよ。
M=Model及びAction
V=Action及びView
C=Controller
だから明確な区別は難しいんだよ。
Agavi実際に稼働させてる奴いる？
PHP4でフレームワークって皆さん何を使ってますか？
あと、PHP5だと何を使ってるかも教えて下さい。
あと、PHP5だと何を使ってるかも教えて下さい。
>>281
最近ちと人が大目の職場に転職したんだが、そこではphp4+mojavi2を使うようにと言われている。
個人的な物には、php5+agaviまたはmojavi3を使っている。
海外のどっかのサイトのアンケートだとSymfonyを使っている人が一番多かったんだっけ？
まぁでも統計結果が実情を正確に表せるほどフレームワークが広まっているような気がしないんだが。
てか、>>1に乗ってるのを全部使ってみて自分にあったものを使えばいいんじゃないかねぇ。
最近ちと人が大目の職場に転職したんだが、そこではphp4+mojavi2を使うようにと言われている。
個人的な物には、php5+agaviまたはmojavi3を使っている。
海外のどっかのサイトのアンケートだとSymfonyを使っている人が一番多かったんだっけ？
まぁでも統計結果が実情を正確に表せるほどフレームワークが広まっているような気がしないんだが。
てか、>>1に乗ってるのを全部使ってみて自分にあったものを使えばいいんじゃないかねぇ。
俺フレームワーク使ってます。意外と多いのでは。
俺も先行き不透明だったんで俺フレームワーク使ってるけど
最初削っていた機能が必要になるたび付けて行ったら
どんどんM3に似て来た。
Mojavi系はConverterがないのが不満。
勝手に改造したらバージョンアップ時の整合性が面倒くさいからなぁ。
最初削っていた機能が必要になるたび付けて行ったら
どんどんM3に似て来た。
Mojavi系はConverterがないのが不満。
勝手に改造したらバージョンアップ時の整合性が面倒くさいからなぁ。
Mojavi2でRendererクラスのexecuteメソッドの引数に
Controller、Request、Userの三つのオブジェクトを渡しているんだけど
RequestとUserは使ってないんだよね。何の為に渡してんの？
Controller、Request、Userの三つのオブジェクトを渡しているんだけど
RequestとUserは使ってないんだよね。何の為に渡してんの？
Rednererを派生させたクラスで使う
286だけど、他の板での番号が残ってました
すまん202ではないです
すまん202ではないです
Actionから別のActionへのデータの受け渡しってどうやってる？
Request->Attributeとか
User->Parameterに入れる？
ネームスペースで区切る、区切らない等いろいろ考えられるけど。
Request->Attributeとか
User->Parameterに入れる？
ネームスペースで区切る、区切らない等いろいろ考えられるけど。
Mojavi2ならRequestにデータを格納し
ActionChainのsetPreserve()をtrueにして渡すのが順当かな
ActionChainのsetPreserve()をtrueにして渡すのが順当かな
290 ：nobodyさん：2006/02/20(月) 15:25:19 ID:X62Wwkk2
最近フレームワーク触りだした初心者でかなり申し訳ないのですが、
orマッパがないフレームワークはやはり皆さん自前でこしらえてますか？
orマッパがないフレームワークはやはり皆さん自前でこしらえてますか？
>>290
PEARのDB_DataObject使ってる
PEARのDB_DataObject使ってる
292 ：nobodyさん：2006/02/20(月) 19:01:00 ID:vRXDRBjP
日本はMaple
>288
漏れはActionChain::register()の第4引数に連想配列で渡してるんだが、
ひょっとして少数派？
むしろ値の戻し方がよくわからん。
$user->setAttribute()してるけど、名前ぶつからないようにするのﾏﾝﾄﾞｸｾ
漏れはActionChain::register()の第4引数に連想配列で渡してるんだが、
ひょっとして少数派？
むしろ値の戻し方がよくわからん。
$user->setAttribute()してるけど、名前ぶつからないようにするのﾏﾝﾄﾞｸｾ
ActionChainってそんなに頻繁に使うもの？
PgSQLSessionHandler使ってるんだが、
ユーザ定義のDB接続と同時に使った場合、
コネクション別々に張るの無駄じゃね？
ユーザ定義のDB接続と同時に使った場合、
コネクション別々に張るの無駄じゃね？
mojaviのDB接続はつかいもにならんよ。
どうしても使うなら、コネクションプールするべし
どうしても使うなら、コネクションプールするべし
>>297
pg_connectなら第2引数にPGSQL_CONNECT_FORCE_NEW指定しなければコネクションは1つだけど？
pg_connectなら第2引数にPGSQL_CONNECT_FORCE_NEW指定しなければコネクションは1つだけど？
Simplateの中の人は
技術力では桁違いな感じだね。
これは期待できそう。
今は俺フレームワークで作ってるけど
いずれは乗り換えたいな。
技術力では桁違いな感じだね。
これは期待できそう。
今は俺フレームワークで作ってるけど
いずれは乗り換えたいな。
>299
知らんｶｯﾀ
無駄はないんだな。安心したよ。
知らんｶｯﾀ
無駄はないんだな。安心したよ。
mojavi2 + xml-rpc やろうとしてるんだけど、PEARのはしんどい（大幅に手を加えなきゃならない）
なんか良い解決法ある？
mojavi2は確定（というか変えるのめんどくさい）
なんか良い解決法ある？
mojavi2は確定（というか変えるのめんどくさい）
流れぶった切りで失礼します。
今PHPとFirebirdでD.B.の中にあるデータの値を取り込んで、
Excelのグラフを自動的に作成する、スクリプトを作ろうとしているのですが、
ここで便利なフレームワークはないものでしょうか・・・
Excelではなくただのグラフを作成してくれるもの、
有償のソフト、は見つけたのですが、
これをオープンソースで行っているフレームワークはないかなと思いまして。
何か、良いものがあったら教えていただけないでしょうか？
よろしくお願いします。
今PHPとFirebirdでD.B.の中にあるデータの値を取り込んで、
Excelのグラフを自動的に作成する、スクリプトを作ろうとしているのですが、
ここで便利なフレームワークはないものでしょうか・・・
Excelではなくただのグラフを作成してくれるもの、
有償のソフト、は見つけたのですが、
これをオープンソースで行っているフレームワークはないかなと思いまして。
何か、良いものがあったら教えていただけないでしょうか？
よろしくお願いします。
そういうのはフレームワークではなくただのアプリと言うんじゃないか？
Pearにエクセル出力出来るClassがあったと思う
使ったことないからグラフ出力出来るかは知らんけど
使ったことないからグラフ出力出来るかは知らんけど
すみません、説明不足でした。
そのPEARのExcelWriterClassを使って表を作るところまではできたのですが、
グラフ出力が出来なくて。
日本のフレームワークは結構見た(つもりかも)のですが、なかなか見つからなくて・・・
そのPEARのExcelWriterClassを使って表を作るところまではできたのですが、
グラフ出力が出来なくて。
日本のフレームワークは結構見た(つもりかも)のですが、なかなか見つからなくて・・・
■■声を大きく再掲示■■
そういうのはフレームワークではなくただのアプリと言うんじゃないかぁぁぁぁ？
そういうのはフレームワークではなくただのアプリと言うんじゃないかぁぁぁぁ？
Mojaviってコントローラにモジュール名とアクション名の２つを渡さなくては
ならないけど、なんでみんな何の疑問も持たずに使ってんだろうか？
面倒くさくない？アクション名だけでいいじゃんとか思う。
ならないけど、なんでみんな何の疑問も持たずに使ってんだろうか？
面倒くさくない？アクション名だけでいいじゃんとか思う。
デフォルトのmodule名設定しておけば
Actionだけでいけるじゃん
ただある程度以上になるとModuleがないとやってられねーけどな。
Actionだけでいけるじゃん
ただある程度以上になるとModuleがないとやってられねーけどな。
311 ：nobodyさん：2006/02/22(水) 20:47:08 ID:PffjIGDj
このスレで言ってるフレームワークはあくまでもウェブフレームワークだからね。
エクセル操作系のフレームワークとかライブラリって言い方も出来るとは思うけど。
エクセル操作系のフレームワークとかライブラリって言い方も出来るとは思うけど。
ImageMagick かなんかかませばグラフ作れるんじゃね？
めんどいし、Excel 多分関係ないし、フレームワークも関係無いけどなー
めんどいし、Excel 多分関係ないし、フレームワークも関係無いけどなー
>>311
語弊があるな。MojaviとかAgaviとか
コマンドライン用のフレームワークとしても動作するよう設計されてるぞ。
それと「エクセルのグラフを出力する」てのはViewの問題だから、
「エクセルのグラフを出力する」クラスや関数群はライブラリであってもフレームワークではないだろ。
語弊があるな。MojaviとかAgaviとか
コマンドライン用のフレームワークとしても動作するよう設計されてるぞ。
それと「エクセルのグラフを出力する」てのはViewの問題だから、
「エクセルのグラフを出力する」クラスや関数群はライブラリであってもフレームワークではないだろ。
それも含めてウェブフレームワークだろ。ま、PHPはウェブ専用言語といっていいし、PHPでフレームワークといえば、ウェブフレームワークと同義だな。
>PHPはウェブ専用言語といっていいし
ウェブ用言語として開発はされているが 専用 ではないぞ。
ウェブ用言語として開発はされているが 専用 ではないぞ。
おいおいおまいら勘違いするなよ。
ここはWebProg板であり、PHPのフレームワークについて語るスレですよ。
たとえ/(Moj|Ag)avi/やPHPがコマンドラインだのエクセルだので使えたとしてもそれは板違い・スレ違いなだけ。
ここはWebProg板であり、PHPのフレームワークについて語るスレですよ。
たとえ/(Moj|Ag)avi/やPHPがコマンドラインだのエクセルだので使えたとしてもそれは板違い・スレ違いなだけ。
PHPをWeb以外で使おうとする時点でキチガイ。
突然だけど、無かったから貼っておく
PRADO
http://www.xisc.com/
PHP5専用フレームワーク
（確か、PHP5のコーディングコンテストで優勝した奴だったと思う）
個人的感想：
・.NETっぽくて分かりやすい
・重い
使ってみた人居たら、感想聞かせて欲しい
PRADO
http://www.xisc.com/
PHP5専用フレームワーク
（確か、PHP5のコーディングコンテストで優勝した奴だったと思う）
個人的感想：
・.NETっぽくて分かりやすい
・重い
使ってみた人居たら、感想聞かせて欲しい
320 ：nobodyさん：2006/02/24(金) 10:03:20 ID:UY/cDtzQ
漏れにはWACTが最高です。他を使った事がないんだけどね。
Mojavi+Smartyを使ってる隣の奴らはよくグチってるけど、
WACT onlyな漏れはさっさと仕事を片付けてる。
Mojavi+Smartyを使ってる隣の奴らはよくグチってるけど、
WACT onlyな漏れはさっさと仕事を片付けてる。
WACTの感想って全然聞かないね。
ってか、他を使わず、WACTだけって人はかなり珍しい。
ってか、他を使わず、WACTだけって人はかなり珍しい。
だいたい出来る事は同じなんだから
今更ﾏｲﾅｰFWに手を出そうとはなかなか思わﾅｲ
今更ﾏｲﾅｰFWに手を出そうとはなかなか思わﾅｲ
Mojavi2を使ってみた感想
・Rendererクラスがフレームワークと密接に絡みすぎ。
・Validaterや認証を一箇所を一括管理できないので保守性に欠ける。
・ソースが汚い。
・Rendererクラスがフレームワークと密接に絡みすぎ。
・Validaterや認証を一箇所を一括管理できないので保守性に欠ける。
・ソースが汚い。
↑あー失敗。
×Validaterや認証を一箇所を一括管理できないので保守性に欠ける。
○Validaterや認証を一括管理できないので保守性に欠ける。
×Validaterや認証を一箇所を一括管理できないので保守性に欠ける。
○Validaterや認証を一括管理できないので保守性に欠ける。
>>324
Validater
Validater
>>318
未だにそんなこと言ってる時点で時代遅れ
未だにそんなこと言ってる時点で時代遅れ
mojavi2のvalidaterはアホなので使わない
だからValidatorだって。
どんな教育を受けたら validator を validater なんて打つんだ？
DSの英語漬けしる。
varideatar
あがびサイトがエラーになってますよ！
http://agavi.org/
http://agavi.org/
こういうの見てると、Agavi とか使う気無くすなｗｗｗ
しかもチェックすればすぐ分かるエラーなんだよな。
ノーチェックでアップしているのかと。
ノーチェックでアップしているのかと。
公開鯖でデバッグ（*´∀｀）
あるある探検隊！あるある探検隊！
素早く直せば 気づかない
あるある探検隊！
ヽ(｀Д´) ヽ(｀Д´)
| ﾍ|ヽ | ﾍ|ヽ
|￣ |￣
あるある探検隊！
(｀Д´)ﾉ (｀Д´)ﾉ
ﾉ|∧ | ﾉ|∧ |
￣| ￣|
ヽ(｀Д´) ヽ(｀Д´)
| ﾍ|ヽ | ﾍ|ヽ
|￣ |￣
あるある探検隊！
(｀Д´)ﾉ (｀Д´)ﾉ
ﾉ|∧ | ﾉ|∧ |
￣| ￣|
修正ばかりで 完成しない
学習コストが 高くつく
あるある探険隊!
あるある探険隊!
あるある探険隊!
あるある探険隊!
覚えた頃には、旧式だ。
中途半端なものばかり
倫敦どんより 晴れたら巴里
ぶゆうでんでんででんでん
symfonyをアップグレードしようと思ったら
こんなエラーが返ってきたんだけど…
Exception: corrupt registry, could not retrieve channel symfony information
invalid package name/package file "symfony/symfony"
pear.symfony-project.comにPINGしても反応ないし
落ちてるのかなぁ
こんなエラーが返ってきたんだけど…
Exception: corrupt registry, could not retrieve channel symfony information
invalid package name/package file "symfony/symfony"
pear.symfony-project.comにPINGしても反応ないし
落ちてるのかなぁ
symfonyなんてマイナーなFWを使うなよ。
agavi よりはメジャーだぞ。
mojaviはずいぶん取りざたされてたのにagaviはイマイチなのはどういうことだろう？
やる気なくしたmojaviとagaviのサービス精神との対比はかなりインパクト強かったと思うんだけどな。
実はmojaviユーザ（＝依然PHP4ユーザ）が大半？
やる気なくしたmojaviとagaviのサービス精神との対比はかなりインパクト強かったと思うんだけどな。
実はmojaviユーザ（＝依然PHP4ユーザ）が大半？
PHPにそれほどでかいフレームワークは必要ないからだと思うよ
mojaviに自分の必要な機能を付け加えるだけで十分なんじゃないかな
お手軽さが売りのPHPにagaviほどの機能は必要ないかと
mojaviに自分の必要な機能を付け加えるだけで十分なんじゃないかな
お手軽さが売りのPHPにagaviほどの機能は必要ないかと
いやーお手軽さが売りってのは従来のPHPの話だと思うけど、今はお手軽にも使えるしそれなりの規模にも対応できるってのを売りにしてるんじゃない？
Java風のOO導入したりSPL整えたりZend Framework作ってるのは、少なくともZendはそういう方向に向かっているからだとは思う（中途半端かどうかって話は別として）。
もちろんごく小規模なものにも使えるがゆえに厨が多いってのもあるけど、今のご時世PHPは小規模のみっていう感じではなくなってきてるよ。
まあagaviはそこそこいいとは思うけど「必須」って感じじゃないってのはあるね。
なんか上でせっかくSymfonyの話がでてきたからちょっとチェックしてみようかとは思った。
Java風のOO導入したりSPL整えたりZend Framework作ってるのは、少なくともZendはそういう方向に向かっているからだとは思う（中途半端かどうかって話は別として）。
もちろんごく小規模なものにも使えるがゆえに厨が多いってのもあるけど、今のご時世PHPは小規模のみっていう感じではなくなってきてるよ。
まあagaviはそこそこいいとは思うけど「必須」って感じじゃないってのはあるね。
なんか上でせっかくSymfonyの話がでてきたからちょっとチェックしてみようかとは思った。
Agavi 普通にいいよ、使いやすい
PHP4で、フレームワーク探してるんだけど、何が良いだろうか？
やりたい事。AJAX、XML-RPC、RSS辺りを組み込みたいんだけど。
やりたい事。AJAX、XML-RPC、RSS辺りを組み込みたいんだけど。
M3とAgaviの違いって何？
>>307
遅ﾚｽですまんが一回Excelでグラフ作成したﾃﾝﾌﾟﾚを作ってそれをSpreadsheet_Excel_Writerで開いてデータだけを操作する方法じゃだめかな。試してないからわからないけど
遅ﾚｽですまんが一回Excelでグラフ作成したﾃﾝﾌﾟﾚを作ってそれをSpreadsheet_Excel_Writerで開いてデータだけを操作する方法じゃだめかな。試してないからわからないけど
>>357
MO->AG
MO->AG
ロジックによってViewとかHelperに追い出すか
テンプレートに書くか迷うなぁ
明確な線引きってしてる？
テンプレートに書くか迷うなぁ
明確な線引きってしてる？
PHP4でも5でも動くFWってどれ?
>>357
もともとAgaviは（たぶん）Mojavi3の開発の遅さにあきれた人たちが勝手にMojavi3の穴埋め＋独自の開発を始めたもの。
でもMojaviとAgaviの開発者の間で話し合いがあったらしく、今はMojavi3の開発は終了し、Mojavi3の代わりにAgaviを使ってね、とMojaviのサイトに書いてある。
いちおうMojavi4の開発は進められているけどまだいまいち形になってないね。
もともとAgaviは（たぶん）Mojavi3の開発の遅さにあきれた人たちが勝手にMojavi3の穴埋め＋独自の開発を始めたもの。
でもMojaviとAgaviの開発者の間で話し合いがあったらしく、今はMojavi3の開発は終了し、Mojavi3の代わりにAgaviを使ってね、とMojaviのサイトに書いてある。
いちおうMojavi4の開発は進められているけどまだいまいち形になってないね。
AgaviとSymfonyではAgaviの方がまだ使ってる人多いと思ってるんだどどうかな？
どっちが優れてるかは置いといて。
Symfonyの方が多いのかな？
どうせZend FrameWorkが出たらそっちにいこうと思ってたので
Symfonyは全然触ってないんだけど、不安になってきたなぁ・・・。
どっちが優れてるかは置いといて。
Symfonyの方が多いのかな？
どうせZend FrameWorkが出たらそっちにいこうと思ってたので
Symfonyは全然触ってないんだけど、不安になってきたなぁ・・・。
367 ：名無し募集中。。。：2006/03/02(木) 18:47:58 ID:FcCsra75
Symfonyのpearチャンネルdiscoverできない、、、
俺だけ・・・？
俺だけ・・・？
いちおうgoogleさんに聞いてみたら
日本語：mojavi 243,000 > symfony 115,000 > agavi 17,300
Web全体：symfony 425,000 > mojavi 314,000 > agavi 182,000
だそうです。こりゃびっくり。
日本語：mojavi 243,000 > symfony 115,000 > agavi 17,300
Web全体：symfony 425,000 > mojavi 314,000 > agavi 182,000
だそうです。こりゃびっくり。
>>367 俺もだめだぽ
え？もはやMojaviよりSymfonyの方がメジャーなのか
symfonyはphpだけのものではないわな。
英語で検索すりゃそりゃ多いわ。
英語で検索すりゃそりゃ多いわ。
>363
4で動くなら5でも大体動くんじゃね？
4で動くなら5でも大体動くんじゃね？
symfonyのtgz落としても展開に失敗するし。
pearもダメだし。
とりあえずsvnでcoできた。
なにげにsymfonyもmojaviの派生かい。
pearもダメだし。
とりあえずsvnでcoできた。
なにげにsymfonyもmojaviの派生かい。
>>369
symfonyのフォーラムに投稿があった
http://www.symfony-project.com/forum/index.php/t/51/
PEAR 1.4.7に問題があるのかね
pear upgrade -f PEAR-1.4.6
してから
pear channel-discover pear.symfony-project.com
でdiscover succeededになった
symfonyのフォーラムに投稿があった
http://www.symfony-project.com/forum/index.php/t/51/
PEAR 1.4.7に問題があるのかね
pear upgrade -f PEAR-1.4.6
してから
pear channel-discover pear.symfony-project.com
でdiscover succeededになった
追記
http://bergie.iki.fi/blog/midcom-pear-channel-not-working-with-pear-1-4-7.html
http://pear.php.net/bugs/bug.php?id=6960
バグらしい
報告されてるからすぐfixされるかなあ
何気にはまった
http://bergie.iki.fi/blog/midcom-pear-channel-not-working-with-pear-1-4-7.html
http://pear.php.net/bugs/bug.php?id=6960
バグらしい
報告されてるからすぐfixされるかなあ
何気にはまった
>>368 >>370-371
php framework mojavi: 111,000
php framework symfony: 88,900
php framework agavi: 12,300
まぁこんな感じ。
php framework mojavi: 111,000
php framework symfony: 88,900
php framework agavi: 12,300
まぁこんな感じ。
>>373
うごかないですよ!
うごかないですよ!
>>375
本当だ。できた。
本当だ。できた。
>>363
あとは、日本の Ethna、Mapleあたりも動く
あとは、日本の Ethna、Mapleあたりも動く
383 ：nobodyさん：2006/03/03(金) 12:57:54 ID:Tn8o6vdH
今日 agavi の勉強を始めたんですが、
agavi で任意のテンプレートエンジンを使うのって簡単にできますか?
SmartyView.class.php ってファイルがあって
Smarty は使えそうだってところまではわかりましたが、
できることなら patTemplate を使いたいのです。
agavi で任意のテンプレートエンジンを使うのって簡単にできますか?
SmartyView.class.php ってファイルがあって
Smarty は使えそうだってところまではわかりましたが、
できることなら patTemplate を使いたいのです。
>>384
ありがとうございます。
残念ですが、あきらめて Smarty を勉強することにします。
一応 View クラスを書こうとはしたのですが、
patTemplate を require した時点でエラーが出てしまって手に負えませんでした。
ありがとうございます。
残念ですが、あきらめて Smarty を勉強することにします。
一応 View クラスを書こうとはしたのですが、
patTemplate を require した時点でエラーが出てしまって手に負えませんでした。
>>385
SmartyView.class.phpを参考に（＝パクって）Viewクラスを継承する
PatTemplateView.class.phpを書けばいいんだけど
patTemplate を require した時点のエラーってどんなエラー？
もしかしてPHP5でVARを怒られているだけじゃないの
SmartyView.class.phpを参考に（＝パクって）Viewクラスを継承する
PatTemplateView.class.phpを書けばいいんだけど
patTemplate を require した時点のエラーってどんなエラー？
もしかしてPHP5でVARを怒られているだけじゃないの
>>386
> patTemplate を require した時点のエラーってどんなエラー？
> もしかしてPHP5でVARを怒られているだけじゃないの
こんなエラーです。
Strict Standards: Assigning the return value of new by reference is deprecated in /usr/pkg/lib/php/pat/patErrorManager.php on line 190
Strict Standards: var: Deprecated. Please use the public/private/protected modifiers in /usr/pkg/lib/php/pat/patTemplate.php on line 68
（同様に var のエラーが続く）
Strict Standards: Assigning the return value of new by reference is deprecated in /usr/pkg/lib/php/pat/patTemplate.php on line 1270
PaｔTemplateView.class.php というファイルを作成し、
その冒頭部分で
require_once 'pat/patErrorManager.php';
require_once 'pat/patTemplate.php';
を記述しています。
> patTemplate を require した時点のエラーってどんなエラー？
> もしかしてPHP5でVARを怒られているだけじゃないの
こんなエラーです。
Strict Standards: Assigning the return value of new by reference is deprecated in /usr/pkg/lib/php/pat/patErrorManager.php on line 190
Strict Standards: var: Deprecated. Please use the public/private/protected modifiers in /usr/pkg/lib/php/pat/patTemplate.php on line 68
（同様に var のエラーが続く）
Strict Standards: Assigning the return value of new by reference is deprecated in /usr/pkg/lib/php/pat/patTemplate.php on line 1270
PaｔTemplateView.class.php というファイルを作成し、
その冒頭部分で
require_once 'pat/patErrorManager.php';
require_once 'pat/patTemplate.php';
を記述しています。
>>387
cakeのrc4のアプリをPHP4からPHP5に移行したけど、
バージョン違いから来る問題はなかったよ。
いやまぁ、Dboをほぼ全面的に書き直すハメにはなったけどね。
それはPHP4とPHP5両対応とは違う話ってことで。
ModelとDboのドロドロの関係とドキュメント以外はまぁ問題ないと思う。
Railsへの道ははるか遠しだけど、
まぁ開発は活発だしまだ判断は早いと思っとる。
cakeのrc4のアプリをPHP4からPHP5に移行したけど、
バージョン違いから来る問題はなかったよ。
いやまぁ、Dboをほぼ全面的に書き直すハメにはなったけどね。
それはPHP4とPHP5両対応とは違う話ってことで。
ModelとDboのドロドロの関係とドキュメント以外はまぁ問題ないと思う。
Railsへの道ははるか遠しだけど、
まぁ開発は活発だしまだ判断は早いと思っとる。
>>389
ini_set("display_errors", 0);
ini_set("error_reporting", false);
require_once(AG_PATTEMPLATE_DIR.'pat/patErrorManager.php');
require_once(AG_PATTEMPLATE_DIR.'pat/patTemplate.php');
ini_restore("error_reporting");
ini_restore("display_errors");
こんなふうにして消せばいい
>>390
の方法でもいいけどデバッグの際はStrictの警告が出たほうがいいでしょ
ini_set("display_errors", 0);
ini_set("error_reporting", false);
require_once(AG_PATTEMPLATE_DIR.'pat/patErrorManager.php');
require_once(AG_PATTEMPLATE_DIR.'pat/patTemplate.php');
ini_restore("error_reporting");
ini_restore("display_errors");
こんなふうにして消せばいい
>>390
の方法でもいいけどデバッグの際はStrictの警告が出たほうがいいでしょ
関係ないけどRails本が出るみたいだね
ベーパーウェアって何?
ベーパーウェアって何?
>>393
ちょwwwwwwww
ちょwwwwwwww
http://framework.zend.com/download
Preview Release ｷﾀ━━━━(´д｀;)━━━━!
Preview Release ｷﾀ━━━━(´д｀;)━━━━!
Controllerまわりを見てみたけどフローがRailsっぽい
tar.gzで6MBytesっすか...
含まれてるファイルの数が半端ないな
資本の力SUGE-
資本の力SUGE-
>>402
マニュアルのページのスタイルは禿しく手抜きだけどなー
マニュアルのページのスタイルは禿しく手抜きだけどなー
ベーパーウェア 呼ばわりした外人どうすんだよｗｗ
記念に>>393のページ保存しとこ
Luceneのインデックスがそのまま読めるとあったので、PHPでLucene互換エンジンを
スクラッチで書いたのかスゲーと思ったら、結構.javaもあるんだね。
たぶん、検索はphpのみでできる...のかな?
ていうか、テンプレートと思われるtpl.phpファイルを除くと.phpと.javaの
各ファイル数の比は6:4くらいじゃんか。
スクラッチで書いたのかスゲーと思ったら、結構.javaもあるんだね。
たぶん、検索はphpのみでできる...のかな?
ていうか、テンプレートと思われるtpl.phpファイルを除くと.phpと.javaの
各ファイル数の比は6:4くらいじゃんか。
当然PHP5前提だよな・・・
interface、abstract、exception、stl、などなどつかいまくりですがな
想像以上に作りがショボい…。
Controllerのドキュメントがないと思ったら、まだまともに動かないのね。
しっかりしてよ>Zend
しっかりしてよ>Zend
zend frameworkって知らなかったんだけど、マニュアル読む限り、strutsみたいなウェブフレームワークというより、PEARの代替なんだな。
vaporware扱いされるに至って、少々あわててPreview releaseを出したのでは。
でもPdfとかLuceneとかのコンポーネントの独立性が高くて単体でも使えそうなのはいいね。
でもPdfとかLuceneとかのコンポーネントの独立性が高くて単体でも使えそうなのはいいね。
あるみたいよ、テンプレート。
ただし、あのなつかしきPHPLIBライクの奴らしいけど。
Smartyのようなミニ言語テンプレートとはアプローチが違って
少々判りにくい面はあるとおもうけど、ちゃんとロジックを分割する方を選んだんだね。
ただし、あのなつかしきPHPLIBライクの奴らしいけど。
Smartyのようなミニ言語テンプレートとはアプローチが違って
少々判りにくい面はあるとおもうけど、ちゃんとロジックを分割する方を選んだんだね。
>>402
え？
え？
目を引くのは Pure-PHP の PDF 用ライブラリぐらいか？
今の状態じゃデファクト・スタンダードのフレームワークになったりする
ようなものではないね…。
今の状態じゃデファクト・スタンダードのフレームワークになったりする
ようなものではないね…。
>>420
しかしPDFライブラリをPure-PHPにする意味はあるのだろうか。
しかしPDFライブラリをPure-PHPにする意味はあるのだろうか。
まあ機能的にはどのフレームワークもさほど大差はないから
「そこそこ使えるレベル」でも
デファクトとしては充分という判断があるのか、ないのか
「そこそこ使えるレベル」でも
デファクトとしては充分という判断があるのか、ないのか
メンテナンスが保証されてるのが良いところ
強くはなさそうだから
既存フレームワークと棲み分けは出来そうだね。
それぞれ戦略もってやって欲しい。
既存フレームワークと棲み分けは出来そうだね。
それぞれ戦略もってやって欲しい。
ソース流し読みした感じから独り言。フロントコントローラを使うと
http://example.com/hello/world/
っていうURLのhelloがコントローラ名、worldがアクション名になり、HelloController.phpの中に
class HelloController extends Zend_Controller_Action {
public function world() { }
public function index() { }
}
ってのを書いとくとHelloController::world()が呼ばれるみたいだ。
mojaviのように深いディレクトリ構造を要するわけではなくシンプルな点は○。
でも全部のアクションを一つのファイルに書くとなると、ここからどうやってファイルごとにモジュール化するんだろう？
Viewにどうやってつなげるかもよくわからん。
http://example.com/hello/world/
っていうURLのhelloがコントローラ名、worldがアクション名になり、HelloController.phpの中に
class HelloController extends Zend_Controller_Action {
public function world() { }
public function index() { }
}
ってのを書いとくとHelloController::world()が呼ばれるみたいだ。
mojaviのように深いディレクトリ構造を要するわけではなくシンプルな点は○。
でも全部のアクションを一つのファイルに書くとなると、ここからどうやってファイルごとにモジュール化するんだろう？
Viewにどうやってつなげるかもよくわからん。
>>425
railsっぽいね。
railsっぽいね。
Controllerといい、Viewといい、Routerといい、ほんっとにRails風なのね。
だったらActiveRecordまでインスパイアされて作ってくれればよかったのに。
なんだか、ActiveRecordとか、generatorとか、scaffoldingとかAjaxHelperとかの
Railsの便利機能のないRailsクローンという印象。
責める訳じゃないけど extremely simple っていううたい文句も
Railsから持ってきただけだったんですか、と思うとちょっとむなしい。
>>425
ドキュメントによると、アクションメソッドの中で
手動でViewをインスタンス化してrender()を呼ぶらしいよ。
だったらActiveRecordまでインスパイアされて作ってくれればよかったのに。
なんだか、ActiveRecordとか、generatorとか、scaffoldingとかAjaxHelperとかの
Railsの便利機能のないRailsクローンという印象。
責める訳じゃないけど extremely simple っていううたい文句も
Railsから持ってきただけだったんですか、と思うとちょっとむなしい。
>>425
ドキュメントによると、アクションメソッドの中で
手動でViewをインスタンス化してrender()を呼ぶらしいよ。
だれもこいつ→>>414には突っ込まないのか？
>>430
マニュアルにはZActiveRecordとか書いてあるよ
マニュアルにはZActiveRecordとか書いてあるよ
ActiveRecordパターンってRailsのActiveRecordを実装した人が命名したんじゃなかったっけ？
ZendFrameworkにもActiveRecord実装は確かにあるみたいだね、だけど
Zend_DataObjectにはRailsのモデルみたいにbelongsToにテーブル名書くだけで
find()のときに自動でjoinしてくれる機能はないよね?
むしろ使い勝手としてはPEAR::DB_DataObjectに近くない?
混乱させてごめん。
Railsのモデルの機能とActiveRecordパターンを混同してたみたいだ。
Zend_DataObjectにはRailsのモデルみたいにbelongsToにテーブル名書くだけで
find()のときに自動でjoinしてくれる機能はないよね?
むしろ使い勝手としてはPEAR::DB_DataObjectに近くない?
混乱させてごめん。
Railsのモデルの機能とActiveRecordパターンを混同してたみたいだ。
>>415
> vaporware扱いされるに至って、少々あわててPreview releaseを出したのでは。
ZendのAndiは4ヶ月も前からベーパーウェア扱いされてるの知ってたらしい。去年10/27のAndiのblogより勝手に訳：
http://andigutmans.blogspot.com/2005/10/zend-framework-post-is-too-long-so.html
> まあ今のところは何かしら実際に提示できるものを準備することに焦点をおいてるよ＞ベーパーウェア
> 早く出せるものは出すために全力を尽くしてる。
> シンプルかつ統一的なフレームワークを作り出すなんてどう考えても簡単なことじゃない。
> だから小グループ制で集中的に開発するのがそれだけ重要だってことだよ。
で、リリースまでにずいぶん時間かかりましたね。＞Andi
> vaporware扱いされるに至って、少々あわててPreview releaseを出したのでは。
ZendのAndiは4ヶ月も前からベーパーウェア扱いされてるの知ってたらしい。去年10/27のAndiのblogより勝手に訳：
http://andigutmans.blogspot.com/2005/10/zend-framework-post-is-too-long-so.html
> まあ今のところは何かしら実際に提示できるものを準備することに焦点をおいてるよ＞ベーパーウェア
> 早く出せるものは出すために全力を尽くしてる。
> シンプルかつ統一的なフレームワークを作り出すなんてどう考えても簡単なことじゃない。
> だから小グループ制で集中的に開発するのがそれだけ重要だってことだよ。
で、リリースまでにずいぶん時間かかりましたね。＞Andi
Zendの連中は「物事をシンプルに保つ」ということが本当に出来ないな。
zendの正式版というのはあとどれくらいですか
>>431
ZActiveRecordみたいにZで始まるクラス名とZend_DbみたいにZend_で始まるクラス名との間の相関関係がよくわからんな。
つーかZActiveRecordってどこに入ってんの？
ZActiveRecordみたいにZで始まるクラス名とZend_DbみたいにZend_で始まるクラス名との間の相関関係がよくわからんな。
つーかZActiveRecordってどこに入ってんの？
関係ないけど、Rubyの開発者の職場と結構近い事を最近知って、超興奮。
PHP、Java、Perl、Rubyの垣根がだんだんなくなってきたと
個人的には思ってるので、これを機会にRuby学ぼうと思った。
ﾁﾗ裏すまん。あまりに興奮して。
PHP、Java、Perl、Rubyの垣根がだんだんなくなってきたと
個人的には思ってるので、これを機会にRuby学ぼうと思った。
ﾁﾗ裏すまん。あまりに興奮して。
やっぱパッケージシステムなしにクラスライブラリを充実させるのって無理あるな。クラス名、長。
>>440
はげどうはげどうおおはげどう
はげどうはげどうおおはげどう
>>440
パッケージシステムっつーか、名前空間な。
まあ、Railsのいいところはマネしてもいいんじゃね？ただ、PHPでRubyのマネ（メタプログラミングまわり）はどう考えてもできないから、そのへんをどうすんのか気になる。
パッケージシステムっつーか、名前空間な。
まあ、Railsのいいところはマネしてもいいんじゃね？ただ、PHPでRubyのマネ（メタプログラミングまわり）はどう考えてもできないから、そのへんをどうすんのか気になる。
メタプログラミングなんかはフレームワークじゃなくて言語自体の話だね。
やるとしたらPHP6で無理やりとりこむか。
ところで、なんか前スレかなんかで「PHPはどうせ汎用言語じゃなくてWebに特化したものなんだからフレームワークみたいなものは言語仕様で提供すればいいのに」、って感じの話が印象的だったのを思い出した。
リンク張ろうと思ったけど検索で見つからなかったorz
やるとしたらPHP6で無理やりとりこむか。
ところで、なんか前スレかなんかで「PHPはどうせ汎用言語じゃなくてWebに特化したものなんだからフレームワークみたいなものは言語仕様で提供すればいいのに」、って感じの話が印象的だったのを思い出した。
リンク張ろうと思ったけど検索で見つからなかったorz
>>445
見れないのかよ！
見れないのかよ！
メタプログラミングって何？
Web Archive にもないな
classkitとAOP使って織り込んでいけばメタプログラミングもどきっぽい事は出来そう。
>>444
まさに言語設計時の問題だよね。
PHP6で実装されたとしても今更感がある。
そーいやnamespaceすらない言語なんだよな・・・・・。
>>444
まさに言語設計時の問題だよね。
PHP6で実装されたとしても今更感がある。
そーいやnamespaceすらない言語なんだよな・・・・・。
namespace は PHP5 のリリース直前まで入る予定だったんだけどな……残念だ
phpのcreate_functionとかevalはメタプログラミングとは言わないの？
RORも使ってるらしい？けど、evalはやだなぁ。。
>>450
たしか Andy がいつものように火病でトチ狂って入れないことになったんだっけ？
たしか Andy がいつものように火病でトチ狂って入れないことになったんだっけ？
PHPはHTMLを生成するメタプログラミング言語です。
>>452
使ってるどころか、使いまくりです。
たしか Maple の kunit さんのブログに書いてあったんだと思うけど、PHP 的には
生成したコードを eval するよりファイルに書き出して inlucde するほうが速いらしい。
>>453
パフォーマンスが悪いということで Zeev に却下されたんじゃない？ かなり怪しい記憶だけど。
PHP 6では導入予定で、CVS HEAD ではパフォーマンス問題も改善されてるっぽい。
個人的にはスレッドを実装してほしい。
使ってるどころか、使いまくりです。
たしか Maple の kunit さんのブログに書いてあったんだと思うけど、PHP 的には
生成したコードを eval するよりファイルに書き出して inlucde するほうが速いらしい。
>>453
パフォーマンスが悪いということで Zeev に却下されたんじゃない？ かなり怪しい記憶だけど。
PHP 6では導入予定で、CVS HEAD ではパフォーマンス問題も改善されてるっぽい。
個人的にはスレッドを実装してほしい。
>>455
まじ？evalってそんなに遅いのか…
まじ？evalってそんなに遅いのか…
基本的にどの言語でも eval はデメリットがでかいと思うけど。
スピードだけじゃなくて。
スピードだけじゃなくて。
俺がeval使うのはclassを動的生成するときだけだな。
create_functionならぬcreate_classみたいな関数あればよかったんだけど。
create_functionならぬcreate_classみたいな関数あればよかったんだけど。
あ，しまった，「ならぬ」か。失礼。
Zend Frameworkの話題が止んだのは、みんなもう飽きたからですね。
>>462
なんか話したいことあるならどうぞ？
なんか話したいことあるならどうぞ？
>>463
うーむ・・・
うーむ・・・
>>462
なにか話せるような素晴らしい展開があるのなら、喋ってもいいですよ？
なにか話せるような素晴らしい展開があるのなら、喋ってもいいですよ？
>>466
それだと継承を要求できない
それだと継承を要求できない
つーかインスタンスの生成じゃなくてクラスの生成の話ね。
＞それだと継承を要求できない
意味不明。
意味不明。
>>469
$className = "ArbitraryName";
eval("class $className extends RequiredClass {}");
$instance = new $className();
$className = "ArbitraryName";
eval("class $className extends RequiredClass {}");
$instance = new $className();
いや、458=470なんだが・・・
>>462
とりあえずZend Frameworkを見て、Symfonyを使い続ける決心がつきました
とりあえずZend Frameworkを見て、Symfonyを使い続ける決心がつきました
>>426
Rails以前に、pradoとかもそうじゃん
Rails以前に、pradoとかもそうじゃん
>>473
まあ今の状態じゃコントローラの実装が中途半端だしフレームワークとしては使い物にならんわな。
俺はちゃんと整ってきたらいつでも移行できるように定期的にチェックしようとは思うけど。
>>441
たぶんZActiveRecordは未実装なのでは？
ZSearchとかZFormみたいなのはphpdocのapiにのってるし。
まあ今の状態じゃコントローラの実装が中途半端だしフレームワークとしては使い物にならんわな。
俺はちゃんと整ってきたらいつでも移行できるように定期的にチェックしようとは思うけど。
>>441
たぶんZActiveRecordは未実装なのでは？
ZSearchとかZFormみたいなのはphpdocのapiにのってるし。
>>473
詳しく
詳しく
早速アップデートか
Zend Framework Preview 0.1.2
なんか実装に文句ある香具師は早めにメールしといた方がいいんじゃねか?
Zend Framework Preview 0.1.2
なんか実装に文句ある香具師は早めにメールしといた方がいいんじゃねか?
>>458
> create_functionならぬcreate_classみたいな関数あればよかったんだけど。
PECLのrunkitって知ってる? 試してみると面白いかもよ
http://pecl.php.net/package/runkit
> create_functionならぬcreate_classみたいな関数あればよかったんだけど。
PECLのrunkitって知ってる? 試してみると面白いかもよ
http://pecl.php.net/package/runkit
JavaのStrutsの話かい？
ぱっと見だけど
SymfonyのTemplateって生PHPなん？
SymfonyのTemplateって生PHPなん？
>>482
俺普段Agavi使ってるけど、それ気になってた。
Smartyを組み込み難いって言ってたし、どうなのかなぁって。
ttp://headlines.yahoo.co.jp/hl?a=20060307-00000006-cnet-sci
もう・・・、PHPったら・・・。
俺普段Agavi使ってるけど、それ気になってた。
Smartyを組み込み難いって言ってたし、どうなのかなぁって。
ttp://headlines.yahoo.co.jp/hl?a=20060307-00000006-cnet-sci
もう・・・、PHPったら・・・。
>>483
一応ユーザが作ったSmartyViewはある
ttp://www.symfony-project.com/forum/index.php/t/122/
しかしちょっと試しにやってみたがうまく行かなかった
誰か興味がある奴は組み込んでみてくれ
一応ユーザが作ったSmartyViewはある
ttp://www.symfony-project.com/forum/index.php/t/122/
しかしちょっと試しにやってみたがうまく行かなかった
誰か興味がある奴は組み込んでみてくれ
>>479
＞「流行ってるんだから PHP が一番良いに決まっている」
本当にそんなアホな理由の案件なら断れよ。
共用サバみたいなとこでも高速である程度セキュリティが確保された状態で実行できる環境が、
他の言語にないからだろ。
＞「流行ってるんだから PHP が一番良いに決まっている」
本当にそんなアホな理由の案件なら断れよ。
共用サバみたいなとこでも高速である程度セキュリティが確保された状態で実行できる環境が、
他の言語にないからだろ。
>>478
つーか嫌でも使わざる得ない状況になる可能性は高いな
リソースもありそうだから今ならちゃんとした要望ならすぐ
受け入れてくれるだろうし
良い提案なら早めに入れてくれると使う方もありがたいし
今のところZFの文句ってないのかな?
つーか嫌でも使わざる得ない状況になる可能性は高いな
リソースもありそうだから今ならちゃんとした要望ならすぐ
受け入れてくれるだろうし
良い提案なら早めに入れてくれると使う方もありがたいし
今のところZFの文句ってないのかな?
>>478
自分が仕切る側になればいいだけじゃん
自分が仕切る側になればいいだけじゃん
>>487
客がZF使えって言い出した場合の話しではなかったのか?
どちらにしてもZFが業界標準みたいになるんだろうよ
良かろうと悪かろうと
だから使うようになってから文句言うよりも早めにチェックして
文句言っておいた方がいいってこと
客がZF使えって言い出した場合の話しではなかったのか?
どちらにしてもZFが業界標準みたいになるんだろうよ
良かろうと悪かろうと
だから使うようになってから文句言うよりも早めにチェックして
文句言っておいた方がいいってこと
なんだかなぁ・・
仕事でＰＨＰいじるってるひとって大変やね
>>ZF
個人的な小さな小さな事なんだが、、
クラス名とファイル名が微妙に違うのは、ソース読みにくいなぁ・・と思った
いや、、それだけなんだが
個人的な小さな小さな事なんだが、、
クラス名とファイル名が微妙に違うのは、ソース読みにくいなぁ・・と思った
いや、、それだけなんだが
とりあえず、phpのデフォでしょ＞クラス名とファイル名が微妙に違う
LAMPスタックのコンポーネントのなかでも、
人気の高いプログラミング言語（笑）であるPHPだけは、
バグ密度が基準より高かったと、Coverityは述べている。
人気の高いプログラミング言語（笑）であるPHPだけは、
バグ密度が基準より高かったと、Coverityは述べている。
>>489
>客がZF使えって言い出した場合の話しではなかったのか?
自分が仕切る側になれば、そんな客とらなくていいだろｗ
現状WEB開発の仕事なんて腐るほどあるし、そんな客から仕事貰う必要がどこにあるの？
>客がZF使えって言い出した場合の話しではなかったのか?
自分が仕切る側になれば、そんな客とらなくていいだろｗ
現状WEB開発の仕事なんて腐るほどあるし、そんな客から仕事貰う必要がどこにあるの？
>>497
なんでPHPに限ってるの？
なんでPHPに限ってるの？
>>497
まず話の流れを理解しよう
まず話の流れを理解しよう
自分が有能なふりして（あるいは本当に有能でかつ性格悪いかで）
話の前提を壊して話題を逸らす人って鬱陶しいですよね
話の前提を壊して話題を逸らす人って鬱陶しいですよね
どこからともなく精神論持ち出す人も鬱陶しいですよ
>>503
まあそうだろうね。
まあそうだろうね。
>>503
詳しくは知らないが、AliasMatchって使えんかな？
試してないでスマンが
AliasMatch ^/(action1|action2|action3) /var/www/html/$1/index.php
とか
詳しくは知らないが、AliasMatchって使えんかな？
試してないでスマンが
AliasMatch ^/(action1|action2|action3) /var/www/html/$1/index.php
とか
いずれにせよ、スレ違い。
zendにもRailsのconfig/routes.rbみたいのあればいいのに
509 ：ヽ(´ー`)ノ ◆.ogCuANUcE ：2006/03/10(金) 17:37:36 ID:???
>>507
Zend_Controller_Router_Interface を継承してそういう Router クラスを
作って、置き換えたら？
Zend_Controller_Router は何で Zend_Controller_Router_Interface を
継承してないんだろう…。
Zend_Controller_Router_Interface を継承してそういう Router クラスを
作って、置き換えたら？
Zend_Controller_Router は何で Zend_Controller_Router_Interface を
継承してないんだろう…。
ZF wikiとかZF ユーザ会とかできるかな?
ﾌﾞﾛｸﾞで見たんだけど
Symfonyのヘルパーはグローバル関数らしいね。
グローバルをView用の空間に使うなんて大胆だけど
ありっちゃありかもしれないなぁ
俺ﾌﾚｰﾑﾜｰｸでもそうしようかな…
Symfonyのヘルパーはグローバル関数らしいね。
グローバルをView用の空間に使うなんて大胆だけど
ありっちゃありかもしれないなぁ
俺ﾌﾚｰﾑﾜｰｸでもそうしようかな…
(´・ω・｀)しらんがな
DBから取ってきたコンテンツをサニタイズとか改行コードを<br />にする処理は
どこでやってますか?
ViewかActionかModelで迷ってます。
どこでやってますか?
ViewかActionかModelで迷ってます。
>>509
> Zend_Controller_Router は何で Zend_Controller_Router_Interface を
> 継承してないんだろう…。
それのせいで引数が渡せなくてフロントコントローラが動かないんだよね。
しかもメソッドの実装が両者で微妙にズレてるし。
無理やり書き換えたらいちおうアクションメソッドまで呼び出せたけど、やっぱりちゃんとドキュメントとか出てからにしようと思った。
>>513
サニタイズはDBに保存する前にやるのが普通。
nl2brはDBからとってきた後にやる設計でやってるならビューで。
> Zend_Controller_Router は何で Zend_Controller_Router_Interface を
> 継承してないんだろう…。
それのせいで引数が渡せなくてフロントコントローラが動かないんだよね。
しかもメソッドの実装が両者で微妙にズレてるし。
無理やり書き換えたらいちおうアクションメソッドまで呼び出せたけど、やっぱりちゃんとドキュメントとか出てからにしようと思った。
>>513
サニタイズはDBに保存する前にやるのが普通。
nl2brはDBからとってきた後にやる設計でやってるならビューで。
>>513
<br>はviewじゃない？
<br>はviewじゃない？
> サニタイズはDBに保存する前にやるのが普通。
うそ?
SQLのサニタイズは、SQL発行直前
HTMLのサニタイズは、出力前
というのが基本と思っていたけど...
どっかに書いてなかったっけかな
後で調べてみる
うそ?
SQLのサニタイズは、SQL発行直前
HTMLのサニタイズは、出力前
というのが基本と思っていたけど...
どっかに書いてなかったっけかな
後で調べてみる
>>516
それで合ってる。
それで合ってる。
519 ：nobodyさん：2006/03/10(金) 22:19:12 ID:fDWXlAX4
HTMLってサニタイズなんて言葉使ったっけ？
zend使うか自分で作るか悩むな～
>>521
おまえの作ったやつって誰が使うの？
おまえの作ったやつって誰が使うの？
>>522
自分で使うんだよｗ
自分で使うんだよｗ
>>523
あぁ、なるほど趣味ね
あぁ、なるほど趣味ね
>>524
そうです趣味です
そうです趣味です
zend待つか・・・
お前らは「サニタイズ言うなキャンペーン」でも読め。
>>527
あれはどうしようもない素人が書いてるから無視
あれはどうしようもない素人が書いてるから無視
>>528
お前よりは玄人
お前よりは玄人
書いてることは大体間違って無いけど、書いてるコードがキモかったので俺は敬遠してる
>>528の理由知りたい
>>528の理由知りたい
言いたいことは分かるんだが、じゃあなんて置き換えればいいのか悩む
セキュアプログラミングは当たり前だから言うこと自体がおかしい、といわれても
実際そういう処理がどこかにあるわけだし・・・
セキュアプログラミングは当たり前だから言うこと自体がおかしい、といわれても
実際そういう処理がどこかにあるわけだし・・・
つか、あれは極端な例だろ？
本人だって、まさかあれをそのまま使わせるつもりはないだろうし。
本人だって、まさかあれをそのまま使わせるつもりはないだろうし。
eRuby の「h」はいいよね。
最近よくある
[大タブ1][大タブ2][大タブ3]
小タブ1 小タブ2 小タブ3
こんなナビゲーション作る時（例：Appleのサイト）は、
大タブ用Actionと小タブ用Actionを、
コンテキスト用Actionからforwardするのが普通？
[大タブ1][大タブ2][大タブ3]
小タブ1 小タブ2 小タブ3
こんなナビゲーション作る時（例：Appleのサイト）は、
大タブ用Actionと小タブ用Actionを、
コンテキスト用Actionからforwardするのが普通？
ZFのマニュアル読んでってるけど
分かりやすいね。
Mojavi系よりとっつきやすそうな印象。
分かりやすいね。
Mojavi系よりとっつきやすそうな印象。
>>537
お前の想定しているFWはなんだ
お前の想定しているFWはなんだ
>>539
M2だよ
M2だよ
ZFさらっと見た印象では
フレームワーク内でも疎結合を目指してるんだね。
理解しやすい反面、とっちらかった感じもある。
他のフレームワークは
PHPをラッピングしようとしてるけど
ZFは生PHPそのままでいい部分はそのまま使おうという感じ。
フレームワーク固有の知識習得のハードルを
出来るだけ低くしておこうというのは、
戦略としてはｱﾘと思う。
フレームワーク内でも疎結合を目指してるんだね。
理解しやすい反面、とっちらかった感じもある。
他のフレームワークは
PHPをラッピングしようとしてるけど
ZFは生PHPそのままでいい部分はそのまま使おうという感じ。
フレームワーク固有の知識習得のハードルを
出来るだけ低くしておこうというのは、
戦略としてはｱﾘと思う。
Mojavi系みたいに最終的にはZFをベースにしたフレームワークが出回りそうな感じだな。
え、MojaviってZFをベースにしてたの？
>>544
おｋ。理解した。
おｋ。理解した。
Mojavi3やAgaviではActionChainがなくなったってホント？
やっぱりいらない機能だから無くしたってことなのかね。
やっぱりいらない機能だから無くしたってことなのかね。
>>546
ほんと。 それぐらい自分で調べないでどうする
ほんと。 それぐらい自分で調べないでどうする
ActionChainの代替がDecorator
有限会社レアル
http://www.e-real.jp/
SE募集 Fedora Core + Apache + MySQL + PHP
自注の場合はクライアントに合わせる
勤務場所 ご自宅
雇用形態 正社員 アルバイト フリーランス 副業
WEBアプリケーション開発をしている会社で、簡単な資料を基に仕様書を作成し、翻訳家を通してセブのPGに作業させて、完成させる。
若い会社です。一緒に夢を追いかけませんか？
http://www.e-real.jp/
SE募集 Fedora Core + Apache + MySQL + PHP
自注の場合はクライアントに合わせる
勤務場所 ご自宅
雇用形態 正社員 アルバイト フリーランス 副業
WEBアプリケーション開発をしている会社で、簡単な資料を基に仕様書を作成し、翻訳家を通してセブのPGに作業させて、完成させる。
若い会社です。一緒に夢を追いかけませんか？
>549
転送メアドワロス(w
転送メアドワロス(w
スレ違いもほどほどにして欲しいな、宣伝とか
http://framework.zend.com/manual/zend.controller.getting-started.html
ここ見ながら構築してみたんだけど
Fatal error: Call to undefined method Zend_Controller_Front::run()
って言われる。誰か助けて
ここ見ながら構築してみたんだけど
Fatal error: Call to undefined method Zend_Controller_Front::run()
って言われる。誰か助けて
>>552
runって懐かしいよな。F5かよ。
runって懐かしいよな。F5かよ。
ZendFrameworkのチュートリアル
http://phparch.com/zftut/
http://phparch.com/zftut/
>>554
公式にリンクあるのになんでわざわざ載せるの？
公式にリンクあるのになんでわざわざ載せるの？
>>557
それ俺は楽しみにしてるんだけどいつ出来るのやら…
それ俺は楽しみにしてるんだけどいつ出来るのやら…
ZF、いまのところ複合View実現する方法が提示されてないね
forwardとかdecoratorとか
forwardとかdecoratorとか
ZFなんてキモくて流行りそうもねーな。
いじくってみたけど、そこまでキモイとは思わなかったな。
未完成って感じはするけど。
未完成って感じはするけど。
俺としてはなかなか好印象
モジュール＋アクションとアクションのみってどっちがいいですか？
俺フレームワークではアクションのみでやっているんですけど、
モジュールもあった方が便利ですか？
俺フレームワークではアクションのみでやっているんですけど、
モジュールもあった方が便利ですか？
用途によるだろ
用途っちゅーか規模によるな
アプリの規模と開発チームの規模の両方な
モジュールでナントカ空間を分割するんでお互い干渉しませんなんてのも
実際には命名規則だけで普通に問題なかったりするんで
あってもなくてもいいけどあった方が便利って程度じゃないかと思う
モジュールでナントカ空間を分割するんでお互い干渉しませんなんてのも
実際には命名規則だけで普通に問題なかったりするんで
あってもなくてもいいけどあった方が便利って程度じゃないかと思う
モジュールなんて概念はいらない。
hiddenでactionとmoduleの二つのパラメータを
持ちまわすのか？うぜぇ。
アクション名にいろいろな意味を持たせればいいじゃん。
ホントMojaviの作者はセンスねーよ。
hiddenでactionとmoduleの二つのパラメータを
持ちまわすのか？うぜぇ。
アクション名にいろいろな意味を持たせればいいじゃん。
ホントMojaviの作者はセンスねーよ。
パラメータ一つだろうが二つだろうが
たいして変わらんやん
言ってる意味が分からん
moduleがないと一つのディレクトリが
Actionだらけになって視認性が低下するしな
たいして変わらんやん
言ってる意味が分からん
moduleがないと一つのディレクトリが
Actionだらけになって視認性が低下するしな
例えば、訪問者用ページと管理者用ページ、とかだと、
いくら命名規則とかあっても、同じ名前空間にあるのはｷﾓｲ。
まぁ、サーバーごと別にする場合もあるだろうが。
でもそもそもモジュール名をhiddenとかで持ち歩く必要性は無いよな。
例えばSCRIPT_NAMEとか使って、 hoge.php にアクセスされたら
define('MODULE_NAME', 'hoge') になるような設計でいい気がする。
いくら命名規則とかあっても、同じ名前空間にあるのはｷﾓｲ。
まぁ、サーバーごと別にする場合もあるだろうが。
でもそもそもモジュール名をhiddenとかで持ち歩く必要性は無いよな。
例えばSCRIPT_NAMEとか使って、 hoge.php にアクセスされたら
define('MODULE_NAME', 'hoge') になるような設計でいい気がする。
つーかMojavi系でモジュール名やアクション名ってhiddenフィールドに入れるのが一般的なの？
普通にURIのクエリストリング中（$_GET）かパス（mod_rewrite）に入れればいいだけの話だと思ってたけど。
普通にURIのクエリストリング中（$_GET）かパス（mod_rewrite）に入れればいいだけの話だと思ってたけど。
>>570
でも結局は大抵は「同じファイルシステム空間にある」ってことになりそうだよ
action しかないフレームワークでも
hoge.php にアクセスされたら "hoge_{$action}" って action に行くようにすれば
やっぱ命名規則でどうにかなる問題な気がする
ものによって「別モジュールにすると何を分割できるか」が違うだろうから難しいけど
どうしてもモジュールが必要になるのってどんな場合なんだろう……
でも結局は大抵は「同じファイルシステム空間にある」ってことになりそうだよ
action しかないフレームワークでも
hoge.php にアクセスされたら "hoge_{$action}" って action に行くようにすれば
やっぱ命名規則でどうにかなる問題な気がする
ものによって「別モジュールにすると何を分割できるか」が違うだろうから難しいけど
どうしてもモジュールが必要になるのってどんな場合なんだろう……
分割統治せよ。
mojaviなんぞなら、フィルタの適用を変えるとかいろいろ。
mojaviなんぞなら、フィルタの適用を変えるとかいろいろ。
「モジュール」って考え方自体がそもそも必要性を求めるものじゃないよ。
理屈の上だけではたった一つのPHPファイルで全てを処理することも可能なわけだし。
俺はFWには普通にモジュールあったほうがわかりやすいし管理しやすいと思うけどね。
そんなに必要のなさが気になるなら使わなければいいし。
「命名規則でどうにでもなる」なんて、程度の差こそあれ「マシン語で何でもできる」と言っているのと同じようなもの。
こういうのは適材適所でいいよ。
理屈の上だけではたった一つのPHPファイルで全てを処理することも可能なわけだし。
俺はFWには普通にモジュールあったほうがわかりやすいし管理しやすいと思うけどね。
そんなに必要のなさが気になるなら使わなければいいし。
「命名規則でどうにでもなる」なんて、程度の差こそあれ「マシン語で何でもできる」と言っているのと同じようなもの。
こういうのは適材適所でいいよ。
hiddenに入れるってどういうこと？
ページ遷移を必ずpostで行うのか？
ページ遷移を必ずpostで行うのか？
moduleいらなかったら
全部Defaultにほうりこんでactionだけ使えばいい
あって困るもんじゃない
全部Defaultにほうりこんでactionだけ使えばいい
あって困るもんじゃない
でもmodule名は指定しないといけないだろ？
モジュール機能を提供してる大抵のフレームワークは
モジュール名が指定されなかった時に
デフォルトモジュールを決める手段を何かしら提供してるんじゃないかな？
モジュール名が指定されなかった時に
デフォルトモジュールを決める手段を何かしら提供してるんじゃないかな？
Mojaviでforwardするとき、
RequestParameterがパラメータコンテナに使われるみたいけど
セキュリティー的にどうなんだろ？
forward用のActionが外から直呼びされたりしたらﾔﾊﾞｽな感じがするんだが
RequestParameterがパラメータコンテナに使われるみたいけど
セキュリティー的にどうなんだろ？
forward用のActionが外から直呼びされたりしたらﾔﾊﾞｽな感じがするんだが
補足。setAttributeで目印を付けてgetAttributeで確認するという意味です。
やっぱりそんな感じにするしかないかな
直接呼び出し禁じる設定メソッドがあればいいんだけど
isSubAction?とか
直接呼び出し禁じる設定メソッドがあればいいんだけど
isSubAction?とか
>>584
アクションクラスにメソッドを準備すると仮定すると、アクションクラスがイ
ンスタンス化されるまでチェック不可能なので、Mojavi2なら
ExecutionFilterに手を入れる形になる。
それ以外の手としてはどこかに置いてある直接アクセス許可/禁止リストを
チェックするグローバルフィルタを準備することもできるかな。
アクションクラスにメソッドを準備すると仮定すると、アクションクラスがイ
ンスタンス化されるまでチェック不可能なので、Mojavi2なら
ExecutionFilterに手を入れる形になる。
それ以外の手としてはどこかに置いてある直接アクセス許可/禁止リストを
チェックするグローバルフィルタを準備することもできるかな。
>>581
forwardされたのか直接読まれたのかをRequestのパラメータmoduleとactionから判断すればよろしい。
forwardされたのか直接読まれたのかをRequestのパラメータmoduleとactionから判断すればよろしい。
フレームワーク比較表だって
http://lnx.googlewrite.com/chart.php
http://lnx.googlewrite.com/chart.php
>>587
何語ですか？ｗ
何語ですか？ｗ
589 ：nobodyさん：2006/03/25(土) 14:29:31 ID:89IwyN4m
590 ：nobodyさん：2006/03/26(日) 19:04:39 ID:CBEzlswa
みんな ZF いじってる？
>>590
hello, worldまではやったけど、最近別のことで忙しいので後回し。
hello, worldまではやったけど、最近別のことで忙しいので後回し。
592 ：nobodyさん：2006/03/26(日) 19:07:44 ID:CBEzlswa
Agavi にするか symfony にするか ZF を待つか迷ってます。。
ZFはたいしたことないから、symfonyを強くお勧めする。
594 ：nobodyさん：2006/03/26(日) 21:56:31 ID:DeU9y+sO
それでは symfony でいこうかな。
ただ、 Agavi/Mojavi とはちょっと勝手が違うようなので、
慣れるまで時間かかるんじゃないかと少し不安です。
ZF は今のところ微妙ですよね。
まだ Preview の段階なのでなんとも言えませんが。
私的には Controller の中に Action をずらずらっと書くのが好きになれません。
mod_rewrite を強制している(?)のもどうかと。
ただ、 Agavi/Mojavi とはちょっと勝手が違うようなので、
慣れるまで時間かかるんじゃないかと少し不安です。
ZF は今のところ微妙ですよね。
まだ Preview の段階なのでなんとも言えませんが。
私的には Controller の中に Action をずらずらっと書くのが好きになれません。
mod_rewrite を強制している(?)のもどうかと。
この間のwebcastではmod_rewriteには依存しないって言ってたのにどうなっちゃったのかね？＞ZF
596 ：nobodyさん：2006/03/26(日) 23:06:30 ID:DeU9y+sO
おそらく「依存しない」というのは、 mod_rewrite で
RewriteRule !\.(js|ico|gif|jpg|png|css)$ index.php
として、
URL/コントロール名/アクション名/
でアクセスさせるからだと思います。（違ってたらごめんなさい）
ここに理屈が書かれています。
http://revilog.com/program/2006/03/006937.html
ここでは REQUEST_URI を PATH_INFO に差し替えて…なんてことをしているようです。
http://tdiary.ishinao.net/20060322.html#p01
フレームワークを使う人なら mod_rewrite に慣れているはずだから、
わざわざフレームワーク側でしなくても…って思ったんです。
RewriteRule !\.(js|ico|gif|jpg|png|css)$ index.php
として、
URL/コントロール名/アクション名/
でアクセスさせるからだと思います。（違ってたらごめんなさい）
ここに理屈が書かれています。
http://revilog.com/program/2006/03/006937.html
ここでは REQUEST_URI を PATH_INFO に差し替えて…なんてことをしているようです。
http://tdiary.ishinao.net/20060322.html#p01
フレームワークを使う人なら mod_rewrite に慣れているはずだから、
わざわざフレームワーク側でしなくても…って思ったんです。
>>595
フレームワーク全体は mod_rewrite には依存していない、ってことじゃね？
現状は Preview 版の Router が依存してるけど、適宜書き直せば良いと。
>>596
オープンソースのように不特定多数が使うケースを考えると、apache の設定が
弄れない可能性がある。むしろ、フレームワーク側で用意してない方が糞。
フレームワーク全体は mod_rewrite には依存していない、ってことじゃね？
現状は Preview 版の Router が依存してるけど、適宜書き直せば良いと。
>>596
オープンソースのように不特定多数が使うケースを考えると、apache の設定が
弄れない可能性がある。むしろ、フレームワーク側で用意してない方が糞。
>>597
Router書き直すっていうかRouter Interfaceつかってrouteメソッド書けばいいんじゃない？
Mojavi系っぽいURLでindex.phpにアクセスしたいならこんな感じ
class MojaviRouter implements Zend_Controller_Router_Interface {
public function route(Zend_Controller_Dispatcher_Interface $dispatcher) {
$module = @ $_REQUEST['module'] or $module = 'Default';
// サニタイズしてね
$action = @ $_REQUEST['action'] or $action = 'Index'
// サニタイズしてね
$token = new Zend_Controller_Dispatcher_Token($module, $action, $_REQUEST);
// サニタイズしてね
if (! $dispatcher->isDispatchable($token)
throw new Zend_Controller_Router_Exception('～');
else
return $token;
}
あとはindex.phpの中のどっかで
$controller->setRouter(new MojaviRouter);
とかやればいいんでないかな。
しかしクラス名が長くて眩暈がするな。大したことやってないのに・・・
Router書き直すっていうかRouter Interfaceつかってrouteメソッド書けばいいんじゃない？
Mojavi系っぽいURLでindex.phpにアクセスしたいならこんな感じ
class MojaviRouter implements Zend_Controller_Router_Interface {
public function route(Zend_Controller_Dispatcher_Interface $dispatcher) {
$module = @ $_REQUEST['module'] or $module = 'Default';
// サニタイズしてね
$action = @ $_REQUEST['action'] or $action = 'Index'
// サニタイズしてね
$token = new Zend_Controller_Dispatcher_Token($module, $action, $_REQUEST);
// サニタイズしてね
if (! $dispatcher->isDispatchable($token)
throw new Zend_Controller_Router_Exception('～');
else
return $token;
}
あとはindex.phpの中のどっかで
$controller->setRouter(new MojaviRouter);
とかやればいいんでないかな。
しかしクラス名が長くて眩暈がするな。大したことやってないのに・・・
>>598
サニタイズしてね
サニタイズしてね
>>599
うん。
うん。
つーかサニタイズはdispatcherの仕事だな。
デフォルトのdispatcher使えば598のままで問題ないと思われ。
デフォルトのdispatcher使えば598のままで問題ないと思われ。
$module = @ $_REQUEST['module'] or $module = 'Default';
っていう書き方はじめて見た。
変数に値がない時の書き方が冗長になるなぁと
ずっと思ってたんだよな。
っていう書き方はじめて見た。
変数に値がない時の書き方が冗長になるなぁと
ずっと思ってたんだよな。
@演算子は好きじゃないな。
書くならむしろこっちでは。
$module = isset($_REQUEST['module']) ? $_REQUEST['module'] : 'Default';
書くならむしろこっちでは。
$module = isset($_REQUEST['module']) ? $_REQUEST['module'] : 'Default';
@は理解が深まると癖になる不思議な演算子。
まあそれ以前にPHPのorがboolしか返さないのがそもそもの難点なんだが・・・
まあそれ以前にPHPのorがboolしか返さないのがそもそもの難点なんだが・・・
>>602-605
ｽﾚ違い
ｽﾚ違い
まあもちついてくださいよ
いくつかのActionをChainさせた場合、
別々のActionからDBの同じデータにアクセスしてることあるじゃん。
いくつか方法はありそうだけど
どうやって対処してる？
別々のActionからDBの同じデータにアクセスしてることあるじゃん。
いくつか方法はありそうだけど
どうやって対処してる？
富豪プラグラミング
>>608
ただアクセスするだけならそのままでもいいし、データの書き込みに関してお互いの整合性が必要なら別口にDAO的なModel作ったらどう？
ただアクセスするだけならそのままでもいいし、データの書き込みに関してお互いの整合性が必要なら別口にDAO的なModel作ったらどう？
>608
agaviのSingletonModelとか、自前でSingletonするとか。
Actionに直接DBへのアクセス書くのはなんか抵抗があるな。
agaviのSingletonModelとか、自前でSingletonするとか。
Actionに直接DBへのアクセス書くのはなんか抵抗があるな。
いや、DAOはSingletonなModelでActionの外においてるんだけど、
同じデータを取るのに複数回クエリ発行するのが気になったんだ。
そのへんはあまり気にしないが正解かな。
同じデータを取るのに複数回クエリ発行するのが気になったんだ。
そのへんはあまり気にしないが正解かな。
>>612
DAO 側でデータをキャッシュしておいて，
同じデータと判断できるような何かがあったらキャッシュを返すとか……
結局は DB アクセスとメモリキャッシュのどちらかでリソースを食うので
状況次第ではどちらも富豪的な発想ってことに．
oracle なんかだと RDBMS 側でもキャッシュしてるから
同じデータを触りに行くクエリとかだと連打しても大して負荷なかったりする場合も．
DAO 側でデータをキャッシュしておいて，
同じデータと判断できるような何かがあったらキャッシュを返すとか……
結局は DB アクセスとメモリキャッシュのどちらかでリソースを食うので
状況次第ではどちらも富豪的な発想ってことに．
oracle なんかだと RDBMS 側でもキャッシュしてるから
同じデータを触りに行くクエリとかだと連打しても大して負荷なかったりする場合も．
MySQLのクエリキャッシュってMyISAMだけだよね？
>>615
MySQL 4.1.1 以降では、 InnoDB テーブルの使用時、クエリキャッシュはトランザクション内でも機能します
MySQL 4.1.1 以降では、 InnoDB テーブルの使用時、クエリキャッシュはトランザクション内でも機能します
フレームワークつかわんでプログラムするとき
おまいらはdaoとかつくりますか？
おまいらはdaoとかつくりますか？
だおとフレームワークは独立概念だお
>>615
時代の流れに置いていかれないようにね。
時代の流れに置いていかれないようにね。
「香具師がいた」とかどこの誰かと思ったら
m-takagi.org って php-doc で名前よく見る高木氏じゃないか
心底から感謝を捧げたい！
m-takagi.org って php-doc で名前よく見る高木氏じゃないか
心底から感謝を捧げたい！
おっ！いいね。
やっぱリファレンスが充実しなきゃ良いものも
広まらないからな。良いものかどうかは知らんが。
やっぱリファレンスが充実しなきゃ良いものも
広まらないからな。良いものかどうかは知らんが。
まだプレビュー版だから本サイトで使ってる人は殆どいないんじゃない？
実運用のサイトを作るのに使う香具師はいないだろうが、ちょっといじって
みたいって人はいるでしょ。というか使ってみたいんだけど、なかなか時間が
まわりのツールが集まってくると面白いことになるんだろうけど
ドキュメントは結構早く出てきてる感じがする
サイトはまだかなー
みたいって人はいるでしょ。というか使ってみたいんだけど、なかなか時間が
まわりのツールが集まってくると面白いことになるんだろうけど
ドキュメントは結構早く出てきてる感じがする
サイトはまだかなー
http://tdiary.ishinao.net/
ishinao さんがZend Frameworkをいろいろ触って所感を書いていますね。
ishinao さんがZend Frameworkをいろいろ触って所感を書いていますね。
携帯用フレームワーク?
http://ke-tai.org/index.php?KEMP
http://ke-tai.org/index.php?KEMP
>>628
作者乙。でも期待してるよ。
作者乙。でも期待してるよ。
基本というからには、他のすべてのフレームワークに、
日本の携帯に適したものが当然のごとく実装されてんのか？
そいつは知らんかったな。
日本の携帯に適したものが当然のごとく実装されてんのか？
そいつは知らんかったな。
630みたいのは「汎用厨」とでも名づけましょうかね
う～ん。。どっちもどっちジャマイカ？
PC 用には Smarty があるんだから
ケータイ用に KEMP でいいと思うよ。
ケータイ用に KEMP でいいと思うよ。
その二つを並べるのは変だろ
KEMP って Smarty 使っているんじゃないの
KEMP って Smarty 使っているんじゃないの
・PC用、携帯用のどちらにも対応したフレームワーク
・PC用に特化したフレームワーク
・携帯用に特化したフレームワーク
どれもあっていいと思うけどね。
そりゃどちらにも対応しててどちらに対しても最高の拡張性を備えてるなら文句ないけど、ないものねだりしても始まらない。
・PC用に特化したフレームワーク
・携帯用に特化したフレームワーク
どれもあっていいと思うけどね。
そりゃどちらにも対応しててどちらに対しても最高の拡張性を備えてるなら文句ないけど、ないものねだりしても始まらない。
>>632
一生懸命作ったものを否定されちゃったら、そりゃ厨扱いもしたくなるよね。
一生懸命作ったものを否定されちゃったら、そりゃ厨扱いもしたくなるよね。
携帯って独特の機能（端末IDを使った認証とか、絵文字とか、ユーザーエージェント毎の振り分けとか）
があるから、それに特化したフレームワークがあっても面白いかと思う。
PC版と携帯版があるサイトとかだと、別々のフレームワークが必要になったりして
不便かもしれないけど。
があるから、それに特化したフレームワークがあっても面白いかと思う。
PC版と携帯版があるサイトとかだと、別々のフレームワークが必要になったりして
不便かもしれないけど。
>>638
俺自身は携帯向け自体作る気ないから別にほしいとは思わないしお前もいらないんだろうけど、欲しい人もいるんじゃないの？
特に携帯の機種依存な処理とかどれくらい面倒くさいのか知らないが、ぱっと見た感じフレームワーク的なものあったら便利になるんだろうとは思った。
別にお前が要らないと考えること自体に対して異論はないよ。
人それぞれだから。
俺自身は携帯向け自体作る気ないから別にほしいとは思わないしお前もいらないんだろうけど、欲しい人もいるんじゃないの？
特に携帯の機種依存な処理とかどれくらい面倒くさいのか知らないが、ぱっと見た感じフレームワーク的なものあったら便利になるんだろうとは思った。
別にお前が要らないと考えること自体に対して異論はないよ。
人それぞれだから。
mojavi を例に取ると、filter と renderer 書く方がスマートって気もする。
>>642
突然何の話ですか？
突然何の話ですか？
ちょこっとですむならちょこっとで済ませたらいいんじゃないの。
適材適所だし。誰も咎めてはいないよ。
適材適所だし。誰も咎めてはいないよ。
>>643
なんの話というか…、こうやって専用にしか使えないフレームワーク作るより、
汎用のフレームワークに対する、いわばプラグインって形で提供すれば、
使ってくれる人も多くなるし、うまく行けば流行るかもしれん。
と言う意味で、スマートじゃないかな、と思った。
なんの話というか…、こうやって専用にしか使えないフレームワーク作るより、
汎用のフレームワークに対する、いわばプラグインって形で提供すれば、
使ってくれる人も多くなるし、うまく行けば流行るかもしれん。
と言う意味で、スマートじゃないかな、と思った。
どうかな？PHPのWebサイト全体に対するMojaviの使用率なんてそこまで高くないしな。
もし今後ZFが標準になったりとかすれば、プラグイン製作って考えも当たるかもね。
現時点では何とも言えないけど。
もし今後ZFが標準になったりとかすれば、プラグイン製作って考えも当たるかもね。
現時点では何とも言えないけど。
>>647
いや、別にmojavi は例として挙げただけだから、あまり気にしないでね。
少なくとも、携帯専用フレームワークよりは、mojavi でも何でも良いんで、
そこそこ知名度のあるフレームワークに寄生した方が、使う側にしても敷居が低くて良いと思うよ。
いや、携帯用のデファクトスタンダードに育て上げるんだ、
って意気込みでやるってんなら、それはそれで良いのかもしれんけど。
ま、個人的感想だと思って頂戴。
いや、別にmojavi は例として挙げただけだから、あまり気にしないでね。
少なくとも、携帯専用フレームワークよりは、mojavi でも何でも良いんで、
そこそこ知名度のあるフレームワークに寄生した方が、使う側にしても敷居が低くて良いと思うよ。
いや、携帯用のデファクトスタンダードに育て上げるんだ、
って意気込みでやるってんなら、それはそれで良いのかもしれんけど。
ま、個人的感想だと思って頂戴。
まあ俺の個人的な感想を言わせてもらえば、そっちのほうがいいと思うなら自分で作って公開してみたらどうだろう、と思うけどな。
どっちみちどうでもいい結論しか出なさそう。
どっちみちどうでもいい結論しか出なさそう。
携帯サイトは、絵文字対応とか端末IDの取得など、PC用サイトとはかなり違う構成になる。
それ専用のフレームワークは十分需要があるよ。
絵文字ライブラリだけでも売り物になるんだから。
それ専用のフレームワークは十分需要があるよ。
絵文字ライブラリだけでも売り物になるんだから。
あ、もちろん、個人で勝手サイト作る分には、どうにでも適当に作ればいいけど。
GroovyによるRuby on Railsライクなフレームワーク - Grails 0.1公開
http://headlines.yahoo.co.jp/hl?a=20060401-00000091-myc-sci
http://headlines.yahoo.co.jp/hl?a=20060401-00000091-myc-sci
>>650
だからその処理をFilterに入れるんだろうよ。
だいたい携帯でもPCでも見れるようなサイトを作る場合
わざわざフレームワークを分けるわけ？
その技術を世に公開するならSmartyやMojaviなどの
プラグインにした方がマシだと思う。
だからその処理をFilterに入れるんだろうよ。
だいたい携帯でもPCでも見れるようなサイトを作る場合
わざわざフレームワークを分けるわけ？
その技術を世に公開するならSmartyやMojaviなどの
プラグインにした方がマシだと思う。
携帯サイトのコンテンツとPCサイトのコンテンツはまったく違ったものにならざるを得ない。
まあ、公式サイトを作ったことあるやつならすぐわかる話。
まあ、公式サイトを作ったことあるやつならすぐわかる話。
>>654
おれもこないだまでは
「MVCきちんと分離しとけばVだけ変更して携帯サイトできあがり～」とか思ってたんだが
仕事で公式やったら>>650の通りで、>>630なんてのは空論に過ぎねーと思い知った
ていうかもう携帯の仕事はやりたくなくなったｗ
おれもこないだまでは
「MVCきちんと分離しとけばVだけ変更して携帯サイトできあがり～」とか思ってたんだが
仕事で公式やったら>>650の通りで、>>630なんてのは空論に過ぎねーと思い知った
ていうかもう携帯の仕事はやりたくなくなったｗ
>>656
それにしたってわざわざフレームワークを分ける必要は無くね？
それにしたってわざわざフレームワークを分ける必要は無くね？
えーと、後に引けなくなっちゃったのかな？
>>657
653のやり方に反対しているわけじゃないんだ
同じフレームワーク（以下FW）上で656に書いたみたいな大きな違いまで吸収できるならそれでいい
ただ実際、特化FWの代わりができるほどに「こなれた」汎用FWは見たことがない
654も言うとおり、実際「まったく違った」サイトにせざるを得んのだから、
それなら携帯の方は分けて考えて特化FWで作っても問題になりにくいだろうな、ってこと
もちろんFWの学習曲線を2回登らないといけないとかのデメリットも忘れてるわけじゃない
でも携帯サイトの不自然な制約はそれすら凌駕するくらいだと思うってこと
（これは個人的意見だしどこまで対応しなきゃならないかっていう要件にもよると思う）
653のやり方に反対しているわけじゃないんだ
同じフレームワーク（以下FW）上で656に書いたみたいな大きな違いまで吸収できるならそれでいい
ただ実際、特化FWの代わりができるほどに「こなれた」汎用FWは見たことがない
654も言うとおり、実際「まったく違った」サイトにせざるを得んのだから、
それなら携帯の方は分けて考えて特化FWで作っても問題になりにくいだろうな、ってこと
もちろんFWの学習曲線を2回登らないといけないとかのデメリットも忘れてるわけじゃない
でも携帯サイトの不自然な制約はそれすら凌駕するくらいだと思うってこと
（これは個人的意見だしどこまで対応しなきゃならないかっていう要件にもよると思う）
>>659
mojavi使える？他のフレームワークでも構わない。
filterとrendererで対応できないのって、どの辺？
別に煽ってるとかじゃないよ、携帯コンテンツとか作ったこと無いから、知的好奇心。
mojavi使える？他のフレームワークでも構わない。
filterとrendererで対応できないのって、どの辺？
別に煽ってるとかじゃないよ、携帯コンテンツとか作ったこと無いから、知的好奇心。
携帯の開発はNDAがあるから、あんまり喋れない。
だから、ウェブの資料とかあんまりない。
CP剥奪とかなったらシャレにならない。
まあ、携帯の開発って、フレームワークを適用できる部分が多いと思うよ。
PCのサイトなんかよりずっと。
だから、ウェブの資料とかあんまりない。
CP剥奪とかなったらシャレにならない。
まあ、携帯の開発って、フレームワークを適用できる部分が多いと思うよ。
PCのサイトなんかよりずっと。
>>662
良く知らないことを"ごとき"と評価できる貴方は素晴らしい。
良く知らないことを"ごとき"と評価できる貴方は素晴らしい。
このスレらしからぬ荒れ方をしているな
春休みって奴か
春休みって奴か
>>630,636,638,644,653,657,662
春具合ﾃﾗﾜﾛｽｗｗｗ
春具合ﾃﾗﾜﾛｽｗｗｗ
>662 が携帯の特殊性についての、どのような情報に
基づいて、携帯専用のフレームワークは不要と判断
しているのかを知りたい。
基づいて、携帯専用のフレームワークは不要と判断
しているのかを知りたい。
>>660
結論言えばfilter/pluginやrenderer/decoratorでもやればできる。
さらに言えばフレームワーク使わなくてもやればできる。
さらに言えばPHP使わなくても（ｒｙ
作ろうとしているサイトの規模に応じて適切なものを検討してね。
あとはご勝手に、と
結論言えばfilter/pluginやrenderer/decoratorでもやればできる。
さらに言えばフレームワーク使わなくてもやればできる。
さらに言えばPHP使わなくても（ｒｙ
作ろうとしているサイトの規模に応じて適切なものを検討してね。
あとはご勝手に、と
サイトの作りによるからなぁ
携帯独自のコンテンツを提供するサイトだったら
専用フレームワークが必要十分だろうけど、
両方提供する場合は専用だと嬉しくない
ただまぁ、現状の一般のフレームワークでは
携帯の邪魔くさい部分に対応しきれないのは
間違いないので、携帯向けフィルタ集みたいな
ものもあったらいいね
携帯独自のコンテンツを提供するサイトだったら
専用フレームワークが必要十分だろうけど、
両方提供する場合は専用だと嬉しくない
ただまぁ、現状の一般のフレームワークでは
携帯の邪魔くさい部分に対応しきれないのは
間違いないので、携帯向けフィルタ集みたいな
ものもあったらいいね
携帯だと、課金方法とかもある程度決まっているから
その辺の処理とかもフレームワーク側で便利にこなしてくれるといいんじゃない？
いらないいらないって叩くやつからは何も生まれてこないので、どっちかというと
作って公開してくれる人を大切にしたい。
その辺の処理とかもフレームワーク側で便利にこなしてくれるといいんじゃない？
いらないいらないって叩くやつからは何も生まれてこないので、どっちかというと
作って公開してくれる人を大切にしたい。
>>656
わかるー！おれも「viewを変えるだけでいいだろ」と思ってたけど、技術的な制約が全然違うから、作り方も別にならざるを得なくて、すごい苦労した。
なんかね、パソコン向けと携帯向けって、使っているのがHTML（とそのサブセット）というぐらいしか共通点ってないんじゃないかと思った。
GET/POSTとかないし、クッキーないし、URLの文字数に厳しい制限あるし、CSSやJavaScriptないし、Sessionはれなかったりするし、認証方式まるで違うし、そのくせ情報少ないし、これでどうやって作れっての？と思った。
もうフルブラウザしかサポートしませんといいたかったよ。
>>659
>でも携帯サイトの不自然な制約はそれすら凌駕するくらいだと思うってこと
はげどー！誰が考えたんだよ、あんな仕様・・・特にi-mode。
>>653
FilterやPluginで対応できる・・・そう思ってたときが自分にもありました。
最初から携帯も視野にいれて設計されたフレームワークならともかく、そうじゃないフレームワークではFilterごときでは対応できなくて、Controllerにも手をいれないと難しい。
「MojaviにFilterいれればクラサバアプリが作れる」というのと同じようなもん。
わかるー！おれも「viewを変えるだけでいいだろ」と思ってたけど、技術的な制約が全然違うから、作り方も別にならざるを得なくて、すごい苦労した。
なんかね、パソコン向けと携帯向けって、使っているのがHTML（とそのサブセット）というぐらいしか共通点ってないんじゃないかと思った。
GET/POSTとかないし、クッキーないし、URLの文字数に厳しい制限あるし、CSSやJavaScriptないし、Sessionはれなかったりするし、認証方式まるで違うし、そのくせ情報少ないし、これでどうやって作れっての？と思った。
もうフルブラウザしかサポートしませんといいたかったよ。
>>659
>でも携帯サイトの不自然な制約はそれすら凌駕するくらいだと思うってこと
はげどー！誰が考えたんだよ、あんな仕様・・・特にi-mode。
>>653
FilterやPluginで対応できる・・・そう思ってたときが自分にもありました。
最初から携帯も視野にいれて設計されたフレームワークならともかく、そうじゃないフレームワークではFilterごときでは対応できなくて、Controllerにも手をいれないと難しい。
「MojaviにFilterいれればクラサバアプリが作れる」というのと同じようなもん。
>>670
GET/POSTとかがないってどゆ意味？
GET/POSTとかがないってどゆ意味？
>>670
実際のブラウザシェアをキャリアが公開してくれると
嬉しいんだよな。例えばこれこれのスペックの端末が
これくらいのペースで減ってるからこの時点で非対応
に、とか判断できる。
この辺は新規開発じゃまったく情報ないから
古い仕様に合わせるってことになるわけだけど、
そうすると制約だらけで何もできないに等しく
なっちゃうんだよな。
実際には 3G じゃなくても PDC の後期の機械は
結構ハイスペックなんで、いろんなことできる。
これは仕様外の端末独自のものだけじゃなくて
仕様上も結構制約緩くなってたりする。
どうでもいいけどキャリアは端末情報をすべて XML で
提供してくれんかな。PDF じゃ全然使えねーよ。
実際のブラウザシェアをキャリアが公開してくれると
嬉しいんだよな。例えばこれこれのスペックの端末が
これくらいのペースで減ってるからこの時点で非対応
に、とか判断できる。
この辺は新規開発じゃまったく情報ないから
古い仕様に合わせるってことになるわけだけど、
そうすると制約だらけで何もできないに等しく
なっちゃうんだよな。
実際には 3G じゃなくても PDC の後期の機械は
結構ハイスペックなんで、いろんなことできる。
これは仕様外の端末独自のものだけじゃなくて
仕様上も結構制約緩くなってたりする。
どうでもいいけどキャリアは端末情報をすべて XML で
提供してくれんかな。PDF じゃ全然使えねーよ。
ごめん，めっさ長文になっちった
>>660
FilterやらRendererやらで対応は，原理的にはそりゃ何だってできるだろうけど．
あるUAには複数画面に分割したHTMLフォームで入力は932+携帯独自コード，
別のUAにはFlash読ませてエラーもFlash生成して返しますよ，なんてのは
実質的に単なる別プログラムでしょう．
あるいは認証とかで，古い端末はセッションIDをURLにくっつけてください，
でもブックマークしてもらうページにはつけちゃダメだからhiddenで渡してください，
あぁでもCookie使える新しい端末は逆にCookie以外は禁止してください，とか．
個別に考えれば「こうすればいいじゃん」とか浮かぶだろうけど，
つまりは対応できないってのではなく，汎用FWの機能内で無理して対応するより
特化FWで支援機能バリバリで対応した方が
コードの見通しもメンテ性も良いだろうなって話だわ．
まぁ「お前の設計が糞」とか言われりゃそれまでなのだが．
>>670 同志がいてくれて嬉しいｗ
>>660
FilterやらRendererやらで対応は，原理的にはそりゃ何だってできるだろうけど．
あるUAには複数画面に分割したHTMLフォームで入力は932+携帯独自コード，
別のUAにはFlash読ませてエラーもFlash生成して返しますよ，なんてのは
実質的に単なる別プログラムでしょう．
あるいは認証とかで，古い端末はセッションIDをURLにくっつけてください，
でもブックマークしてもらうページにはつけちゃダメだからhiddenで渡してください，
あぁでもCookie使える新しい端末は逆にCookie以外は禁止してください，とか．
個別に考えれば「こうすればいいじゃん」とか浮かぶだろうけど，
つまりは対応できないってのではなく，汎用FWの機能内で無理して対応するより
特化FWで支援機能バリバリで対応した方が
コードの見通しもメンテ性も良いだろうなって話だわ．
まぁ「お前の設計が糞」とか言われりゃそれまでなのだが．
>>670 同志がいてくれて嬉しいｗ
>>673
そそ、可能か不可能かといわれれば、可能。
でも、事実上不可能。
単なるフォーム入力画面でも、PCなら一画面ですむのが携帯だとHTML最大サイズが小さいから複数画面にしなきゃいけなかったりとか、
その最大サイズも端末ごとに違うから端末ごとに画面数が違うとか、
そもそもキャリアごと・端末ごとに使えるタグが違うとか。
画面数が変わるとVだけでなくCもかわるし、入力データのバリデーションもやり方が変わってくる。別の画面で入力されたデータとあわせてチェックしなきゃいけないとか。
おれの場合、共通化できたのはMだけだった。
ちょっとスレ違いになってすまんかった。でもこのスレはフレームワーク設計者もみてると思うから、携帯対応も考慮してくれるとうれしい。
そそ、可能か不可能かといわれれば、可能。
でも、事実上不可能。
単なるフォーム入力画面でも、PCなら一画面ですむのが携帯だとHTML最大サイズが小さいから複数画面にしなきゃいけなかったりとか、
その最大サイズも端末ごとに違うから端末ごとに画面数が違うとか、
そもそもキャリアごと・端末ごとに使えるタグが違うとか。
画面数が変わるとVだけでなくCもかわるし、入力データのバリデーションもやり方が変わってくる。別の画面で入力されたデータとあわせてチェックしなきゃいけないとか。
おれの場合、共通化できたのはMだけだった。
ちょっとスレ違いになってすまんかった。でもこのスレはフレームワーク設計者もみてると思うから、携帯対応も考慮してくれるとうれしい。
それは、そもそも、フレームワークになんて、ならんのでは無いのか？
としか思えん。
としか思えん。
>>673
>つまりは対応できないってのではなく，汎用FWの機能内で無理して対応するより
>特化FWで支援機能バリバリで対応した方が
>コードの見通しもメンテ性も良いだろうなって話だわ．
なんで汎用だと「無理して対応」になるの？なんで特化だと「バリバリ対応」になるの？
君の上げている理由じゃぁ普通のWEBフレームワークに普通に突っ込めるじゃん。
むしろPCと携帯でVIEWだけ分けてロジック共通にしたい時なんて、特化フレームワーク
なんて使ってたら偉い手間。
>つまりは対応できないってのではなく，汎用FWの機能内で無理して対応するより
>特化FWで支援機能バリバリで対応した方が
>コードの見通しもメンテ性も良いだろうなって話だわ．
なんで汎用だと「無理して対応」になるの？なんで特化だと「バリバリ対応」になるの？
君の上げている理由じゃぁ普通のWEBフレームワークに普通に突っ込めるじゃん。
むしろPCと携帯でVIEWだけ分けてロジック共通にしたい時なんて、特化フレームワーク
なんて使ってたら偉い手間。
>>677
なんでループさせるの？
特化してるのも汎用の拡張もやりたいように
やればいいじゃん。
作ることそのものを否定する必要はあるまい。
専用のものから汎用のものへインポート
できるかもしれないんだし。成果が誰かを
幸せにすりゃそんでいいんだよ。もちろん
まず最初に自己満足を満たすのも大事。
なんでループさせるの？
特化してるのも汎用の拡張もやりたいように
やればいいじゃん。
作ることそのものを否定する必要はあるまい。
専用のものから汎用のものへインポート
できるかもしれないんだし。成果が誰かを
幸せにすりゃそんでいいんだよ。もちろん
まず最初に自己満足を満たすのも大事。
>>677
> 君の上げている理由じゃぁ普通のWEBフレームワークに普通に突っ込めるじゃん。
↓
> 個別に考えれば「こうすればいいじゃん」とか浮かぶだろうけど，
> なんで汎用だと「無理して対応」になるの？なんで特化だと「バリバリ対応」になるの？
なんで？って……ならない理由がわからないんだが．
すごく簡単な喩え話でいうとさ，mb_send_mail()が使える環境と使えない環境で，
日本語のたいていのMUAで正常に読めるように日本語メールを送るのはどっちが楽よ？って話．
> 君の上げている理由じゃぁ普通のWEBフレームワークに普通に突っ込めるじゃん。
↓
> 個別に考えれば「こうすればいいじゃん」とか浮かぶだろうけど，
> なんで汎用だと「無理して対応」になるの？なんで特化だと「バリバリ対応」になるの？
なんで？って……ならない理由がわからないんだが．
すごく簡単な喩え話でいうとさ，mb_send_mail()が使える環境と使えない環境で，
日本語のたいていのMUAで正常に読めるように日本語メールを送るのはどっちが楽よ？って話．
結論から言うと、俺はMojavi3で商用携帯サイト作った。
当然、対応させるためにフィルタやらViewやらなんやらを作ったし、
キャリアごとに異なる認証機構もフレームワーク内で収まるようにした。
具体的な方法はいえないが。
もちろん、専用フレームワークをきちっとした形で作り上げてくれるのなら大変ありがたいよ。
当然、対応させるためにフィルタやらViewやらなんやらを作ったし、
キャリアごとに異なる認証機構もフレームワーク内で収まるようにした。
具体的な方法はいえないが。
もちろん、専用フレームワークをきちっとした形で作り上げてくれるのなら大変ありがたいよ。
だからーそのごちゃごちゃした携帯専用の処理を
Filterに突っ込めって行ってんだよ！
そんなこともで出来ねーならプログラマなんか辞めちまえよ！
Filterに突っ込めって行ってんだよ！
そんなこともで出来ねーならプログラマなんか辞めちまえよ！
だからー小規模ならそれでも構わないって行ってんだよ！
そんなことも理解できないなら人間なんか辞めちまえよ！
そんなことも理解できないなら人間なんか辞めちまえよ！
人のやり方に過剰にケチ付ける意味が分からん
色んな意見参考にして自分に取り入れていったらええやん
もともとそういうスレだし
色んな意見参考にして自分に取り入れていったらええやん
もともとそういうスレだし
どうせなら、OSからつくろうぜ。
まあ、公式サイト作ったことあれば、どういうことだかすぐに分かるよ。
filterでできると言ってるやつが、それを作って公開してくれればよいと思いました。
2chで叩いてる奴より形にして公開してるやつの方が100倍えらい。
2chで叩いてる奴より形にして公開してるやつの方が100倍えらい。
じゃあ俺はCPUから作りゅ
作れば。トランジスタでもシリコン基盤でも何でも勝手にどうぞ。
スレ違いだからもう来なくていいよ。
スレ違いだからもう来なくていいよ。
>>687
公式携帯サイトつくったことないのか？
公式携帯サイトつくったことないのか？
とりあえず携帯用フレームワークなんてｲﾗﾈ
だったら喪前が使わなければいいだけだろ。
他人の自由を制約する必要は一切なし。
他人の自由を制約する必要は一切なし。
一行レスによくこんな食いつくよなぁ
で？
>>694
少し落ち着け
少し落ち着け
そうだね。これ以上粘着されると困るからな。
最近スレの伸びがいいようだから、期待して久々に来てみたら、、、
>>670辺りの一連の話、参考になるなー。てか携帯って大変なんだね。
携帯電話はバッドノウハウの巣窟。
だからフレームワークがあると助かるよ。KEMP 期待してる。
そしていい所は俺フレームワークに取り込んで
フリーライドさせてもらうよ。
だからフレームワークがあると助かるよ。KEMP 期待してる。
そしていい所は俺フレームワークに取り込んで
フリーライドさせてもらうよ。
今一番ﾓﾘ上がってるｽﾚはここですか？違いますか？
本当にありがとうございました。
本当にありがとうございました。
>>703
おまいさんに使ってくれとは誰も強要してないが何か嫌なことでもあったのかな？
おまいさんに使ってくれとは誰も強要してないが何か嫌なことでもあったのかな？
KEMP 以外のケータイ・フレームワークってあるの？
どういたましてし
mojavi2で携帯サイト対応しようと思っていたので、なかなか勉強になった
やっぱmojavi2で携帯に対応するより、専用FW使った方が工数が低くなりそうだ
公式でなく勝手サイトだけど、そう思う。
勝手サイトでなく公式サイト作ればわかるってのは、どの辺を言ってるの?
課金がらみのセキュリティとか認証とか?
やっぱmojavi2で携帯に対応するより、専用FW使った方が工数が低くなりそうだ
公式でなく勝手サイトだけど、そう思う。
勝手サイトでなく公式サイト作ればわかるってのは、どの辺を言ってるの?
課金がらみのセキュリティとか認証とか?
携帯向け開発の話だけで十分話題が成り立つような気がするんだけど、
専用のスレってないの？
専用のスレってないの？
>>714
立てたらいいんじゃない？
立てたらいいんじゃない？
そのKEMPとかいうFWをごっそりパクって
Mojaviのプラグインにしたら怒るかなｗ
Mojaviのプラグインにしたら怒るかなｗ
こっそりパクって発表しないんなら好きにやればいいじゃないの
>>716
なんの問題もないでしょ
なんの問題もないでしょ
Mojavi On Mobileとして公開するつもりなんだけど。
AgaviやSymfonyもMojaviを堂々とパクってる。
好きにしなさい。
どうせできやしないでしょ。
好きにしなさい。
どうせできやしないでしょ。
>>719
公開してからものを言え
公開してからものを言え
今更mojaviの作ってもねぇ。誰も使わんでしょ。
とりあえず俺は使うぞ!!
>>717
BSDライセンスって知ってる？
BSDライセンスって知ってる？
mojavi2 or 3 or 4をベースにするの?
というかプラグインってどのバージョンでも問題なく動くようにできるのかな?
私も期待しております。
というかプラグインってどのバージョンでも問題なく動くようにできるのかな?
私も期待しております。
期待しても無駄だろうね。
作る前から何か作るとか言ってる場合、口だけな厨か途中で投げ出すケースが圧倒的に多い。
作る前から何か作るとか言ってる場合、口だけな厨か途中で投げ出すケースが圧倒的に多い。
それなんてtadashi？
ゴールデンウィークを過ぎるまでこの調子なのか。。。
パクルのは無理ってことか？
じゃあ、一から作るとして携帯用のフィルタでどんな機能が欲しい？
じゃあ、一から作るとして携帯用のフィルタでどんな機能が欲しい？
とりあえずethnaで色々作ってるけど、
Ruby on Rails本読むと、もっと頑張って欲しいなぁ～って思った。
Ruby on Rails本読むと、もっと頑張って欲しいなぁ～って思った。
Zend FrameworkってPEARと同じような位置づけになりそうだよね。
結局使われるのはPEAR DBよりADODB、DB_DataObjectよりPropelみたいな。
結局使われるのはPEAR DBよりADODB、DB_DataObjectよりPropelみたいな。
mojavi2使っています。
みなさんは画像のアップロードは、どうしていますか?
HTML_QuickFormを利用しようかと思ったのですが、利用を推奨していないようなので…
みなさんは画像のアップロードは、どうしていますか?
HTML_QuickFormを利用しようかと思ったのですが、利用を推奨していないようなので…
$_FILES
cakeって何がまずいの？便利に使わせて貰ってるんだけど。。
>>736
開発が遅いらしい
開発が遅いらしい
>>736
過去ログ嫁
過去ログ嫁
StrutsはView=Templateで、MojaviはViewとテンプレートが
切り離されてるんだけど、これってどっちがMVCとして正しいのかな？
切り離されてるんだけど、これってどっちがMVCとして正しいのかな？
MojaviでもテンプレートはViewの一部でしょ。
そういう意味ではどちらも間違っているということはないと思う。
Viewクラスはプレゼンテーションロジックの中でテンプレート上ではやりづらい部分を書くために用意されているだけの話で。
そういう意味ではどちらも間違っているということはないと思う。
Viewクラスはプレゼンテーションロジックの中でテンプレート上ではやりづらい部分を書くために用意されているだけの話で。
どっちでもいいと思う
テンプレートだけでViewを完結させようとすると
どうしても、制御文入りのテンプレートになってしまうからね
テンプレートだけでViewを完結させようとすると
どうしても、制御文入りのテンプレートになってしまうからね
MojaviのViewはViewHelperパターンってこと？
そう考えるのも悪くないかもね
ViewHelperはテンプレートから動的に呼び出されるロジックだけど、MojaviのViewに書くプレゼンテーションロジックはテンプレートが呼び出される前に実行される点が違うんじゃないか？
Viewがおのれ自身をtemplateにassignしたら、
ヘルパーになるよ。
おれはthisという名前でassignして
{$this->hoge()}
で呼んだりしてる。
ヘルパーになるよ。
おれはthisという名前でassignして
{$this->hoge()}
で呼んだりしてる。
>>745
Viewの中で$smarty->assign('this', $this);ってこと？
おもしろいやり方だな。俺もやってみようかな。
まあthisに限らず、smartyで言えばregister_functionやregister_modifierでViewのメソッドを登録しとけばばヘルパーになるね。
つーか、register_function自体がヘルパーを登録するものか・・・
Viewの中で$smarty->assign('this', $this);ってこと？
おもしろいやり方だな。俺もやってみようかな。
まあthisに限らず、smartyで言えばregister_functionやregister_modifierでViewのメソッドを登録しとけばばヘルパーになるね。
つーか、register_function自体がヘルパーを登録するものか・・・
zendはいつになったら完成するんですか！！！
>>747
来年の今くらいじゃないか？
来年の今くらいじゃないか？
symfonyでPDOを使って接続するのってどーやるの？
databases.ymlで設定するっぽいけど…。
symfonyでPDO使ってる人いる？
databases.ymlで設定するっぽいけど…。
symfonyでPDO使ってる人いる？
749です。
出来ますた。
自己レスでスマソ。
all:
pdo:
class: sfPDODatabase
param:
dsn: mysql://aaa:bbb@localhost/ccc
username: aaa
password: bbb
database: ccc
host: localhost
ちゃんとインデントしないと動かないようでつ。
ネイティブも同じ要領でいけまつ。
みんなはPropel使ってるのかな。
出来ますた。
自己レスでスマソ。
all:
pdo:
class: sfPDODatabase
param:
dsn: mysql://aaa:bbb@localhost/ccc
username: aaa
password: bbb
database: ccc
host: localhost
ちゃんとインデントしないと動かないようでつ。
ネイティブも同じ要領でいけまつ。
みんなはPropel使ってるのかな。
750>>
書き忘れ。
$db = sfContext::getInstance()->getDatabaseConnection('pdo');
書き忘れ。
$db = sfContext::getInstance()->getDatabaseConnection('pdo');
symfonyって
ContextをgetContextじゃなくて
sfContext::getInstance()で取得してんの？
確かにそれだと、各主要インスタンスにcontext渡さなくていいから
便利っちゃ便利そうだな
ContextをgetContextじゃなくて
sfContext::getInstance()で取得してんの？
確かにそれだと、各主要インスタンスにcontext渡さなくていいから
便利っちゃ便利そうだな
>>752
フレームワーク１年生のヘタレなので分かりませぬ。
普通はgetContextを使うんでつか？
>>750
訂正：
PDOの場合のdsnは
mysql:host=localhost;dbname=ccc
でした。ｽﾏｿ
しかし、DBから引いたデータは文字化けする模様。
>>747
Preview 0.1.2で止まってますね。
Zendよ、早くしてオクレ兄さん。
フレームワーク１年生のヘタレなので分かりませぬ。
普通はgetContextを使うんでつか？
>>750
訂正：
PDOの場合のdsnは
mysql:host=localhost;dbname=ccc
でした。ｽﾏｿ
しかし、DBから引いたデータは文字化けする模様。
>>747
Preview 0.1.2で止まってますね。
Zendよ、早くしてオクレ兄さん。
情報少ないんでezpdoは分からないけど、
O/Rマッピングにはあまり魅力を感じないんです。＜オイラだけ？
$this->getContext()でもいけるんですね。
もう少し勉強してみます。
O/Rマッピングにはあまり魅力を感じないんです。＜オイラだけ？
$this->getContext()でもいけるんですね。
もう少し勉強してみます。
久しぶりに行ったらmojavi.orgダウンしてやんの。
少なくても二日前かららしい。完全終了ですかね。
少なくても二日前かららしい。完全終了ですかね。
も、Mojavi兄さん…
金が尽きたのか？
金が尽きたのか？
mojaviはもういいzendを出せ！
前スレの初めのほうでやってた寄付金は返ってくるの？
合掌
4/10の23時頃には見れてた。
ブラウザに表示したままPCを休止状態にしたりして、
2日前くらいに次のページを見ようとしてリンクをクリックしたら、
しばし待つのだぞのページになった。。。
ブラウザに表示したままPCを休止状態にしたりして、
2日前くらいに次のページを見ようとしてリンクをクリックしたら、
しばし待つのだぞのページになった。。。
リニューアルするまで待ってね、と言っているのだから
まあ待とうじゃないか。
まあ待とうじゃないか。
>>762
往年のジャンプ漫画の「第二部を楽しみにしてくださいね」に思える俺は、ひねたやつなんだろう。
往年のジャンプ漫画の「第二部を楽しみにしてくださいね」に思える俺は、ひねたやつなんだろう。
欧米のフレームワーク関連サイトで出てくる
scaffoldingてどゆ意味？
excite翻訳で調べたら「足場」って意味わがんね
scaffoldingてどゆ意味？
excite翻訳で調べたら「足場」って意味わがんね
scaffoldingって、テンプレ作成のことじゃない？
symfonyだと、symfony init-appとかのコマンドでいくつかファイルをまとめて作ってくれるし。
symfonyだと、symfony init-appとかのコマンドでいくつかファイルをまとめて作ってくれるし。
日本語でいったら……「雛形」とかか？
雛形を（大抵は自動的に）生成したりするのを scaffolding というような気がする
雛形を（大抵は自動的に）生成したりするのを scaffolding というような気がする
なるほど！thanks!
どういたまして♪
symfony触ってみたけど最強じゃんこれ？
今まで俺フレームワークで来たけどレベルが違うわ…
今まで俺フレームワークで来たけどレベルが違うわ…
>>769
好き好きだけど、Templateが生PHPなのが、ちと気に掛かる。
好き好きだけど、Templateが生PHPなのが、ちと気に掛かる。
>>770
PHPそのままをtemplateにすると、どんな不都合があるんでしょうか。
おれてきには、Smartyとか使われるとまた覚える量が増えてしまうし、SmartyでやってることはPHPでもできてしまうので、
templateにPHPを使った場合の不都合を教えてください。またはSmartyを積極的に使う利点。
PHPそのままをtemplateにすると、どんな不都合があるんでしょうか。
おれてきには、Smartyとか使われるとまた覚える量が増えてしまうし、SmartyでやってることはPHPでもできてしまうので、
templateにPHPを使った場合の不都合を教えてください。またはSmartyを積極的に使う利点。
>>771
その話はほんとに定期的にでるね。
↓を眺めてみたら？
ttp://pc8.2ch.net/test/read.cgi/php/1118799352/
あと、君はshort_open_tag = Onな人だと思う。
その話はほんとに定期的にでるね。
↓を眺めてみたら？
ttp://pc8.2ch.net/test/read.cgi/php/1118799352/
あと、君はshort_open_tag = Onな人だと思う。
誰か asp_tags = on にしてる兵はいないのか？
てか、まだそのオプションあるのか？
てか、まだそのオプションあるのか？
Mojavi系ではsymfonyが圧倒的だから
もうM4は出ない予感。
Zend V.S. symfonyって感じに収斂していきそう。
もうM4は出ない予感。
Zend V.S. symfonyって感じに収斂していきそう。
PHP5の案件が少ないのですけど…
なんで？
おれも、synfony を使って見たいよ
なんで？
おれも、synfony を使って見たいよ
>>736
ModelがmySQL前提だからとか、マニュアルがいつまでたってもいまいちとか、
RCになってから大きな変更をホイホイ加えるとか、そういうことじゃないかな。
折角Dboを苦労してAdo-mssqlでまともに動くようにしたのに、インターフェイスが
変わってもう新しいバージョンでは使えないよ...orz
ただ、開発は遅くないと思う。でも本格的に使うなら正式リリース後がいいと思う。
あとはRailsの劣化コピーってのに我慢できるかどうか。
ModelがmySQL前提だからとか、マニュアルがいつまでたってもいまいちとか、
RCになってから大きな変更をホイホイ加えるとか、そういうことじゃないかな。
折角Dboを苦労してAdo-mssqlでまともに動くようにしたのに、インターフェイスが
変わってもう新しいバージョンでは使えないよ...orz
ただ、開発は遅くないと思う。でも本格的に使うなら正式リリース後がいいと思う。
あとはRailsの劣化コピーってのに我慢できるかどうか。
>>774
symfonyって、漢字でUTF-8以外の、EUCとかSJISの文字コード使えるの？
UTF-8しか使えないとなると、国産も生き残るものがある様な気がする。
まあ、AJAXとかしだすと、UTF-8にせざるを得ないケースが多いんだけど。
symfonyって、漢字でUTF-8以外の、EUCとかSJISの文字コード使えるの？
UTF-8しか使えないとなると、国産も生き残るものがある様な気がする。
まあ、AJAXとかしだすと、UTF-8にせざるを得ないケースが多いんだけど。
smartyいらいんよね。遅くなるだけ。覚えることが増えるだけ。
ethnaってmojavi2とどの位互換性がありますか?
mojavi2がPHP5で使えないので、module以下を移せば使えるかなぁと思いまして…
mojavi2がPHP5で使えないので、module以下を移せば使えるかなぁと思いまして…
>>778
テンプレートはなにがよさげ？自前かな
テンプレートはなにがよさげ？自前かな
>>778
smartyの覚えることよりphpの覚えることのほうが100倍多いわな。
smartyの覚えることよりphpの覚えることのほうが100倍多いわな。
やっぱ生が一番だよな
short_tagなんて、それを使うことが問題になるケースもあるってだけ。
sedで置換しても数秒で終わる話。
まったく本質じゃない。
SmartyというのはJSPにあこがれた、そんな時代もあったねということ。
実際、すでにンプレートエンジンは使わないという流れが出来てるじゃないか。
sedで置換しても数秒で終わる話。
まったく本質じゃない。
SmartyというのはJSPにあこがれた、そんな時代もあったねということ。
実際、すでにンプレートエンジンは使わないという流れが出来てるじゃないか。
フレームワークは、多くの人が使えないと意味がない。
フレームワークを採用することで、経験の少ないPGにも一定の品質を強いることができる。
無駄に覚えることを増やす理由はどこにもないということ。
フレームワークを採用することで、経験の少ないPGにも一定の品質を強いることができる。
無駄に覚えることを増やす理由はどこにもないということ。
> 実際、すでにンプレートエンジンは使わないという流れが出来てるじゃないか。
はつみみです。
そういうことにしたいのですね？:)
はつみみです。
そういうことにしたいのですね？:)
voidたんﾅﾂｶｼｽ
Smarty は，ちょっとHTMLコーダがやっちゃっただけでもすぐ PHP エラー吐くのが
気に入らないといえなくもない
テンプレート側の誤記に関してはもーちっと堅くあってほしいね
Smarty は，ちょっとHTMLコーダがやっちゃっただけでもすぐ PHP エラー吐くのが
気に入らないといえなくもない
テンプレート側の誤記に関してはもーちっと堅くあってほしいね
Smartyの遅さは異常
>>785
> 実際、すでにンプレートエンジンは使わないという流れが出来てるじゃないか。
どの辺を根拠にしているのか、具体例を挙げてもらえると分かり易いですね。
AJAX用のFrameworkは、単純にsmartyが使えなくて、ob_startとかを併用する
必要があるものがありますが、「使わないという流れ」とは繋がらないし・・・。
symfonyを見てそう言っているのなら、それだけで「流れ」がそうなると言うには、
論拠として弱すぎだし・・・。
> 実際、すでにンプレートエンジンは使わないという流れが出来てるじゃないか。
どの辺を根拠にしているのか、具体例を挙げてもらえると分かり易いですね。
AJAX用のFrameworkは、単純にsmartyが使えなくて、ob_startとかを併用する
必要があるものがありますが、「使わないという流れ」とは繋がらないし・・・。
symfonyを見てそう言っているのなら、それだけで「流れ」がそうなると言うには、
論拠として弱すぎだし・・・。
>>777
オイラはsymfonyでeuc-jpだけど文字化けしてないでつよ。
apps/app/config/view.yml
を設定すれば良いと思ふ。（たぶん）
apps/app/templates/layout.php
で強引に、ってのもアリかも。
ちなみに
>>753
の文字化けはmy.cnfに
[mysqld]
skip-character-set-client-handshake
で直りますた。
オイラはsymfonyでeuc-jpだけど文字化けしてないでつよ。
apps/app/config/view.yml
を設定すれば良いと思ふ。（たぶん）
apps/app/templates/layout.php
で強引に、ってのもアリかも。
ちなみに
>>753
の文字化けはmy.cnfに
[mysqld]
skip-character-set-client-handshake
で直りますた。
O/Rマッパと分散DBの両立させてる人いる？
こういうのってO/Rマッパの上に一層かぶせるんかな。
こういうのってO/Rマッパの上に一層かぶせるんかな。
>>791 横からレスするけど...
Symphony,Cakeはじめ、Railsの影響を受けた後発のフレームワークは
テンプレートエンジンを備えてないか、デフォルトで無効になってる奴が多いよ。調べてみ。
Railsの作者もはっきりeruby以外のテンプレートエンジンは
Railsには不要と言っていたような気がする。
ま、これはRailsっていう流行の影響なわけで、>>785のように
テンプレートエンジンを使わん流れと見なすのには解釈が分かれるとこかもしれないが。
Symphony,Cakeはじめ、Railsの影響を受けた後発のフレームワークは
テンプレートエンジンを備えてないか、デフォルトで無効になってる奴が多いよ。調べてみ。
Railsの作者もはっきりeruby以外のテンプレートエンジンは
Railsには不要と言っていたような気がする。
ま、これはRailsっていう流行の影響なわけで、>>785のように
テンプレートエンジンを使わん流れと見なすのには解釈が分かれるとこかもしれないが。
795 ：nobodyさん：2006/04/16(日) 19:24:48 ID:LCwI0Ihf
SMARTYは面倒で遅い。
面倒だけど速い。楽だけど遅い。これなら検討するが、SMARTYは考えるまでもない。
面倒だけど速い。楽だけど遅い。これなら検討するが、SMARTYは考えるまでもない。
たしかにSmartyは時代のあだ花くさいな。
流れを見ていると。
流れを見ていると。
デザイナに対して、アプリケーションロジックを壊させない、サーバーリソースに無闇にアクセスさせない、などの環境が楽に作れることが利点になるなら積極的に使ったらいいんじゃないか？
サイトの規模とかプロジェクトメンバーの人数とレベルなど色々検討して利点にならないと判断できるなら使わなければいいだけだし。
あとsmartyのラッパクラスをそのままViewにすることもできるし、デコレータやレンダラに組み込むのも容易にできるような仕組みになってる。
ヘルパーを拡張する機能（register_functionやregister_modifier）もちゃんとある。
だいたい<?php echoが頻出するソースよりテンプレートのほうがずっと見やすいしレイアウトの編集しやすいよ。
実際にはコンパイル結果はPHPのコードをキャッシュしててincludeするだけだから、生PHPと比べて極端に速度が落ちることは考えられない。
むしろ体感速度として遅くはない。
サイトの規模とかプロジェクトメンバーの人数とレベルなど色々検討して利点にならないと判断できるなら使わなければいいだけだし。
あとsmartyのラッパクラスをそのままViewにすることもできるし、デコレータやレンダラに組み込むのも容易にできるような仕組みになってる。
ヘルパーを拡張する機能（register_functionやregister_modifier）もちゃんとある。
だいたい<?php echoが頻出するソースよりテンプレートのほうがずっと見やすいしレイアウトの編集しやすいよ。
実際にはコンパイル結果はPHPのコードをキャッシュしててincludeするだけだから、生PHPと比べて極端に速度が落ちることは考えられない。
むしろ体感速度として遅くはない。
railsは、<% %> だっけ？
phpもasp形式のショートタグをデフォルト推奨にしてくれたらいいのに。どうだろう？
phpもasp形式のショートタグをデフォルト推奨にしてくれたらいいのに。どうだろう？
Smartyそのものの是非は割とどうでもよく、
今現在WEBデザインの効率を考える上で
どのような手法がホットなのか、
Smartyからどこへシフトしているのかが知りたい
今現在WEBデザインの効率を考える上で
どのような手法がホットなのか、
Smartyからどこへシフトしているのかが知りたい
phpなら生で
まあsmarty不必要論自体に関してはこれ以上議論の余地はなさそうだしな。
phpタグはxml宣言とかぶって仕方なく「<?php」にした歴史があるから、どうも記述形式が宙ぶらりんなんだよな。
「<?=」が使えたらかなりすっきりするとは思う。
でもこれもまた「<? echo」のショートカットであると定義されてしまっていて、short_open_tagの一種なのでどうにもならない。
phpタグはxml宣言とかぶって仕方なく「<?php」にした歴史があるから、どうも記述形式が宙ぶらりんなんだよな。
「<?=」が使えたらかなりすっきりするとは思う。
でもこれもまた「<? echo」のショートカットであると定義されてしまっていて、short_open_tagの一種なのでどうにもならない。
<% %>
もうにしちゃえばいいのに
もうにしちゃえばいいのに
サイト見てたらsymfonyもAction=メソッドじゃん？
Zendもそうだし。こういうの流行ってるのかな？
guessworkもそうだね。
Zendもそうだし。こういうの流行ってるのかな？
guessworkもそうだね。
>>797
アプリケーションロジックを壊させないっていっても、どうせデザイナが
信用できない以上、コードチェックとテストはしなきゃいけないから手間は一緒じゃないかな?
オープンタグだけが問題ならそれこそrails風に h() という関数とか書けば?
あった方が好ましいとか、簡単に組み込めるからくらいの理由で余計なレイヤーを
追加するのはいやだな。
そういうのはどうしても無きゃダメっていうときだけ積極的になるべきじゃないか。
アプリケーションロジックを壊させないっていっても、どうせデザイナが
信用できない以上、コードチェックとテストはしなきゃいけないから手間は一緒じゃないかな?
オープンタグだけが問題ならそれこそrails風に h() という関数とか書けば?
あった方が好ましいとか、簡単に組み込めるからくらいの理由で余計なレイヤーを
追加するのはいやだな。
そういうのはどうしても無きゃダメっていうときだけ積極的になるべきじゃないか。
>>805
なんか言いがかりっぽいけど・・・
> アプリケーションロジックを壊させないっていっても、どうせデザイナが
> 信用できない以上、コードチェックとテストはしなきゃいけないから手間は一緒じゃないかな?
ぜんぜん一緒じゃないよ。smartyでヘンなことしようとしてたらくっきりわかるよ。
少なくとも不意に介入してしまう危険性の方は減るでしょ。
> オープンタグだけが問題ならそれこそrails風に h() という関数とか書けば?
<?php h($var) ?>って<?php echo $var ?>とほとんど変わんないじゃん。
{$var}と比べてごらんなさい。このすっきり具合。
> あった方が好ましいとか、簡単に組み込めるからくらいの理由で余計なレイヤーを
> 追加するのはいやだな。
> そういうのはどうしても無きゃダメっていうときだけ積極的になるべきじゃないか。
なんじゃそりゃ。フレームワークって楽するために余計なレイヤーをはさむものでしょ。
まあ好き好きなんだろうけど。
なんか言いがかりっぽいけど・・・
> アプリケーションロジックを壊させないっていっても、どうせデザイナが
> 信用できない以上、コードチェックとテストはしなきゃいけないから手間は一緒じゃないかな?
ぜんぜん一緒じゃないよ。smartyでヘンなことしようとしてたらくっきりわかるよ。
少なくとも不意に介入してしまう危険性の方は減るでしょ。
> オープンタグだけが問題ならそれこそrails風に h() という関数とか書けば?
<?php h($var) ?>って<?php echo $var ?>とほとんど変わんないじゃん。
{$var}と比べてごらんなさい。このすっきり具合。
> あった方が好ましいとか、簡単に組み込めるからくらいの理由で余計なレイヤーを
> 追加するのはいやだな。
> そういうのはどうしても無きゃダメっていうときだけ積極的になるべきじゃないか。
なんじゃそりゃ。フレームワークって楽するために余計なレイヤーをはさむものでしょ。
まあ好き好きなんだろうけど。
>>806
> <?php h($var) ?>って<?php echo $var ?>とほとんど変わんないじゃん。
> {$var}と比べてごらんなさい。このすっきり具合。
普通の知能があるなら、どれも全部変わらないよ。
ウェブデザイナをバカにしすぎ。
それに<?=$var?>でもいいじゃん。
XML宣言したいんだったら、その部分だけoutput buffering処理で付け足せばいい。
> <?php h($var) ?>って<?php echo $var ?>とほとんど変わんないじゃん。
> {$var}と比べてごらんなさい。このすっきり具合。
普通の知能があるなら、どれも全部変わらないよ。
ウェブデザイナをバカにしすぎ。
それに<?=$var?>でもいいじゃん。
XML宣言したいんだったら、その部分だけoutput buffering処理で付け足せばいい。
> なんじゃそりゃ。フレームワークって楽するために余計なレイヤーをはさむものでしょ。
他の部分はともかくここにはとても同意
余計なレイヤを挟みたくないなら素の PHP で書けばいいしね
他の部分はともかくここにはとても同意
余計なレイヤを挟みたくないなら素の PHP で書けばいいしね
{$var|escape}の代わりの<?=esc($var)?>ってラッパーを書けばいいってこと。
{$var|escape:"url"}と<?=urlesc($var)?>、どちらが簡潔か？
プログラマーにとっても、カスタム修正子作るより関数作る方が簡単だし、柔軟なものが作れる。
当然関数の方が処理速度も速い。
{$var|escape:"url"}と<?=urlesc($var)?>、どちらが簡潔か？
プログラマーにとっても、カスタム修正子作るより関数作る方が簡単だし、柔軟なものが作れる。
当然関数の方が処理速度も速い。
<% %>がデフォルトで使えるようになってくれたらいいのになぁ。
>>810
カスタム修正子より関数の方が簡単って、register_modifierのたった一文を書くか書かないかの違いだけだし。
あと処理速度は変わらんて。同じphpコードに変換されるんだから。コンパイル済みのコード見てみ。
カスタム修正子より関数の方が簡単って、register_modifierのたった一文を書くか書かないかの違いだけだし。
あと処理速度は変わらんて。同じphpコードに変換されるんだから。コンパイル済みのコード見てみ。
そろそろ「単に言い張ってるだけ」になってまいりました
この話題たぶんずっとループだからやめにしない？
この話題たぶんずっとループだからやめにしない？
Railsの作者は「<% %>じゃテンプレートのプレビューができないじゃマイカ」という
声に対して、「Railsは動作確認のためにセットアップするのが簡単だから、デザイナー
にもRailsの動く環境を用意してあげて、そこでプレビューさせればいいじゃない」という
スタンスなんだけど（別途Webサーバを用意する必要がない）、SymfonyとかCakeは
そのあたりどうパクるつもりだろう。
声に対して、「Railsは動作確認のためにセットアップするのが簡単だから、デザイナー
にもRailsの動く環境を用意してあげて、そこでプレビューさせればいいじゃない」という
スタンスなんだけど（別途Webサーバを用意する必要がない）、SymfonyとかCakeは
そのあたりどうパクるつもりだろう。
>>810
{$var|escape|nl2br} は？
修正子にパラメータが付いたときの表記は、確かに冗長だけど、
変数の後ろに処理を記述する方法は、直感的に理解し易い表記
方法だと思う。
>>813
確かに、宗教論争っぽくなって来ている。
{$var|escape|nl2br} は？
修正子にパラメータが付いたときの表記は、確かに冗長だけど、
変数の後ろに処理を記述する方法は、直感的に理解し易い表記
方法だと思う。
>>813
確かに、宗教論争っぽくなって来ている。
>>807
>普通の知能があるなら、どれも全部変わらないよ。
>ウェブデザイナをバカにしすぎ。
この人はできるウェブデザイナとしか仕事したこと無いんだろうね。
（この「できる」は「普通にできる」の範囲で）
もうどうしようもないの居るから。本当に。しかもかなりの確率で。
<?って入った時点で思考停止させるやつとか。
でも仕事は終わらせないとダメだからさ。
俺らにとって変わらないと思うくらいのことでもすり寄ってあげないとダメなんさ。
>普通の知能があるなら、どれも全部変わらないよ。
>ウェブデザイナをバカにしすぎ。
この人はできるウェブデザイナとしか仕事したこと無いんだろうね。
（この「できる」は「普通にできる」の範囲で）
もうどうしようもないの居るから。本当に。しかもかなりの確率で。
<?って入った時点で思考停止させるやつとか。
でも仕事は終わらせないとダメだからさ。
俺らにとって変わらないと思うくらいのことでもすり寄ってあげないとダメなんさ。
ここでのsmarty不要論ってのは、smartyが異常に遅いという前提があると思うんだけど、
私の経験と、この前提は一致しない。(ベンチとった訳ではないけど)
レイヤー増えるんだから、早くなることはありえないけど、通常は十分な速度が出ていると
思うんだけど、どうだろう？
FW入れるという前提があって、そこで使うテンプレートが生PHPで記述するタイプと、
smartyを使って、初回起動時にsmartyが生成したphpを使うのと、速度的に、どの程度
の差があるのか比較した場合、実質的に差が無いのではないかと言う気がする。
私の経験と、この前提は一致しない。(ベンチとった訳ではないけど)
レイヤー増えるんだから、早くなることはありえないけど、通常は十分な速度が出ていると
思うんだけど、どうだろう？
FW入れるという前提があって、そこで使うテンプレートが生PHPで記述するタイプと、
smartyを使って、初回起動時にsmartyが生成したphpを使うのと、速度的に、どの程度
の差があるのか比較した場合、実質的に差が無いのではないかと言う気がする。
>>817
速度の差がないなら、なぜSmartyを推すの?
どうもsmarty擁護論の前提はデザイナとの連携みたいだけど、
デザイナとの連携が必要ない場合のメリットていうと
(例えば、見本ページが全ページ用意されていて、そこにデータを
流し込むだけとか、デザインはどうでも良いという客とか)
見やすい以外になにかあるのかな?
#◯◯は必要ありませんからその分安くしてください
#っていう客の是非はこの際おいといて...
速度の差がないなら、なぜSmartyを推すの?
どうもsmarty擁護論の前提はデザイナとの連携みたいだけど、
デザイナとの連携が必要ない場合のメリットていうと
(例えば、見本ページが全ページ用意されていて、そこにデータを
流し込むだけとか、デザインはどうでも良いという客とか)
見やすい以外になにかあるのかな?
#◯◯は必要ありませんからその分安くしてください
#っていう客の是非はこの際おいといて...
patTemplateてのはどうなん？
オイラ的にSmartyは不要だと思うけど、
必要だと思う人は使えばよいのでは？
symfonyでSmartyしたいのならsmartyViewを使え良いと思ふ。
http://www.symfony-project.com/forum/index.php/m/1488/#msg_1488
必要だと思う人は使えばよいのでは？
symfonyでSmartyしたいのならsmartyViewを使え良いと思ふ。
http://www.symfony-project.com/forum/index.php/m/1488/#msg_1488
>>819
817じゃないけど、速度に触れてるのは「smartyは遅い」とかいい加減な書き込みをしてたアホがわいてたからでしょ。
俺はsmarty擁護派というか、普通に便利だったり楽だったり見易かったりする側面もあると思うので、反対派に対しては積極的に反対するけど>>821の意見とは衝突しない。
結局ケースバイケース、十人十色、適材適所で何の不満もない。
必要のない人にまで押し付ける気はさらさらないね。
俺だってsmartyが常に最善の選択になるとまでは考えてない。
それでもソースが簡潔に書けるので俺は使う。
817じゃないけど、速度に触れてるのは「smartyは遅い」とかいい加減な書き込みをしてたアホがわいてたからでしょ。
俺はsmarty擁護派というか、普通に便利だったり楽だったり見易かったりする側面もあると思うので、反対派に対しては積極的に反対するけど>>821の意見とは衝突しない。
結局ケースバイケース、十人十色、適材適所で何の不満もない。
必要のない人にまで押し付ける気はさらさらないね。
俺だってsmartyが常に最善の選択になるとまでは考えてない。
それでもソースが簡潔に書けるので俺は使う。
#
# s.php
#
<?php
require_once('Smarty/Smarty.class.php');
$smarty = new Smarty();
$smarty->template_dir = './templates';
$smarty->compile_dir = './templates_c';
$smarty->cache_dir = './cache';
$smarty->config_dir = './configs';
$smarty->caching = 1;
$smarty->assign('num', mt_rand());
$smarty->display('index.tpl');
?>
<html>
<body>
{$num|escape}
</body>
</html>
# s.php
#
<?php
require_once('Smarty/Smarty.class.php');
$smarty = new Smarty();
$smarty->template_dir = './templates';
$smarty->compile_dir = './templates_c';
$smarty->cache_dir = './cache';
$smarty->config_dir = './configs';
$smarty->caching = 1;
$smarty->assign('num', mt_rand());
$smarty->display('index.tpl');
?>
<html>
<body>
{$num|escape}
</body>
</html>
#
# not_s.php
#
<?php
function e($str){
return htmlspecialchars($str);
}
$num = mt_rand();
?>
<html>
<body>
<?php print e($num) ?>
<body>
</html>
# not_s.php
#
<?php
function e($str){
return htmlspecialchars($str);
}
$num = mt_rand();
?>
<html>
<body>
<?php print e($num) ?>
<body>
</html>
ab.exe -n 500 -c 10
s.php
Requests per second: 57.54 [#/sec] (mean)
not_s.php
Requests per second: 631.59 [#/sec] (mean)
s.php
Requests per second: 57.54 [#/sec] (mean)
not_s.php
Requests per second: 631.59 [#/sec] (mean)
ちなみにSmartyのescapeはださいと思う。
もっと短くして欲しいし、もっといえば
デフォルトでエスケープされるようにして欲しい。
もっと短くして欲しいし、もっといえば
デフォルトでエスケープされるようにして欲しい。
おまけ
s.php（キャッシュなし）
Requests per second: 52.26 [#/sec] (mean)
s.php（キャッシュなし）
Requests per second: 52.26 [#/sec] (mean)
>>826
デフォルトでescapeの設定はできたんじゃなかったっけ？
デフォルトでescapeの設定はできたんじゃなかったっけ？
フレームワークスレで、not_s.phpみたいなコード見るとは思わなかった。
こんな竹槍戦法じゃ仕事にならないから、速度を犠牲にしてでもFW使う訳で・・・。
中のコードが、もう少し現実的な分量になっただけでも、差はかなり縮まる。
こんな竹槍戦法じゃ仕事にならないから、速度を犠牲にしてでもFW使う訳で・・・。
中のコードが、もう少し現実的な分量になっただけでも、差はかなり縮まる。
速度差10倍超
とうとうこんなくそコードまで出してベンチ取り出す始末
単なる意地の張り合い（というか否定派だけか意地張ってるのは）になってるから
もうやめろってのに
単なる意地の張り合い（というか否定派だけか意地張ってるのは）になってるから
もうやめろってのに
832 ：nobodyさん：2006/04/17(月) 17:15:06 ID:r0ZxVhnD
まあグラフィックボードが速くても、CPUが遅ければシステム全体の処理は速くならない。
しかし、高い金を払って遅いビデオボードを買うのは不思議な行為だな。
しかし、高い金を払って遅いビデオボードを買うのは不思議な行為だな。
俺はsmartyに最初にケチつけた書き込みを見た瞬間に頭の弱い子のレスなのだと悟ったよ。
まさかここまで再確認させてくれるとは思わなかった（唖然）
まさかここまで再確認させてくれるとは思わなかった（唖然）
>>832
マトモな会話をしたいならたとえ話は話が発散するだけだからやめた方がいいぞ
ぜったい「例えが違う、それを言うなら……」って奴が出てきて話がそれるから
マトモな会話をしたくないならチラシの裏とかへどぞー
マトモな会話をしたいならたとえ話は話が発散するだけだからやめた方がいいぞ
ぜったい「例えが違う、それを言うなら……」って奴が出てきて話がそれるから
マトモな会話をしたくないならチラシの裏とかへどぞー
>>776 なんだけど...
ちょっとフォローしとくとmySQL前提なら生産性は結構あがるし、
上部の構造の見通しは今のところよいので、cakeも言うほど悪くないと思う。
まだベータだしね。最終的な評価はもうすぐ出るはずのリリース版を見てからでもよいはず。
しかし、テンプレートエンジン云々って凄い荒れる話題なんだね(w
すげぇレスが伸びててビビった。
では、続きをどうぞ。
ちょっとフォローしとくとmySQL前提なら生産性は結構あがるし、
上部の構造の見通しは今のところよいので、cakeも言うほど悪くないと思う。
まだベータだしね。最終的な評価はもうすぐ出るはずのリリース版を見てからでもよいはず。
しかし、テンプレートエンジン云々って凄い荒れる話題なんだね(w
すげぇレスが伸びててビビった。
では、続きをどうぞ。
結局の所「ほとんどどっちでもいい」から
宗教論争になっちゃうんだと思ふ
宗教論争になっちゃうんだと思ふ
838 ：nobodyさん：2006/04/17(月) 19:36:07 ID:r0ZxVhnD
10分の1以下のスピードでよければ、確かにどっちでもいいかも。
>>838
数字の読み方分かって無いね。
それぞれの逆数を取って、一回あたりの所要時間を出して引き算する。
大雑把だけど、その値がsmarty導入によって増加した時間。
実際のアプリは、このサンプルと比べて、2,3桁は処理量が増えるので、
その中でsmartyの所要時間がどの程度の比率になるかがポイント。
せめてsymfonyで hello world を、生php、smartyテンプレートの両方で
作ってみて、比較するぐらいの事をしないとね。
たぶん、「symfonyの遅さは異常」という結論が出てくる事でしょう。:-P
ちなみに、使用するFrameworkはなんでも良い。symfonyは、生php,
smartyの両方が使えるという事なので挙げただけ。どんなFrameworkを
使っても同じ結論が出る筈。
数字の読み方分かって無いね。
それぞれの逆数を取って、一回あたりの所要時間を出して引き算する。
大雑把だけど、その値がsmarty導入によって増加した時間。
実際のアプリは、このサンプルと比べて、2,3桁は処理量が増えるので、
その中でsmartyの所要時間がどの程度の比率になるかがポイント。
せめてsymfonyで hello world を、生php、smartyテンプレートの両方で
作ってみて、比較するぐらいの事をしないとね。
たぶん、「symfonyの遅さは異常」という結論が出てくる事でしょう。:-P
ちなみに、使用するFrameworkはなんでも良い。symfonyは、生php,
smartyの両方が使えるという事なので挙げただけ。どんなFrameworkを
使っても同じ結論が出る筈。
smartyは生のPHPに比べて劇的に遅いというのは事実だから。
CPUやディスクが遅ければグラフィックボードが速くても全体のパフォーマンスが上がらないというのは事実だが、
そのグラフィックボードが遅いという事実を否定するものでもない。
CPUやディスクが遅ければグラフィックボードが速くても全体のパフォーマンスが上がらないというのは事実だが、
そのグラフィックボードが遅いという事実を否定するものでもない。
例えば、Perlの場合、低機能だけど軽いH::Tと高機能だけど重いTT、どちらを使うかはケースバイケース。
はてなやmixiは組み合わせて使ってる。
しかし、smartyの場合どうか？
smartyのメリットを挙げれば、
・<?=h($var)?>より{$var|escape}の方が見やすい（と感じる）
・smartyの文法は知ってるけど、PHPの文法は知らないウェブデザイナが担当の場合
これくらいか。
デメリットは、
・10倍の遅さ
・smartyの学習コスト
・smartyの文法から来る柔軟性の制限
これでどちらがいいか選べばいい。
はっきり言って自明と思うけど。
はてなやmixiは組み合わせて使ってる。
しかし、smartyの場合どうか？
smartyのメリットを挙げれば、
・<?=h($var)?>より{$var|escape}の方が見やすい（と感じる）
・smartyの文法は知ってるけど、PHPの文法は知らないウェブデザイナが担当の場合
これくらいか。
デメリットは、
・10倍の遅さ
・smartyの学習コスト
・smartyの文法から来る柔軟性の制限
これでどちらがいいか選べばいい。
はっきり言って自明と思うけど。
まあ、正直言うと、もう1個smartyのメリットってあって、
・テンプレートエンジンを使ってるオレってカッコいい。雑誌に使えって載ってたし。
というのもあるよ。
・テンプレートエンジンを使ってるオレってカッコいい。雑誌に使えって載ってたし。
というのもあるよ。
>>841と同じ疑問なんですけど、Smartyのようなテンプレートエンジンを使う理由として、読みやすいことを挙げている人に質問。
確かに <?php echo htmlspecialchars($var); ?> よりはSmartyのほうが見やすいと思うけど、
foreach文やif文なら、とりたてて生PHPよりSmartyとかのほうが見やすいとは思わないんですけど、そのへんはどうでしょうか。
つまり、「見やすい」のはechoまわりぐらいだけで、あとは生PHPでも>>841のようにh()とか定義してしまえばそんなにかわんないんじゃないかというのが印象です。
例えばJavaのMayaaだとテンプレートのHTMLデザインがまったく崩れないという特徴があるんですが、これだと生PHPと比較して明確な利点があるんで、テンプレートエンジンを使う理由はわかります。
しかしSmarty程度の機能だと、生PHPとの差別化ができてないんじゃないかと思うんです。Smartyでできることは、同じようにPHPでもできる。
これが、PHPだとごちゃごちゃすることがSmartyだとその名の通りスマートにできるというんならいいんですけど、今までの議論見る限り、echo周りぐらいしか利点があがってないようにみえます。
あと、テンプレートはデザイナーに任せると思いますけど、DreamweaverはPHPには対応しているんですが、Smartyには対応してないです（というか、いちいち個別の文法に対応するわけがない）。
それを考えても、なんでSmartyを選ぶのかがわからないので、Smarty（だけじゃないくて他のテンプレートエンジン）を選んでいる人に、Smartyを採用した積極的な理由というのを教えていただきたいです。お願い。
確かに <?php echo htmlspecialchars($var); ?> よりはSmartyのほうが見やすいと思うけど、
foreach文やif文なら、とりたてて生PHPよりSmartyとかのほうが見やすいとは思わないんですけど、そのへんはどうでしょうか。
つまり、「見やすい」のはechoまわりぐらいだけで、あとは生PHPでも>>841のようにh()とか定義してしまえばそんなにかわんないんじゃないかというのが印象です。
例えばJavaのMayaaだとテンプレートのHTMLデザインがまったく崩れないという特徴があるんですが、これだと生PHPと比較して明確な利点があるんで、テンプレートエンジンを使う理由はわかります。
しかしSmarty程度の機能だと、生PHPとの差別化ができてないんじゃないかと思うんです。Smartyでできることは、同じようにPHPでもできる。
これが、PHPだとごちゃごちゃすることがSmartyだとその名の通りスマートにできるというんならいいんですけど、今までの議論見る限り、echo周りぐらいしか利点があがってないようにみえます。
あと、テンプレートはデザイナーに任せると思いますけど、DreamweaverはPHPには対応しているんですが、Smartyには対応してないです（というか、いちいち個別の文法に対応するわけがない）。
それを考えても、なんでSmartyを選ぶのかがわからないので、Smarty（だけじゃないくて他のテンプレートエンジン）を選んでいる人に、Smartyを採用した積極的な理由というのを教えていただきたいです。お願い。
同じ人かな？
別に俺はそこまでSmartyをこき下ろすつもりはなかったんだが…
別に俺はそこまでSmartyをこき下ろすつもりはなかったんだが…
遅さが嫌なら
Smartyとほぼ同様の機能で速度は数倍のSimplateがあるよ。
だから結局どっちでもいい、と思う。
Smartyとほぼ同様の機能で速度は数倍のSimplateがあるよ。
だから結局どっちでもいい、と思う。
前にテンプレートエンジンのスレにも Smarty のみならず PHP でテンプレートエンジンを
使うこと自体を断固として否定する人いたよね。
使うこと自体を断固として否定する人いたよね。
>>848
同一人物の匂いがする。
同一人物の匂いがする。
なんか数年前のMLのログでも見かけたんだけど
同じ人だったらある意味すげぇ
同じ人だったらある意味すげぇ
>>844
>それを考えても、なんでSmartyを選ぶのかがわからないので、Smarty（だけじゃないくて他のテンプレートエンジン）を選んでいる人に、Smartyを採用した積極的な理由というのを教えていただきたいです。お願い。
俺ただの傍観者だけど、誰も844の問いには真正面から答えないの？
>それを考えても、なんでSmartyを選ぶのかがわからないので、Smarty（だけじゃないくて他のテンプレートエンジン）を選んでいる人に、Smartyを採用した積極的な理由というのを教えていただきたいです。お願い。
俺ただの傍観者だけど、誰も844の問いには真正面から答えないの？
>>851
そこのMLの人も、インチキくさいベンチ結果で遅いとか言ってたの？
そこのMLの人も、インチキくさいベンチ結果で遅いとか言ってたの？
じゃあSmartyを使う理由は
「特に意味は無いけどカッコイイから」
ってことでOK？
「特に意味は無いけどカッコイイから」
ってことでOK？
>>854
そう判断したのなら、それが正解。
そう判断したのなら、それが正解。
>>844
echo まわりだけとはいえテンプレートの機能使用のほとんどはそこなんだから
それだけでも大きく違うと思うけど……
生PHPではちょっといじるだけですぐにPHPエラーとか吐くようになってしまうから，
それをいじる非プログラマから見て心理的抵抗感が大きい……とかー
Smarty はテンプレートの変更で致命的エラーを起こせるので個人的にはちょっとイマイチ．
生PHPでは出力する変数をグローバルに置いたりするので名前空間汚染が嫌，とかー
Smarty の場合でいうと，デフォルト変数修飾子で出力値の自由な加工をする枠組みを用意してある，とかー
> Smartyでできることは、同じようにPHPでもできる。
Smarty は PHP で書かれてるんだから，そりゃできなきゃ困るｗ
フレームワークってそういうものでしょ．
echo まわりだけとはいえテンプレートの機能使用のほとんどはそこなんだから
それだけでも大きく違うと思うけど……
生PHPではちょっといじるだけですぐにPHPエラーとか吐くようになってしまうから，
それをいじる非プログラマから見て心理的抵抗感が大きい……とかー
Smarty はテンプレートの変更で致命的エラーを起こせるので個人的にはちょっとイマイチ．
生PHPでは出力する変数をグローバルに置いたりするので名前空間汚染が嫌，とかー
Smarty の場合でいうと，デフォルト変数修飾子で出力値の自由な加工をする枠組みを用意してある，とかー
> Smartyでできることは、同じようにPHPでもできる。
Smarty は PHP で書かれてるんだから，そりゃできなきゃ困るｗ
フレームワークってそういうものでしょ．
858 ：nobodyさん：2006/04/18(火) 02:52:00 ID:0WmA3v/B
symfony触ってるんだけど、
PhingってPEARからちゃんと入る？
install okって言われたのに、
>symfony propel-build-model
とやったら、Phing.phpがないと言われる。
仕方ないから
sandboxを解凍して、
プロジェクトディレクトリのlibに、Phingディレクトリをコピーしたけど…。
なんか納得（´・ω・）ｲｶﾅｽ
PhingってPEARからちゃんと入る？
install okって言われたのに、
>symfony propel-build-model
とやったら、Phing.phpがないと言われる。
仕方ないから
sandboxを解凍して、
プロジェクトディレクトリのlibに、Phingディレクトリをコピーしたけど…。
なんか納得（´・ω・）ｲｶﾅｽ
>>857
>echo まわりだけとはいえテンプレートの機能使用のほとんどはそこなんだから
えー、それは違うだろ。foreachやifやincludeだって多用しないか？
>生PHPではちょっといじるだけですぐにPHPエラーとか吐くようになってしまうから，
>それをいじる非プログラマから見て心理的抵抗感が大きい……とかー
よくわかんね。Smartyのエラー表示は優れているのか？
>Smarty はテンプレートの変更で致命的エラーを起こせるので個人的にはちょっとイマイチ．
じゃあなにがいいのだ？ついでにその致命的エラーを詳しく。
>生PHPでは出力する変数をグローバルに置いたりするので名前空間汚染が嫌，とかー
生PHPでも、include()とextract()を使えば問題なくね？
function include_template($_context_, $_filename_) {
extract($_context_);
include($_filename_);
}
$context = array('str'=>'foo', 'int'=>123);
include_template($context, 'template.php');
>Smarty の場合でいうと，デフォルト変数修飾子で出力値の自由な加工をする枠組みを用意してある，とかー
有益な使い道を詳しく。何に使うのか思いつかん。
>> Smartyでできることは、同じようにPHPでもできる。
>Smarty は PHP で書かれてるんだから，そりゃできなきゃ困るｗ
SmartyでできることはPHPでもできる。だからわざわざSmartyを使う理由は何？ってことだろ。
SmartyはPHPで書かれているうんぬんは回答になってない。
つか、SmartyでできることはPHPでもできるけど、PHPでできることがすべてSmartyでできるわけでもないのか。
>フレームワークってそういうものでしょ．
今はテンプレートエンジンの話。
>echo まわりだけとはいえテンプレートの機能使用のほとんどはそこなんだから
えー、それは違うだろ。foreachやifやincludeだって多用しないか？
>生PHPではちょっといじるだけですぐにPHPエラーとか吐くようになってしまうから，
>それをいじる非プログラマから見て心理的抵抗感が大きい……とかー
よくわかんね。Smartyのエラー表示は優れているのか？
>Smarty はテンプレートの変更で致命的エラーを起こせるので個人的にはちょっとイマイチ．
じゃあなにがいいのだ？ついでにその致命的エラーを詳しく。
>生PHPでは出力する変数をグローバルに置いたりするので名前空間汚染が嫌，とかー
生PHPでも、include()とextract()を使えば問題なくね？
function include_template($_context_, $_filename_) {
extract($_context_);
include($_filename_);
}
$context = array('str'=>'foo', 'int'=>123);
include_template($context, 'template.php');
>Smarty の場合でいうと，デフォルト変数修飾子で出力値の自由な加工をする枠組みを用意してある，とかー
有益な使い道を詳しく。何に使うのか思いつかん。
>> Smartyでできることは、同じようにPHPでもできる。
>Smarty は PHP で書かれてるんだから，そりゃできなきゃ困るｗ
SmartyでできることはPHPでもできる。だからわざわざSmartyを使う理由は何？ってことだろ。
SmartyはPHPで書かれているうんぬんは回答になってない。
つか、SmartyでできることはPHPでもできるけど、PHPでできることがすべてSmartyでできるわけでもないのか。
>フレームワークってそういうものでしょ．
今はテンプレートエンジンの話。
メリットがわからないなら、使わなきゃ良いだけだろ。
何をうだうだ言ってるんだか…
何をうだうだ言ってるんだか…
どっちでもいい派だから各々好きにすりゃいいと思うんだが、
肯定派の頭ごなしの「これだから嫌Smarty派は…」的なレスは正直どうかと思うが…
否定派の方が"まだ"論理的だわな。
肯定派の頭ごなしの「これだから嫌Smarty派は…」的なレスは正直どうかと思うが…
否定派の方が"まだ"論理的だわな。
話自体は面白いんだけど、フレームワークとはあまり関係ないよね。
テンプレートのスレで続けたら？
テンプレートのスレで続けたら？
>>861
好きにすればいいものを否定派がムキになって否定して回ってるように見えるが
ところでフレームワークって言葉はこのスレではWeb構築フレームワーク以外には使わない方針なの？
テンプレートエンジンやらDAOやらも広義のフレームワークだと思うが
好きにすればいいものを否定派がムキになって否定して回ってるように見えるが
ところでフレームワークって言葉はこのスレではWeb構築フレームワーク以外には使わない方針なの？
テンプレートエンジンやらDAOやらも広義のフレームワークだと思うが
>>862に言われるまでSmartyスレ読んでるのかと思ってた・・・。
俺もどっちでもいい派だけど、ただSmartyって言うほど覚える事ある？
余計な機能使いすぎじゃないの？柔軟性なんてそんなに無くていいんだけど。
Viewでいろんな事させ過ぎちゃいかんよ。あくまで分離が目的なのだから。
だからPHPで出来ることがSmartyで出来ない事があるのは当たり前だと思ってるけど。
{php}ってあるけど、あれは使ったらいけない、裏技的なものだと思ってるし。
また、「h()のように定義してしまえば」って言うが、なにかWebアプリ作成するたびに、
何か表示させるたびに定義するの？使い回せばよい？じゃあそれを他人に勧められる？
それはメンテしたり引き継いだりする人がかわいそうかなって思うな。
保守性があがると（速度面での）パフォーマンスが落ちるってのはしょうがない。
Symfonyなどのように「最初から色々用意されている」なら、慣れた方で良いと思うよ。
俺もどっちでもいい派だけど、ただSmartyって言うほど覚える事ある？
余計な機能使いすぎじゃないの？柔軟性なんてそんなに無くていいんだけど。
Viewでいろんな事させ過ぎちゃいかんよ。あくまで分離が目的なのだから。
だからPHPで出来ることがSmartyで出来ない事があるのは当たり前だと思ってるけど。
{php}ってあるけど、あれは使ったらいけない、裏技的なものだと思ってるし。
また、「h()のように定義してしまえば」って言うが、なにかWebアプリ作成するたびに、
何か表示させるたびに定義するの？使い回せばよい？じゃあそれを他人に勧められる？
それはメンテしたり引き継いだりする人がかわいそうかなって思うな。
保守性があがると（速度面での）パフォーマンスが落ちるってのはしょうがない。
Symfonyなどのように「最初から色々用意されている」なら、慣れた方で良いと思うよ。
>>863
だな
テンプレートを使う必要があって、性能的に仕様を満たしていれば
採用実績が多く情報も豊富なsmartyが選択肢に入ってもおかしくない
遅くて仕様を満たせなければ使わなければいいだけの話でしょ
フレームワークにしてもテンプレートエンジンにしても
採用実績が多い事自体が採用基準になるのは良くある事
潜在的なバグ出しがされていて情報も多いと判断できるから
なんでむきになって否定派が否定するのかがわからん
だな
テンプレートを使う必要があって、性能的に仕様を満たしていれば
採用実績が多く情報も豊富なsmartyが選択肢に入ってもおかしくない
遅くて仕様を満たせなければ使わなければいいだけの話でしょ
フレームワークにしてもテンプレートエンジンにしても
採用実績が多い事自体が採用基準になるのは良くある事
潜在的なバグ出しがされていて情報も多いと判断できるから
なんでむきになって否定派が否定するのかがわからん
Smartyは結局最終的にはPHPに変換されるんだから
最初っからPHPでかけばいいじゃない。
馬鹿かお前ら？一度ならずニ度三度死ね。
最初っからPHPでかけばいいじゃない。
馬鹿かお前ら？一度ならずニ度三度死ね。
>>866
う～ん、脳みそあるのかなこの人は…
う～ん、脳みそあるのかなこの人は…
どうもsmartyを否定してるやつら（一人？）はsmartyの難点を踏み台にして「PHPテンプレートでいいじゃん」という結論を共有したかったのではないかとｴｽﾊﾟｰ。
俺も一人でささっと作るときはPHPテンプレート使うし、PHPをそのまま使えることは利点だと考えてる。
一つのファイルで済ませるくらいのときもテンプレート部分は下部にまとめてロジックに一切依存させないようにしたりとか。
でもSmarty普通に良いよ。
Smartyオブジェクトの構築とキャッシュチェックくらいしか実質上オーバーヘッドないんだし。
>>864の
> Viewでいろんな事させ過ぎちゃいかんよ。あくまで分離が目的なのだから。
に禿同。触れようと思ってたけど先に書かれてしまった。
>>866の
> 採用実績が多く情報も豊富なsmartyが選択肢に入ってもおかしくない
これも禿同。
それに記述の簡潔さ、View周りの機能（フィルタやカスタム修正子/プラグイン）もそろってるなら、Smarty使う理由としては特に文句のつけどころないと思うけど。
あと、エスケープの話が出てたけど、Smartyのラッパクラス作ってassignメソッドをオーバーライドすれば、テンプレートに渡される全ての変数に自動的にhtmlspecialcharsを通すようにもできるよ。
俺も一人でささっと作るときはPHPテンプレート使うし、PHPをそのまま使えることは利点だと考えてる。
一つのファイルで済ませるくらいのときもテンプレート部分は下部にまとめてロジックに一切依存させないようにしたりとか。
でもSmarty普通に良いよ。
Smartyオブジェクトの構築とキャッシュチェックくらいしか実質上オーバーヘッドないんだし。
>>864の
> Viewでいろんな事させ過ぎちゃいかんよ。あくまで分離が目的なのだから。
に禿同。触れようと思ってたけど先に書かれてしまった。
>>866の
> 採用実績が多く情報も豊富なsmartyが選択肢に入ってもおかしくない
これも禿同。
それに記述の簡潔さ、View周りの機能（フィルタやカスタム修正子/プラグイン）もそろってるなら、Smarty使う理由としては特に文句のつけどころないと思うけど。
あと、エスケープの話が出てたけど、Smartyのラッパクラス作ってassignメソッドをオーバーライドすれば、テンプレートに渡される全ての変数に自動的にhtmlspecialcharsを通すようにもできるよ。
肯定してる馬鹿どもは思考停止してるだけだろ。
なんとなく賛成派の方が多そうだから賛成しとくみたいな。
このまま「各々が・・・」と逃げられたら、否定派の理論も書くだけ無駄。
論理的に反証してくれないとどうにもならん。
なんとなく賛成派の方が多そうだから賛成しとくみたいな。
このまま「各々が・・・」と逃げられたら、否定派の理論も書くだけ無駄。
論理的に反証してくれないとどうにもならん。
そろそろフレームワークの話に戻そうよ。
この話題は結局結論が出ないし、面白くない。
この話題は結局結論が出ないし、面白くない。
873 ：nobodyさん：2006/04/18(火) 10:44:14 ID:NsVFQKmo
FlickrではSmarty使ってるようですね。
http://phpspot.org/blog/archives/2005/09/flickr.html
http://phpspot.org/blog/archives/2005/09/flickr.html
smartyはPHPのコアに入れるか、バイナリのモジュールにしない限り、
PHPの組み込み関数に比べて大幅に速度低下するのは避けられない。
比べる方がアンフェアといってもいいくらい。
PHPの組み込み関数に比べて大幅に速度低下するのは避けられない。
比べる方がアンフェアといってもいいくらい。
ZFのサイトが変わった。
くるのか？
くるのか？
かっちょいいロゴマークになってるね。
smartyはtemplateとｷｬｯｼｭが簡単に利用できるのが利点だと思ってたよ
静的ｷｬｯｼｭと動的ｷｬｯｼｭができるフレームワークってあるの？
静的ｷｬｯｼｭと動的ｷｬｯｼｭができるフレームワークってあるの？
そうそう。キャッシュが使えるのは大きなメリット。
smarty擁護派はなんでこのメリットを主張しないのか不思議。
もっとも自前でキャッシングの実装しても大して手間じゃないけど。
smarty擁護派はなんでこのメリットを主張しないのか不思議。
もっとも自前でキャッシングの実装しても大して手間じゃないけど。
そうだね。
Pear DBとかsmartyは、どういうものか把握せずに使ってる人が多そうだな。
DBエンジンが変わっても、DBクラスをそのまま使えるのがメリット、みたいな説明あるけど、
DBエンジン変えたら、SQLやアルゴリズムの全面見直しは必須だつーの。
DBエンジンが変わっても、DBクラスをそのまま使えるのがメリット、みたいな説明あるけど、
DBエンジン変えたら、SQLやアルゴリズムの全面見直しは必須だつーの。
だっちゅーの♥
>>864
>また、「h()のように定義してしまえば」って言うが、なにかWebアプリ作成するたびに、
>何か表示させるたびに定義するの？使い回せばよい？じゃあそれを他人に勧められる？
>それはメンテしたり引き継いだりする人がかわいそうかなって思うな。
PHPには標準ですでにnl2br()とか便利な関数があるのに、わざわざプラグイン覚えなきゃいけないほうがかわいそう。
Smarty使っているけど、PHPとSmartyの両方をマスタした要員を確保しなきゃメンテできないので失敗したと思ってる。
>保守性があがると（速度面での）パフォーマンスが落ちるってのはしょうがない。
生PHPなら保守性もパフォーマンスも落とさずに済む。保守性をあげるために必ずしもパフォーマンスを落とす必要はない。両立させることは可能。
でもSmartyってそんなにパフォーマンスわるいのか？内部でPHPファイルにコンパイルしてキャッシュするからそんなに遅くないと思うんだが。
体感的には、Smartyによる速度低下は感じない。それよりDBまわりのほうが体感速度に直に効いてくる。
>また、「h()のように定義してしまえば」って言うが、なにかWebアプリ作成するたびに、
>何か表示させるたびに定義するの？使い回せばよい？じゃあそれを他人に勧められる？
>それはメンテしたり引き継いだりする人がかわいそうかなって思うな。
PHPには標準ですでにnl2br()とか便利な関数があるのに、わざわざプラグイン覚えなきゃいけないほうがかわいそう。
Smarty使っているけど、PHPとSmartyの両方をマスタした要員を確保しなきゃメンテできないので失敗したと思ってる。
>保守性があがると（速度面での）パフォーマンスが落ちるってのはしょうがない。
生PHPなら保守性もパフォーマンスも落とさずに済む。保守性をあげるために必ずしもパフォーマンスを落とす必要はない。両立させることは可能。
でもSmartyってそんなにパフォーマンスわるいのか？内部でPHPファイルにコンパイルしてキャッシュするからそんなに遅くないと思うんだが。
体感的には、Smartyによる速度低下は感じない。それよりDBまわりのほうが体感速度に直に効いてくる。
>>866
>テンプレートを使う必要があって、性能的に仕様を満たしていれば
>採用実績が多く情報も豊富なsmartyが選択肢に入ってもおかしくない
今はその「テンプレートエンジンを使う必要があるのか」という話だろ。「どのテンプレートエンジンを使うか」という話じゃない。
採用実績でいうなら、Smartyより生PHPのほうが実績も情報も上。
>遅くて仕様を満たせなければ使わなければいいだけの話でしょ
だから、Smarty使ってる人になぜ使ってるのか聞いてるんでしょ
「使わなくていい」と開き直るまえに明確な利点をちゃんと説明してやれ
>なんでむきになって否定派が否定するのかがわからん
べつに肯定派も否定派もむきになってないだろ。イタイやつはいるけど。
正当な理由が示せないからってそんな話にもっていくなよ。
>テンプレートを使う必要があって、性能的に仕様を満たしていれば
>採用実績が多く情報も豊富なsmartyが選択肢に入ってもおかしくない
今はその「テンプレートエンジンを使う必要があるのか」という話だろ。「どのテンプレートエンジンを使うか」という話じゃない。
採用実績でいうなら、Smartyより生PHPのほうが実績も情報も上。
>遅くて仕様を満たせなければ使わなければいいだけの話でしょ
だから、Smarty使ってる人になぜ使ってるのか聞いてるんでしょ
「使わなくていい」と開き直るまえに明確な利点をちゃんと説明してやれ
>なんでむきになって否定派が否定するのかがわからん
べつに肯定派も否定派もむきになってないだろ。イタイやつはいるけど。
正当な理由が示せないからってそんな話にもっていくなよ。
>>884
Smartyの覚えることってめちゃくちゃ少ないじゃん。
テンプレート側でかわいそうなほど覚えることがあったってことは、PHPからテンプレートに渡すデータが複雑すぎたんじゃないか？
極端な話がSmarty側は変数の出力、if、foreach（or section）と、修正子を２、３個覚える（覚えさせる）だけで十分効力を発揮するよ。
テンプレートにはほとんどHTMLしか書いてないのが理想だし、それなりに実現可能だと思う。
SmartyにPHPと同等のロジックを無理やりやらせたようなテンプレートだったら、そりゃメンテもキレるわな。
>>885
「Smartyを使う理由」自体はいくつも挙げられてきたじゃん。
それで魅力を感じなければ使わなければいいって話。
みんながみんなおまいと同じ立場、視点、論点から話してるわけでもないしな。
まあとりあえずもちつけや。
Smartyの覚えることってめちゃくちゃ少ないじゃん。
テンプレート側でかわいそうなほど覚えることがあったってことは、PHPからテンプレートに渡すデータが複雑すぎたんじゃないか？
極端な話がSmarty側は変数の出力、if、foreach（or section）と、修正子を２、３個覚える（覚えさせる）だけで十分効力を発揮するよ。
テンプレートにはほとんどHTMLしか書いてないのが理想だし、それなりに実現可能だと思う。
SmartyにPHPと同等のロジックを無理やりやらせたようなテンプレートだったら、そりゃメンテもキレるわな。
>>885
「Smartyを使う理由」自体はいくつも挙げられてきたじゃん。
それで魅力を感じなければ使わなければいいって話。
みんながみんなおまいと同じ立場、視点、論点から話してるわけでもないしな。
まあとりあえずもちつけや。
>>869
>Smartyオブジェクトの構築とキャッシュチェックくらいしか実質上オーバーヘッドないんだし。
そうだよな。Smartyが遅いと問題になったことは、自分のところでは今までない。
>>>864の
>> Viewでいろんな事させ過ぎちゃいかんよ。あくまで分離が目的なのだから。
>に禿同。触れようと思ってたけど先に書かれてしまった。
生PHPよりSmartyのほうがうまく分離できることを示せばいいんじゃないか。
３秒考えたけど思いつかんかった。
>それに記述の簡潔さ、
それはechoまわりだけじゃないかという指摘があったんだが。それ以外でも簡潔だと思うか？
echoまわりだけでも見やすくなるのはたしかにうれしいんだが（おれも最初はそれが理由で使ってみた）、
そのわりには労力が多いし欠点も見えてきたから、労力に見合うほどじゃなかったと反省している。
>View周りの機能（フィルタやカスタム修正子/プラグイン）もそろってる
これはPHPの関数で済むな。
Smartyのmodifierが、PHPの関数より便利だということを示せば、Smartyを使う理由になるんじゃないか。
２秒考えたけど思いつかんかった。
>あと、エスケープの話が出てたけど、Smartyのラッパクラス作ってassignメソッドをオーバーライドすれば、テンプレートに渡される全ての変数に自動的にhtmlspecialcharsを通すようにもできるよ。
デフォルトでhtmlspecialcharsを通して、ある箇所だけ通さない（エスケープしない）ということはできる？高木ひろみつ氏のブログで書かれてたような、セキュリティ重視の仕様。
そういう仕様なら、Smartyを使（r
１秒考え（r
>Smartyオブジェクトの構築とキャッシュチェックくらいしか実質上オーバーヘッドないんだし。
そうだよな。Smartyが遅いと問題になったことは、自分のところでは今までない。
>>>864の
>> Viewでいろんな事させ過ぎちゃいかんよ。あくまで分離が目的なのだから。
>に禿同。触れようと思ってたけど先に書かれてしまった。
生PHPよりSmartyのほうがうまく分離できることを示せばいいんじゃないか。
３秒考えたけど思いつかんかった。
>それに記述の簡潔さ、
それはechoまわりだけじゃないかという指摘があったんだが。それ以外でも簡潔だと思うか？
echoまわりだけでも見やすくなるのはたしかにうれしいんだが（おれも最初はそれが理由で使ってみた）、
そのわりには労力が多いし欠点も見えてきたから、労力に見合うほどじゃなかったと反省している。
>View周りの機能（フィルタやカスタム修正子/プラグイン）もそろってる
これはPHPの関数で済むな。
Smartyのmodifierが、PHPの関数より便利だということを示せば、Smartyを使う理由になるんじゃないか。
２秒考えたけど思いつかんかった。
>あと、エスケープの話が出てたけど、Smartyのラッパクラス作ってassignメソッドをオーバーライドすれば、テンプレートに渡される全ての変数に自動的にhtmlspecialcharsを通すようにもできるよ。
デフォルトでhtmlspecialcharsを通して、ある箇所だけ通さない（エスケープしない）ということはできる？高木ひろみつ氏のブログで書かれてたような、セキュリティ重視の仕様。
そういう仕様なら、Smartyを使（r
１秒考え（r
>>889
> 生PHPよりSmartyのほうがうまく分離できることを示せばいいんじゃないか。
デフォルトでテンプレートファイルはテンプレートにしか使えないようになってるじゃん。
生PHPでもポリシーを策定すれば分離できるね。
> それはechoまわりだけじゃないかという指摘があったんだが。それ以外でも簡潔だと思うか？
いや、基本的にechoまわりだけだよ。
> これはPHPの関数で済むな。
そうだね。
> Smartyのmodifierが、PHPの関数より便利だということを示せば、Smartyを使う理由になるんじゃないか。
記述が短い。あとは好みの問題
> デフォルトでhtmlspecialcharsを通して、ある箇所だけ通さない（エスケープしない）ということはできる？高木ひろみつ氏のブログで書かれてたような、セキュリティ重視の仕様。
よくわからんけど、
class FooSmarty extends Smarty {
function assign($name, $value) {
/* ここに好きなように書いてくれ */
parent::assign($name, $value);
}
}
以上のような理由から俺はSmarty使ってる。
もちろん主観的、個人的な趣向もなくはないけど。
俺だってSmartyが全Webアプリで使うべきであるほど完璧な出来だとは考えてないから、嫌いな人がいるのも普通にうなずけるよ。
このスレ読んでてもよくわかるな。
反対派の人は「使いたい人がいてもおかしくはない」とすら考えられないほど熱烈に反対してるの？
> 生PHPよりSmartyのほうがうまく分離できることを示せばいいんじゃないか。
デフォルトでテンプレートファイルはテンプレートにしか使えないようになってるじゃん。
生PHPでもポリシーを策定すれば分離できるね。
> それはechoまわりだけじゃないかという指摘があったんだが。それ以外でも簡潔だと思うか？
いや、基本的にechoまわりだけだよ。
> これはPHPの関数で済むな。
そうだね。
> Smartyのmodifierが、PHPの関数より便利だということを示せば、Smartyを使う理由になるんじゃないか。
記述が短い。あとは好みの問題
> デフォルトでhtmlspecialcharsを通して、ある箇所だけ通さない（エスケープしない）ということはできる？高木ひろみつ氏のブログで書かれてたような、セキュリティ重視の仕様。
よくわからんけど、
class FooSmarty extends Smarty {
function assign($name, $value) {
/* ここに好きなように書いてくれ */
parent::assign($name, $value);
}
}
以上のような理由から俺はSmarty使ってる。
もちろん主観的、個人的な趣向もなくはないけど。
俺だってSmartyが全Webアプリで使うべきであるほど完璧な出来だとは考えてないから、嫌いな人がいるのも普通にうなずけるよ。
このスレ読んでてもよくわかるな。
反対派の人は「使いたい人がいてもおかしくはない」とすら考えられないほど熱烈に反対してるの？
>>879
キャッシュ機能が目的でSmartyを使っているやつってどのくらいの割合でいるの？
おれんところでは、Smartyが遅くて問題になったことはないから、出力キャッシュを使ったことはない。
そういうやつのほうが多いんじゃない？もしそうなら、出力キャッシュ機能以外が目的でSmartyを使ってるんだから、その理由を知りたい。
>>880
共有サーバじゃなくて、自前でサーバを用意しているなら、アプリケーションサーバレベルでのキャッシュがいちばん楽だよ。
あるURLにマッチしたら、サーバがキャッシュを返す。PHPすら呼び出さないから高速だし、バックエンドの言語に依存しない（Javaでも使える）。
ただし、ポートレットのようにひとつのページに複数のキャッシュを持たせる必要がある場合は使えないけどね。
キャッシュ機能が目的でSmartyを使っているやつってどのくらいの割合でいるの？
おれんところでは、Smartyが遅くて問題になったことはないから、出力キャッシュを使ったことはない。
そういうやつのほうが多いんじゃない？もしそうなら、出力キャッシュ機能以外が目的でSmartyを使ってるんだから、その理由を知りたい。
>>880
共有サーバじゃなくて、自前でサーバを用意しているなら、アプリケーションサーバレベルでのキャッシュがいちばん楽だよ。
あるURLにマッチしたら、サーバがキャッシュを返す。PHPすら呼び出さないから高速だし、バックエンドの言語に依存しない（Javaでも使える）。
ただし、ポートレットのようにひとつのページに複数のキャッシュを持たせる必要がある場合は使えないけどね。
>>886
Smartyの覚えることが多い少ないじゃなくて、そもそもSmartyのようなテンプレートエンジンが必要なのかどうかってこと。
生PHPと比べてSmartyの強い利点がなければSmartyを使う必要がない。じゃあSmartyを使う利点とは何か、あるいは利点といわれているものが本当に利点なのかを議論してるんじゃないか。
どうしても覚える量にこだわるなら、生PHPなら覚えることすら必要ない。
>テンプレート側でかわいそうなほど覚えることがあったってことは、PHPからテンプレートに渡すデータが複雑すぎたんじゃないか？
>極端な話がSmarty側は変数の出力、if、foreach（or section）と、修正子を２、３個覚える（覚えさせる）だけで十分効力を発揮するよ。
>テンプレートにはほとんどHTMLしか書いてないのが理想だし、それなりに実現可能だと思う。
それは生PHPでも同じこと。if, foreach と関数を２、３個覚えるだけで十分効力を発揮する。わざわざSmartyを使う理由にはならん。
>SmartyにPHPと同等のロジックを無理やりやらせたようなテンプレートだったら、そりゃメンテもキレるわな。
だれがキレたのかしらんが、うちのメンテがキレるとしたら、生PHPでもおんなじことがおんなじようにできるのに、
わざわざテンプレートエンジンを導入してしまったおれに対してだなorz
正直すまんかった
>「Smartyを使う理由」自体はいくつも挙げられてきたじゃん。
それがほんとうに意味のある理由かどうかを議論しているんだが。
>それで魅力を感じなければ使わなければいいって話。
なんか勘違いされてるっぽいんだが、おれはSmartyを使ってるやつを非難してないよ。
今までSmartyタイプのテンプレートエンジンを使う利点とされてきたのが、ほんとうに意味のある理由なのかどうか、
生PHPと比べてほんとうに魅力があるのかを議論して検証したいだけ。
今まで挙げられた理由のなかで、いちおう理由として成り立ちそうなのが
・echoまわりが簡潔になる
・キャッシュ機能がある
ぐらいか。あとの理由はあんまり理由にならんな。これがtapestryやmayaaだと明確な理由があるんだが。
Smartyの覚えることが多い少ないじゃなくて、そもそもSmartyのようなテンプレートエンジンが必要なのかどうかってこと。
生PHPと比べてSmartyの強い利点がなければSmartyを使う必要がない。じゃあSmartyを使う利点とは何か、あるいは利点といわれているものが本当に利点なのかを議論してるんじゃないか。
どうしても覚える量にこだわるなら、生PHPなら覚えることすら必要ない。
>テンプレート側でかわいそうなほど覚えることがあったってことは、PHPからテンプレートに渡すデータが複雑すぎたんじゃないか？
>極端な話がSmarty側は変数の出力、if、foreach（or section）と、修正子を２、３個覚える（覚えさせる）だけで十分効力を発揮するよ。
>テンプレートにはほとんどHTMLしか書いてないのが理想だし、それなりに実現可能だと思う。
それは生PHPでも同じこと。if, foreach と関数を２、３個覚えるだけで十分効力を発揮する。わざわざSmartyを使う理由にはならん。
>SmartyにPHPと同等のロジックを無理やりやらせたようなテンプレートだったら、そりゃメンテもキレるわな。
だれがキレたのかしらんが、うちのメンテがキレるとしたら、生PHPでもおんなじことがおんなじようにできるのに、
わざわざテンプレートエンジンを導入してしまったおれに対してだなorz
正直すまんかった
>「Smartyを使う理由」自体はいくつも挙げられてきたじゃん。
それがほんとうに意味のある理由かどうかを議論しているんだが。
>それで魅力を感じなければ使わなければいいって話。
なんか勘違いされてるっぽいんだが、おれはSmartyを使ってるやつを非難してないよ。
今までSmartyタイプのテンプレートエンジンを使う利点とされてきたのが、ほんとうに意味のある理由なのかどうか、
生PHPと比べてほんとうに魅力があるのかを議論して検証したいだけ。
今まで挙げられた理由のなかで、いちおう理由として成り立ちそうなのが
・echoまわりが簡潔になる
・キャッシュ機能がある
ぐらいか。あとの理由はあんまり理由にならんな。これがtapestryやmayaaだと明確な理由があるんだが。
892の言ってることは的確だな。
「本当に」魅力があるのかと問われてる以上、肯定派の言うことはどれも弱い。
それでいいんじゃないか？
最初からたぶん誰も熱くはなっていないし双方落ち着いてるとは思うが、
話すんのめんどくさくなっちゃった人はかなりいるだろうから。
「本当に」魅力があるのかと問われてる以上、肯定派の言うことはどれも弱い。
それでいいんじゃないか？
最初からたぶん誰も熱くはなっていないし双方落ち着いてるとは思うが、
話すんのめんどくさくなっちゃった人はかなりいるだろうから。
Smarty使うと不便なことの方が多いと感じたよ。
そのままではShift_JISで使えなかったり、
ちょっと特殊なことをしようとすると、いろいろ調べる必要があったり、
調べた結果できないとわかったり、できそうでできないことがあったり。
結局、生PHPに戻りました。
そのままではShift_JISで使えなかったり、
ちょっと特殊なことをしようとすると、いろいろ調べる必要があったり、
調べた結果できないとわかったり、できそうでできないことがあったり。
結局、生PHPに戻りました。
>>890
>デフォルトでテンプレートファイルはテンプレートにしか使えないようになってるじゃん。
>生PHPでもポリシーを策定すれば分離できるね。
ポリシーは簡単に破られるから、その点でいうと生PHPよりSmartyのほうが分離を強制できるということか。
>いや、基本的にechoまわりだけだよ。
残念
>> これはPHPの関数で済むな。
>そうだね。
残念
>記述が短い。あとは好みの問題
残
>よくわからんけど、
>class FooSmarty extends Smarty {
> function assign($name, $value) {
> /* ここに好きなように書いてくれ */
> parent::assign($name, $value);
> }
>}
この方法では、「ある箇所だけエスケープしない」というのが実現できないな。
テンプレートに書かれた情報をもってこれないから。なんかいいアイデアあるといいけど。
>反対派の人は「使いたい人がいてもおかしくはない」とすら考えられないほど熱烈に反対してるの？
別にそんなやつはいないんじゃない？ちょっと否定意見がでただけで「使いたくなければ使うな」とほざいて議論を逃げようとするやつはいるけど。
おれはSmarty使って失敗したと思ってるから、他に使ってるやつがどんな理由で使っているか知りたいだけ。
今のままだと次の仕事では生PHPを使おうと思ってるけど、おれの知らない利点がSmartyにあればあれば考えを改めて次もSmartyを使う。
つか、生PHPで済むならアダプタ作んなくてすむから俺フレームワークが簡潔になってｳﾏｰと思ってるのは内緒
>デフォルトでテンプレートファイルはテンプレートにしか使えないようになってるじゃん。
>生PHPでもポリシーを策定すれば分離できるね。
ポリシーは簡単に破られるから、その点でいうと生PHPよりSmartyのほうが分離を強制できるということか。
>いや、基本的にechoまわりだけだよ。
残念
>> これはPHPの関数で済むな。
>そうだね。
残念
>記述が短い。あとは好みの問題
残
>よくわからんけど、
>class FooSmarty extends Smarty {
> function assign($name, $value) {
> /* ここに好きなように書いてくれ */
> parent::assign($name, $value);
> }
>}
この方法では、「ある箇所だけエスケープしない」というのが実現できないな。
テンプレートに書かれた情報をもってこれないから。なんかいいアイデアあるといいけど。
>反対派の人は「使いたい人がいてもおかしくはない」とすら考えられないほど熱烈に反対してるの？
別にそんなやつはいないんじゃない？ちょっと否定意見がでただけで「使いたくなければ使うな」とほざいて議論を逃げようとするやつはいるけど。
おれはSmarty使って失敗したと思ってるから、他に使ってるやつがどんな理由で使っているか知りたいだけ。
今のままだと次の仕事では生PHPを使おうと思ってるけど、おれの知らない利点がSmartyにあればあれば考えを改めて次もSmartyを使う。
つか、生PHPで済むならアダプタ作んなくてすむから俺フレームワークが簡潔になってｳﾏｰと思ってるのは内緒
896 ：nobodyさん：2006/04/18(火) 16:38:57 ID:PuLKXxqh
確かにそろそろsmarty外してもいい気がしてきはするが、
逆にADODBみたいにダイナミックリンクやスタティックリンク可能な標準的テンプレートモジュールが出てもいいかなとも思う。
逆にADODBみたいにダイナミックリンクやスタティックリンク可能な標準的テンプレートモジュールが出てもいいかなとも思う。
>>859 で書いた extract()とinclude()のコンビって、どっかのblogかなんかで紹介されてて読んだ覚えがあるんだが、みつからんかった。
誰か知らない？それ読んでから生PHP派に転向したんだが。
それから、Smartyのエラー表示ってどんなんだったっけ？生PHPより分かりやすければ、Smartyを使う利点といえるはず。
でも今手元にテスト環境がないんで確かめられない。
Railsのエラー表示をみて驚いた覚えがあるから、Smartyのエラー表示がすごかった覚えはないんだよな。
誰か知らない？それ読んでから生PHP派に転向したんだが。
それから、Smartyのエラー表示ってどんなんだったっけ？生PHPより分かりやすければ、Smartyを使う利点といえるはず。
でも今手元にテスト環境がないんで確かめられない。
Railsのエラー表示をみて驚いた覚えがあるから、Smartyのエラー表示がすごかった覚えはないんだよな。
最近フレームワークに興味が出てきただけなんで、なぜこんな流れになったんか分からんが
とりあえず、smartyが気に入らないのは同意。
気に入らないから、自分でテンプレートエンジン作ってみたんだけどな、
途中で、flexy見たりして、要素でアクセスできるといいな・・・とか思って作ってみたら、
途中でテンプレートの文法に矛盾みたいな部分が出たりしてきたので断念した。
結局、出来合いのものを使うのが一番楽かな？とsmartyだな。
まぁ、結局ん所さ、smarty使うにせよ使わないにせよ、あるものを使いこなせるんならそれでいいんじゃね？
（って、この間、PHP5でDOM関数がサポートされてるのを初めて知ったんだが、
DOM APIでXHTMLをテンプレートみたいに使ってみている人居ない？
遅すぎて使い物にならんかな？）
とりあえず、smartyが気に入らないのは同意。
気に入らないから、自分でテンプレートエンジン作ってみたんだけどな、
途中で、flexy見たりして、要素でアクセスできるといいな・・・とか思って作ってみたら、
途中でテンプレートの文法に矛盾みたいな部分が出たりしてきたので断念した。
結局、出来合いのものを使うのが一番楽かな？とsmartyだな。
まぁ、結局ん所さ、smarty使うにせよ使わないにせよ、あるものを使いこなせるんならそれでいいんじゃね？
（って、この間、PHP5でDOM関数がサポートされてるのを初めて知ったんだが、
DOM APIでXHTMLをテンプレートみたいに使ってみている人居ない？
遅すぎて使い物にならんかな？）
それこそ遅くなりそうだけど、興味はあるね
>>897
> それから、Smartyのエラー表示ってどんなんだったっけ？
うちでちょっと出してみた所、
{hoge}
で
Smarty error: [in テンプレート名 line 1]: syntax error: unrecognized tag 'hoge'
ってな感じ。
特に分かりやすいってもんでも無いと思うけど・・・
> それから、Smartyのエラー表示ってどんなんだったっけ？
うちでちょっと出してみた所、
{hoge}
で
Smarty error: [in テンプレート名 line 1]: syntax error: unrecognized tag 'hoge'
ってな感じ。
特に分かりやすいってもんでも無いと思うけど・・・
>>898
概ね同意。
なんか初めは「Smarty不要」を無意味に連発されてる状況だったから、「使いたくないなら使わなくていいよ」って流れになったけど、それを返すように「Smartyは真の意味で必要なのか？」に論旨がずれてきたって印象。
結局は結論は「使いたくないなら使わなくていいよ」にしかならんよ。
smartyそんなめちゃくちゃいいわけじゃないし。
生phpだって悪くはないし。
一長一短じゃん。
俺はsmartyは記述が短いってだけの理由でも十分使う理由になってるし、とやかく言われる筋合いなし。
「使いたいなら使えば」でいいじゃないのよ。
概ね同意。
なんか初めは「Smarty不要」を無意味に連発されてる状況だったから、「使いたくないなら使わなくていいよ」って流れになったけど、それを返すように「Smartyは真の意味で必要なのか？」に論旨がずれてきたって印象。
結局は結論は「使いたくないなら使わなくていいよ」にしかならんよ。
smartyそんなめちゃくちゃいいわけじゃないし。
生phpだって悪くはないし。
一長一短じゃん。
俺はsmartyは記述が短いってだけの理由でも十分使う理由になってるし、とやかく言われる筋合いなし。
「使いたいなら使えば」でいいじゃないのよ。
>>895
> この方法では、「ある箇所だけエスケープしない」というのが実現できないな。
> テンプレートに書かれた情報をもってこれないから。なんかいいアイデアあるといいけど。
prefilterのこと？
> この方法では、「ある箇所だけエスケープしない」というのが実現できないな。
> テンプレートに書かれた情報をもってこれないから。なんかいいアイデアあるといいけど。
prefilterのこと？
>>895
どういう結論を期待してるわけ？
Smarty使って損したなら使わなければいい、以外に言いようがないけど。
まさか再びSmartyを使いたくなるような革命的な理由探しなんかしてないでしょ。
そんなもんないから諦めれ。
俺は記述が簡潔、分離のしやすさ、あとは不満のない程度に拡張もしやすいって理由でSmartyはよく使ってる。
それとも、あなたの書き込みを見てSmarty使うのをやめることにしました。ありがとうございました。って結論じゃなきゃ嫌かい？
「Smartyを使うのをやめる理由」として挙げられたものの方が俺にとっては弱いのでやめる気にはなれない。
どういう結論を期待してるわけ？
Smarty使って損したなら使わなければいい、以外に言いようがないけど。
まさか再びSmartyを使いたくなるような革命的な理由探しなんかしてないでしょ。
そんなもんないから諦めれ。
俺は記述が簡潔、分離のしやすさ、あとは不満のない程度に拡張もしやすいって理由でSmartyはよく使ってる。
それとも、あなたの書き込みを見てSmarty使うのをやめることにしました。ありがとうございました。って結論じゃなきゃ嫌かい？
「Smartyを使うのをやめる理由」として挙げられたものの方が俺にとっては弱いのでやめる気にはなれない。
おそらく、
生PHP？テンプレートエンジンも使ってないの？
というテンプレートエンジン優勢の風潮があったのに対して、
いや生PHPでいいでしょ？むしろこっちの方が使いやすいよ。
というゆり戻しが起きているのが今なのでは。
生PHP？テンプレートエンジンも使ってないの？
というテンプレートエンジン優勢の風潮があったのに対して、
いや生PHPでいいでしょ？むしろこっちの方が使いやすいよ。
というゆり戻しが起きているのが今なのでは。
XOOPSのテンプレートってDWでデザインするプラグインがあったけど
生PHPってDWでくずれずデザインできるの?
生PHPってDWでくずれずデザインできるの?
906 ：nobodyさん：2006/04/18(火) 17:48:02 ID:N+jyBKUQ
railsがプレゼンテーションに埋め込み型ruby使ってるからね。
railsにインスパイアされたフレームワークは軒並みそれを真似てる。
もともとオレは自分が設計に参加した案件ではテンプレートエンジン使ってこなかったけど。
必要ないから。
railsにインスパイアされたフレームワークは軒並みそれを真似てる。
もともとオレは自分が設計に参加した案件ではテンプレートエンジン使ってこなかったけど。
必要ないから。
>>905
ドリでもPHPのコーディングできるから生PHPでも問題ないよ。
WYSIWYGではアイコンで表示されるし。
逆にテンプレートエンジン使うときには崩れるので
少し手を加える必要あり。
http://blog.cles.jp/item/376
フレームワークというより、テンプレートエンジンの話題になってるな…。
ドリでもPHPのコーディングできるから生PHPでも問題ないよ。
WYSIWYGではアイコンで表示されるし。
逆にテンプレートエンジン使うときには崩れるので
少し手を加える必要あり。
http://blog.cles.jp/item/376
フレームワークというより、テンプレートエンジンの話題になってるな…。
>>874
喪前にはがっかりだ。
。。。。。まぁ馬鹿はほっておこう。
否定的な人：特段のメリットが見出せない
肯定的な人：使いたいから使う、イヤなら使うな。
ってのが今の主流派。
で、否定的な人達は今まであがったメリットだけでは利用するに値しないから、
何か他にメリットがあるのか？と聞いている。
要するに自分の意見に対する論理的な反証が欲しいんだよ。
その反証が検討に値するものだったら、このままSmarty使うかもしんないけど、
今まで出てきたメリットしかないっていうなら、たぶんもう使わない。
ただそんだけの話で、誰も「いまどきSmarty使ってる奴ｗｗｗｗｗｗ」
とか言ってるわけじゃない。
喪前にはがっかりだ。
。。。。。まぁ馬鹿はほっておこう。
否定的な人：特段のメリットが見出せない
肯定的な人：使いたいから使う、イヤなら使うな。
ってのが今の主流派。
で、否定的な人達は今まであがったメリットだけでは利用するに値しないから、
何か他にメリットがあるのか？と聞いている。
要するに自分の意見に対する論理的な反証が欲しいんだよ。
その反証が検討に値するものだったら、このままSmarty使うかもしんないけど、
今まで出てきたメリットしかないっていうなら、たぶんもう使わない。
ただそんだけの話で、誰も「いまどきSmarty使ってる奴ｗｗｗｗｗｗ」
とか言ってるわけじゃない。
なんで技術スレで煽り合いになるのかｻｯﾊﾟﾘ分からん
人は人、おのれはおのれだし。
参考になるならパクればいいし
ならないならスルーすればいいし。
人は人、おのれはおのれだし。
参考になるならパクればいいし
ならないならスルーすればいいし。
>>908
じゃメリットを感じる人が、Smartyを使うことのをやめる必要がない、という意見に対する論理的な反証が欲しい場合はどういう反証してくれるの？
結局「好きにしろ」の以外の結論ねーべ。
そこで御託を並べる意味がわからん。
じゃメリットを感じる人が、Smartyを使うことのをやめる必要がない、という意見に対する論理的な反証が欲しい場合はどういう反証してくれるの？
結局「好きにしろ」の以外の結論ねーべ。
そこで御託を並べる意味がわからん。
template toolkitパクればPHPもJSPになれるって考えたんだろうけど、
テンプレートエンジン必須のPerlと埋め込み型のPHPじゃ立ち位置が違いますから。
テンプレートエンジン必須のPerlと埋め込み型のPHPじゃ立ち位置が違いますから。
重いし、覚えるの面倒だし、自由度下がるけど、<?=h($var)?>より{$var|escape}の方が見やすければ、smartyをどうぞ。
記述量が少ないって、ものスゲーメリットだと思うんだけど。
あと、<?=は論外な。
あと、<?=は論外な。
915 ：nobodyさん：2006/04/18(火) 18:57:12 ID:cLSmooAO
静的なHTMLを吐き出す場合でも、そのまま出力する場合でも、
Smartyならあんまコード変更しなくていいから良い
Smartyならあんまコード変更しなくていいから良い
>>914
prototype.jsを張り倒してください
prototype.jsを張り倒してください
なんでショートタグをオフにするのにこだわるのか分からない。
理由は？
理由は？
>>914
いしなおも張り倒してください
いしなおも張り倒してください
>>916
あーあの$系統のセンスキモイね。
あーあの$系統のセンスキモイね。
ああ、ちなみにh()ってERｂの実装だよ。世界中のrailsユーザを張り倒しにケンカ旅行しにいってください。
>>920
いや、rubyはpからして張り倒し対象な前提で始まってるからな。
いや、rubyはpからして張り倒し対象な前提で始まってるからな。
まあ、PHPの場合、何かにつけJavaを意識しすぎて、自分自身を見失った感じがあるね。
railsは真逆の方法論を提示したわけで。rails見てると、いちいちPHPに対する皮肉に思えてくる。
railsは真逆の方法論を提示したわけで。rails見てると、いちいちPHPに対する皮肉に思えてくる。
PHPは http://wiki.fdiary.net/rails/?ErbCheatSheet を完全にぱくって、
デフォルトにしてくれていいと思う。
デフォルトにしてくれていいと思う。
>>917
ttp://php.s3.to/man/language.basic-syntax.html
>>920
h()がｷﾓｲって言ってんじゃなくて、
自分関数をあらゆるシステムで使い回すのがｷﾓｲって言ってるんじゃないの？
言わば枯れてないものを他人に強要出来る自信があるのがすごいな。
何かあってもSmartyやらフレームワークのせいに出来ないしな（笑
ttp://php.s3.to/man/language.basic-syntax.html
>>920
h()がｷﾓｲって言ってんじゃなくて、
自分関数をあらゆるシステムで使い回すのがｷﾓｲって言ってるんじゃないの？
言わば枯れてないものを他人に強要出来る自信があるのがすごいな。
何かあってもSmartyやらフレームワークのせいに出来ないしな（笑
>>923-924
無理だろうね。
無理だろうね。
>>919
Smartyよりはかなりマシじゃね？
Smartyよりはかなりマシじゃね？
ところで<?=が駄目なのは何故？
マニュアルに移植性が低いと書いてあるようだ。
現実的に問題になるのは、HTMLを厳密なXHTMLで書くときに、
<?xml version="1.0" encoding="Shift_JIS"?>
<!doctype xxx>
<html>
みたいにしないといけないってこと。
これを普通にPHPとして実行するとパースエラーが起きる。
しかし、
$str = '<?xml version="1.0" encoding="Shift_JIS"?>';
として、適当な方法で出力すればいいのでは？って話。
なんだったら、sed 's/<?/<?php/g'とやってもいいし。
かなりどうでもいいこと＞ショートタグ使うか使わないか
<?xml version="1.0" encoding="Shift_JIS"?>
<!doctype xxx>
<html>
みたいにしないといけないってこと。
これを普通にPHPとして実行するとパースエラーが起きる。
しかし、
$str = '<?xml version="1.0" encoding="Shift_JIS"?>';
として、適当な方法で出力すればいいのでは？って話。
なんだったら、sed 's/<?/<?php/g'とやってもいいし。
かなりどうでもいいこと＞ショートタグ使うか使わないか
だから <% %> をデフォルトで有効にすればいいのでは
>>930
好きにしたら。
short_open_tagはオフにしている環境ことがわかってるから、マニュアルにも移植性が低いって書いてあるんでしょ。
それでzendも推奨はしていない。
互換性の問題もあるから廃止にもできない宙ぶらりん状態。
好きにしたら。
short_open_tagはオフにしている環境ことがわかってるから、マニュアルにも移植性が低いって書いてあるんでしょ。
それでzendも推奨はしていない。
互換性の問題もあるから廃止にもできない宙ぶらりん状態。
>>931
廃止される予定です。
廃止される予定です。
日本語ヘンだったorz
×環境ことが
○環境が多いことが
×環境ことが
○環境が多いことが
だから、どうでもいいことっていってるジャン。
後になって困っても、sedで置換して終わりだよ。
<?=だけ引っ掛ければ、問題ない。
後になって困っても、sedで置換して終わりだよ。
<?=だけ引っ掛ければ、問題ない。
>>914
おーい、いまをときめくRailsにケンカ売っちゃやばいよ
まぁRuby(eruby)の文法は <%=h @product.name %> みたいに、いちいち括弧を
要求しないからPHPよりはテンプレートにプログラム臭がしなくて比較的いいんだけど。
それにこういう書き方でもヘルパーメソッドだから、なんていうかぱっと見のキモさも少ない。
おーい、いまをときめくRailsにケンカ売っちゃやばいよ
まぁRuby(eruby)の文法は <%=h @product.name %> みたいに、いちいち括弧を
要求しないからPHPよりはテンプレートにプログラム臭がしなくて比較的いいんだけど。
それにこういう書き方でもヘルパーメソッドだから、なんていうかぱっと見のキモさも少ない。
あ、ごめん。名前消し忘れ。
カッコ省略可能になんねーかなw
>>935
だから好きにしたらっていってるジャン。
だから好きにしたらっていってるジャン。
phpをruby風にする妄想をするスレになってまいりました
>>910
喪前にはさらにがっかりだ。
メリットを感じない側は、メリットがないことを証明するのは難しいから、
メリットを感じてる側に反証してくれと言ってたんだよ。
今更取り上げるのも虚しいが、喪前が求めてるのは悪魔の証明と一緒。
ホントにメリットを感じてんだか、ただ暴れたいだけなのか分からん奴よりも、
メリットを感じない人の方が論理的だと言われてた理由がまだ分からんのか？
つーか、もはやいつまでも取り残されてるのは喪前だけなんでこれで終了。
喪前にはさらにがっかりだ。
メリットを感じない側は、メリットがないことを証明するのは難しいから、
メリットを感じてる側に反証してくれと言ってたんだよ。
今更取り上げるのも虚しいが、喪前が求めてるのは悪魔の証明と一緒。
ホントにメリットを感じてんだか、ただ暴れたいだけなのか分からん奴よりも、
メリットを感じない人の方が論理的だと言われてた理由がまだ分からんのか？
つーか、もはやいつまでも取り残されてるのは喪前だけなんでこれで終了。
>>933
なんで廃止にするの？
なんで廃止にするの？
>>942
ちげうよ。使っているものをわざわざ使うのをやめるための理由があるかどうかを論証してごらん。
別にできないならできないでそう言えばいい。
俺だってお前のような頭の固い人間にsmartyを使ってもらえるメリットを論証することなどできない。
お前は自分勝手な論理展開しすぎ。
ちげうよ。使っているものをわざわざ使うのをやめるための理由があるかどうかを論証してごらん。
別にできないならできないでそう言えばいい。
俺だってお前のような頭の固い人間にsmartyを使ってもらえるメリットを論証することなどできない。
お前は自分勝手な論理展開しすぎ。
>>942
＞メリットを感じない側は、メリットがないことを証明するのは難しいから、
何で？悪魔の証明とは全然違うじゃん。smartyのデメリットを挙げて
そのデメリットを持たないsmartyより優れていると思われる他の選択肢を
示せばいいだけじゃん。
結局あんた悪魔の証明と言いたいだけちゃうんか
＞メリットを感じない人の方が論理的だと言われてた
自分で自分を論理的と言っているだけじゃないの？
＞つーか、もはやいつまでも取り残されてるのは喪前だけなんでこれで終了。
逃げるのね、別にいいけど
＞メリットを感じない側は、メリットがないことを証明するのは難しいから、
何で？悪魔の証明とは全然違うじゃん。smartyのデメリットを挙げて
そのデメリットを持たないsmartyより優れていると思われる他の選択肢を
示せばいいだけじゃん。
結局あんた悪魔の証明と言いたいだけちゃうんか
＞メリットを感じない人の方が論理的だと言われてた
自分で自分を論理的と言っているだけじゃないの？
＞つーか、もはやいつまでも取り残されてるのは喪前だけなんでこれで終了。
逃げるのね、別にいいけど
>>942
論理を振りかざすなら誤謬をなくすことから始めようね。
論理を振りかざすなら誤謬をなくすことから始めようね。
おれはどっちかっていったらテンプレート言語から出発して、まだその特徴が
強くのこっているphpにおいて、smartyタイプのテンプレートエンジンを採用する意味は
あんまりないなって思うけど、javaでのxmlcのような奴なら使う価値があるとおもう。
しばらくEnhydraを使っていたんだけど、デザイナーからもらった見本に
ちょいちょいとid属性を振るだけでデザインの変更はおしまい。
あらかじめid属性をつけるように頼むか、既存のものへの小さめの変更なら使用中のものを
ひな形として使うように決めておけばその手間だって必要ない。
文書をDOMツリーとして扱うので、タグマークアップ言語にしか使えないけどね
だれか作らんかしらん。
強くのこっているphpにおいて、smartyタイプのテンプレートエンジンを採用する意味は
あんまりないなって思うけど、javaでのxmlcのような奴なら使う価値があるとおもう。
しばらくEnhydraを使っていたんだけど、デザイナーからもらった見本に
ちょいちょいとid属性を振るだけでデザインの変更はおしまい。
あらかじめid属性をつけるように頼むか、既存のものへの小さめの変更なら使用中のものを
ひな形として使うように決めておけばその手間だって必要ない。
文書をDOMツリーとして扱うので、タグマークアップ言語にしか使えないけどね
だれか作らんかしらん。
> テンプレート言語から出発して、まだその特徴が強くのこっているphp
たしかにphpが出てきたばっかりのころはhtmlにコードを埋め込める感覚は新鮮だったけど（まあSSIとかもあったか）、テンプレートエンジンで書くようになったら、「埋め込んで使うphp」はやや冗長に感じるな。
つーかたぶんsmartyって食わず嫌いの人もけっこういそうな希ガス。
そういえば俺も最初はキモくて使う気がしなかった。
たしかにphpが出てきたばっかりのころはhtmlにコードを埋め込める感覚は新鮮だったけど（まあSSIとかもあったか）、テンプレートエンジンで書くようになったら、「埋め込んで使うphp」はやや冗長に感じるな。
つーかたぶんsmartyって食わず嫌いの人もけっこういそうな希ガス。
そういえば俺も最初はキモくて使う気がしなかった。
ちょうどその食わず嫌いだったんだけど、
この議論（とも言えない部分はあるが）みて、
自分で細かく調べてみて結構使う気になってきたよ
この議論（とも言えない部分はあるが）みて、
自分で細かく調べてみて結構使う気になってきたよ
>>950
そうか？PHPがいまほどはやってなくてまだCGIが全盛だった頃、
USではColdFusionが人気だったぞ。日本ではさっぱり流行らなかったが。
データベースの読み書き程度のアプリならHTMLを書く延長で作れたから、
デザイナーを中心に人気を博した。
複雑なロジックが必要な場合は外部ライブラリに分離し、HTMLからそれを呼び出すから
HTML中に含まれるロジックはそんなに多くない。
そうか？PHPがいまほどはやってなくてまだCGIが全盛だった頃、
USではColdFusionが人気だったぞ。日本ではさっぱり流行らなかったが。
データベースの読み書き程度のアプリならHTMLを書く延長で作れたから、
デザイナーを中心に人気を博した。
複雑なロジックが必要な場合は外部ライブラリに分離し、HTMLからそれを呼び出すから
HTML中に含まれるロジックはそんなに多くない。
そろそろ次スレ立てとこうぜー
テンプレのリンク順番変えない？
とりあえず
・ZF
・Symfony
・Agavi
・Mojavi
・他
の順？他のFW使ったことないからわかんねー。
PHP4/5でわけたりできないかな。
つーか今mojavi.orgに行ってみたら、「ちょっと待っててね」の代わりにこんなエラーに変わってた。
FATAL [/var/www/mojavi.org/opt/user/SessionContainer.class.php:35] Only variable references should be returned by reference
Mojavi4の予感？
とりあえず
・ZF
・Symfony
・Agavi
・Mojavi
・他
の順？他のFW使ったことないからわかんねー。
PHP4/5でわけたりできないかな。
つーか今mojavi.orgに行ってみたら、「ちょっと待っててね」の代わりにこんなエラーに変わってた。
FATAL [/var/www/mojavi.org/opt/user/SessionContainer.class.php:35] Only variable references should be returned by reference
Mojavi4の予感？
【前スレ】http://pc8.2ch.net/test/read.cgi/php/1135847024/
::フレームワーク一覧::
■Zend Framewoek
http://framework.zend.com/
■symfony
http://www.symfony-project.com/
■Agavi
http://agavi.org/
■Mojavi Project
http://www.mojavi.org/
■Phrame
http://phrame.sourceforge.net/
■[ 日本発 ] Maple Project
http://kunit.jp/maple/
■[ 日本発 ] Ethna -PHPウェブアプリケーションフレームワーク-
http://ethna.jp/ethna-tutorial-startup-practice1.html
■[ 日本発 ] guesswork
http://www.guesswork.jp/
■Biscuit
http://bennolan.com/biscuit/
■PHP on TRAX
http://phpontrax.com/
■Web Application Component Toolkit (WACT)
http://www.phpwact.org/
■XOAD
http://wiki.xoad.org/index.php?title=Wiki_Home
■[ 日本発 ] pokox
http://www.glamenv-septzen.net/pukiwiki/index.php?pokox
■[ 日本発 ] 速構Web Framework
http://www.pm9.com/newpm9/itbiz/php/framework/
■CakePHP
ttp://cakephp.org/
::フレームワーク一覧::
■Zend Framewoek
http://framework.zend.com/
■symfony
http://www.symfony-project.com/
■Agavi
http://agavi.org/
■Mojavi Project
http://www.mojavi.org/
■Phrame
http://phrame.sourceforge.net/
■[ 日本発 ] Maple Project
http://kunit.jp/maple/
■[ 日本発 ] Ethna -PHPウェブアプリケーションフレームワーク-
http://ethna.jp/ethna-tutorial-startup-practice1.html
■[ 日本発 ] guesswork
http://www.guesswork.jp/
■Biscuit
http://bennolan.com/biscuit/
■PHP on TRAX
http://phpontrax.com/
■Web Application Component Toolkit (WACT)
http://www.phpwact.org/
■XOAD
http://wiki.xoad.org/index.php?title=Wiki_Home
■[ 日本発 ] pokox
http://www.glamenv-septzen.net/pukiwiki/index.php?pokox
■[ 日本発 ] 速構Web Framework
http://www.pm9.com/newpm9/itbiz/php/framework/
■CakePHP
ttp://cakephp.org/
>>953
＞FATAL [/var/www/mojavi.org/opt/user/SessionContainer.class.php:35] Only variable references should be returned by reference
＞Mojavi4の予感？
ttp://knym.net/wiki/index.php?PHP%2FMojavi
＞FATAL [/var/www/mojavi.org/opt/user/SessionContainer.class.php:35] Only variable references should be returned by reference
＞Mojavi4の予感？
ttp://knym.net/wiki/index.php?PHP%2FMojavi
>>955
しまった。SessionContainerってM2にあったのかorz
しまった。SessionContainerってM2にあったのかorz
PHP4.4のﾖｶｰﾝ
wasp 使った人いる？
今英語のドキュメントを見てます。
余裕があれば土日でいじってみますが
他にも試したい物があって・・・
英語苦手です。
今英語のドキュメントを見てます。
余裕があれば土日でいじってみますが
他にも試したい物があって・・・
英語苦手です。
>>954
これもいれて。
PHPフレームワークの比較
http://lnx.googlewrite.com/chart.php
http://phpspot.org/blog/archives/2006/01/php_30.html
PHPフレームワークのリスト
http://d.hatena.ne.jp/koyhoge/20060327/1143444511
あと、フレームワークの簡単な紹介もつけてくれるとうれしい。
Symfony (機能てんこもり)
Cake (Railsライク)
Agavi (Mojaviを改良)
みたいな。
これもいれて。
PHPフレームワークの比較
http://lnx.googlewrite.com/chart.php
http://phpspot.org/blog/archives/2006/01/php_30.html
PHPフレームワークのリスト
http://d.hatena.ne.jp/koyhoge/20060327/1143444511
あと、フレームワークの簡単な紹介もつけてくれるとうれしい。
Symfony (機能てんこもり)
Cake (Railsライク)
Agavi (Mojaviを改良)
みたいな。
>>959
なんか主観入りまくりの紹介がついてモメそうな予感ｗ
なんか主観入りまくりの紹介がついてモメそうな予感ｗ
>>954は行数制限ギリギリなんでこれ以上は無理ですよ
紹介はモメるから俺は入れない
紹介はモメるから俺は入れない
962 ：nobodyさん：2006/04/19(水) 09:22:09 ID:1t4rF7dP
>>962
あー来たか、スレも終了間際に。
あー来たか、スレも終了間際に。
>>964
ラテン語．
ラテン語．
symfonyは重さ的にはどんなもんでしょう？
>>265
NARUHODO
NARUHODO
symfony使ってみたいけど、
詳しい日本語サイトがないな。
英語はアホだから読めん。
詳しい日本語サイトがないな。
英語はアホだから読めん。
>>968
この辺を見ながら始めればすぐに分かるはず。
http://develop.ddo.jp/tech/index/PHP/Symfony/documentation
http://www.minfish.jp/blog/archives/2006/01/pearphp5.html
http://blog.symfony.jp/
最初にムービー見たほうがよいかもよ。
http://downloads.symfony-project.com/demo/cart/cart.mov
この辺を見ながら始めればすぐに分かるはず。
http://develop.ddo.jp/tech/index/PHP/Symfony/documentation
http://www.minfish.jp/blog/archives/2006/01/pearphp5.html
http://blog.symfony.jp/
最初にムービー見たほうがよいかもよ。
http://downloads.symfony-project.com/demo/cart/cart.mov
>>968
symfony使う前に英語を覚えることだね。
symfony使う前に英語を覚えることだね。
mojaviサイトちゃんと復活してるね
symfonyのルータよくできてるなー
なんか、どのフレームワークも一長一短だから
フレームワークキットみたいにして
バラ売りして欲しい。
っていうかそれがZendか…。
なんか、どのフレームワークも一長一短だから
フレームワークキットみたいにして
バラ売りして欲しい。
っていうかそれがZendか…。
Symfony 0.6.2 released
http://www.symfony-project.com/weblog/2006/04/20/symfony-0-6-2-released.html
http://www.symfony-project.com/weblog/2006/04/20/symfony-0-6-2-released.html
symfonyのルーターの
/:module/:action/*
の*ってどういう意味ですか？
/:module/:action/*
の*ってどういう意味ですか？
エラーメッセージの判定と、メッセージ自体は、action と model どちらに書いてます?
agavi萌え
Symfony使いたいのにPHP5の案件がない・・・(´･ω･｀)
>>980
4000円で俺の欲しいもの作ってよ
4000円で俺の欲しいもの作ってよ
SymfonyってVirtual Host使わないと使えないの？
>>982
そんな事は無い
そんな事は無い
SymfonyってPear使うと簡単インストールみたいな感じになってるけど
あれできないとなんかややこしいよな
説明も投げやりだし
あれできないとなんかややこしいよな
説明も投げやりだし
>>984
sandbox使えばいいじゃん
sandbox使えばいいじゃん
SymfonyやZendFrameworkやMojavi3やAgaviはDIコンテナ搭載してんの？
もし搭載してないならMapleにも劣ってね？
もし搭載してないならMapleにも劣ってね？
>>987
いやいや、今やJava界隈ではDIxAOPは大盛り上がりだよ。
実際に業務で使われるレベルでな。
もし、今PHPでリリースされてる数々のフレームワークが
DIxAOPに対応してないのであれば、２年遅れてるね。
いやいや、今やJava界隈ではDIxAOPは大盛り上がりだよ。
実際に業務で使われるレベルでな。
もし、今PHPでリリースされてる数々のフレームワークが
DIxAOPに対応してないのであれば、２年遅れてるね。
なんで典型的な釣りに引っかかるのか理解に苦しむ
>>988
JavaとPHPでは使われる規模が違うだろ。
あと多分あんた最近DIとAOP知ったんだと思う。
俺も1年前そう思ってたから。
PHPでDIなんか使う（必要とする）場面がほとんどないと思うのだが。
逆に使うと解りにくいと思う。
だが、Seasar.PHPは応援する。
実際に業務レベルで使えるかどうかでは無くて、
可能性を示してくれた事に対して。
JavaとPHPでは使われる規模が違うだろ。
あと多分あんた最近DIとAOP知ったんだと思う。
俺も1年前そう思ってたから。
PHPでDIなんか使う（必要とする）場面がほとんどないと思うのだが。
逆に使うと解りにくいと思う。
だが、Seasar.PHPは応援する。
実際に業務レベルで使えるかどうかでは無くて、
可能性を示してくれた事に対して。
次スレまだ
たてたる
無理でしあ
次スレの ZendFramework が ZendFramewoekになってる
本当だ
ついでに1000げと
1001 ：１００１：
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
もう書けないので、新しいスレッドを立ててくださいです。。。