[PHP]フレームワークについて語るスレ2[総合]
1 :
nobodyさん :
2005/12/29(木) 18:03:44 ID:PQZNoJbD
乙カレー
■PHOCOA
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 が出たのか? 触ってみた人いる?
>>8 えらい変わっとるでよ。
んでも機能追加・拡張っぽい感じなので、よほど変わった書き方をしてなきゃ
0.9.0で書いたのはそのまま動くんでないかな。
MojaviとAgaviが合体する話はどうなったの?
んで、どれを使うといいの?
ドキュメント読んでビビっときたものを使え
今、PHPには使うべきフレームワークというのが無いよね。 JavaにおけるStrutsのような。 PHP5は流行らない・スタンダードとなるフレームワークが 登場しないとくればPHPはかなり苦境だな。
なんかPHPとJavaが対決してどちらかが勝たねばならないかのような前提で喋る人って多いのね
PHPが流行ってくれないと苦境かもね。 PHPだけで食っていこうとするなら。
>>15 PHPだけで食っていく人って給料どれくらいなの?
PHPだけしかできないようなPGだと、月50は無理でしょ。業務委託だとしても。
まさかJavaよりRubyのほうがスケーラビリティ高いとか言わないよね? そもそもPHPだって設計きちんとやれば見下ろすほど拡張性低くないのにね。 まあJavaは言語仕様自体が拡張性上げてるようなもんだし。 特異メソッドだの特異クラスだのクロージャだの溢れかえったRubyにスケーラビリティのスの字もないと思うけど。 拡張モジュールをCで書いたりなんてことになると、もうね。 それより、Zend FrameworkはPHPネイティブらしいし、スケーラビリティに関して少しは期待していいかと。 RoRと比べてどうかとかは出てからじゃないと何ともいえないけど。 ↑なんかこいつ根本的に勘違いしてるな
>>9 >0.9.0で書いたのはそのまま動くんでないかな。
動きません。
22 :
nobodyさん :2005/12/31(土) 07:42:47 ID:/O+wCTfO
そもそも PHP は言語仕様が…。
>>21 そ、そうなんですか!
ショックです。
作り直さないといけないのか・・・・
>>20 > ↑なんかこいつ根本的に勘違いしてるな
あーそう。意見が合わなかったね。
>>24 年間3000円以下でJavaが動く鯖を教えてください
agaviはアクションに階層持たせられるようになったのが良
QuickStart Movieにあったようなコマンドラインから実行するやつのwindows版もついてきたね。 前からcygwin経由で使ってたから個人的にはあまり恩恵ないけど、 windowsであれをやってみたかった人は結構いるかも知れない。
>>25 年間 3000 円どころか、フリーであるけど。よく探せよ。
>>29 フリーてw
さすがにそんなとこ話にならんw
>>27 つーかSVNから持ってくれば使えたからね。
cygwinなんて遠回りしなくても
>>29 バーチャルサーバですか?
共用サーバでフリーでjava動かすなんて危な過ぎて趣味でしかつかえないからね。
新年早々どうでもいいよそんなこと。
34 :
nobodyさん :2006/01/01(日) 07:08:28 ID:WHqdtVTb
>>30 3000円もフリーも大して変わんねぇよ、貧乏人。
>>26 agaviってモジュールの方は階層持たせられるっけ?
フリーを除いて、年間3000円以下でJava使える鯖ってあるのか? まぁ、レン鯖板で聞けって話か
どうしてスレ違いのネタを引き伸ばそうとするの? 安上がりでJava使いたいのは結構だけど、お前の居場所はこのスレじゃない。
JavaにはStrutsやJSFなどのスタンダードとなるフレームワークがあるのに PHPにはそれがないねぇ。
>>38 PHPが元々フレームワークが必要な程のWebアプリの作成
を考えて無かったからでしょ。
で、今需要が増えてきたので乱立中なんでしょ。
速構Web Framework は目からうろこでした。 わたくしは一生をささげます。Mojavi よさらば。
商用利用時のライセンスがややこしそうだけど、そこさえクリアできればよさそうだね。
PHPはクラスライブラリが整備されないからね。いつまでたっても。
43 :
nobodyさん :2006/01/02(月) 03:33:36 ID:I7zXcpPd
>>40 どのへんが画期的だったのか良ければ教えて
そんなどこの馬の骨かもわからないフレームワークなんか 誰も使わないと思うよ。
って、PHP-Screw出してるとこだろ?
zend frameworkの公式ページってどこよ? 検索しても出てこないのだが
ドキュメント出すとか言ってたのに全然ださねーな 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
>>48 それだけ沢山の企業が開発に携わってるの?
ただのスポンサーかと思ってた。
ウェブ開発のフレームワークに、そんな大企業がウジャウジャ一緒に開発してるわけないじゃん。
なんだかんだで、まだMojavi。
アガビがいいー
アガビがいいけど、はやらない。
Zend Frameworkははやるかな?
現状だとやっぱAgaviかな。 使いやすいよ。
agaviでググってもほとんど情報が無いんだが。。。 日本人向きだとmaple ethnaあたりがよさそうかねぇ。
Agavi使うくらいなら、Symfonyのほうがドキュメントも充実しているしよさげ。
>>59 たしかにSymfonyはMojavi派生のようだが、Mojavi/Agaviとはずいぶん方向性が違うような
そんな自分の愛用は未だguesswork classic
mojaviでsmarty使う時、action filterでregistしてる? Viewをextendしてる?
Viewをextendかな。 かなりぴったりハマるしこれでいいやって思ってたけど、action filterでregistってのはどういうことなの?
Mojavi以外を使う勇気が欲しい
mojaviを使った勇気が欲しい・・・
mojaviなら誰でも使えるよ。 ググッて、がんがれ。
母「おい、おまいら!!あすたからフレームワーク使いまつ。勉強しる」 父「ネタ詳細キボンヌ!」 母「mojaviですが、何か?」 兄「キタ━━━━━━(゚∀゚)━━━━━━!!!」 妹「キタ━━━━━━(゚∀゚)━━━━━━!!!」 姉「>兄>妹 ケコーン」 兄「>妹(;´Д`)ハァハァ…」 妹「キモイヨ━!!」 姉「バiタ逝ってよし」 母「オマエモナー」 父「--------終了-------」 兄「--------再開-------」 妹「再開すな!ヴォケが!!それより情報う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 あたりかな。 今後もこの流れだと思う。
>>62 Mojavi JapanにあるMSQDなんかをダウンロードするとわかる
filterでsmartyを使ってる
他のサンプルでもそうしているやつを見た
どういうポリシーの違いだろうか
70 :
62 :2006/01/07(土) 09:49:50 ID:???
>>69 あーM2の話だったのか。
M2だとSmartyRendererが用意されてるから、その初期化をfilterでやるのが普通なのかも(俺はM2経験ない)。
M3の場合だとSmartyViewっていうのが入ってるけど、まだ中身が何も実装されてない状態だったから自分で書いた。
基本的にM2のSmartyRendererと一緒で、$smarty->assignとかのラッパを書いたってだけの話だけど。
Agaviでは実装済みだね。
要は
>>61 の質問は結局はM2かM3かって話になると思う。
HTML_QuickFromのフォーム関連の処理はどこへ置いていますか? forms/ 以下にまとめているものをよくありますがactionsでかいちゃう人もいるようです。 僕はmodelの下で executeForm()で処理させようかと思っていますがどうでしょうか?
>>68 mapleってMLも2chのスレも全然活気無いけどはやってるの?
質問の必要が無いほど完成されてるのかな?
最近Ethna始めたけどこれも結構いい感じだね。
73 :
nobodyさん :2006/01/08(日) 02:44:47 ID:MOiqJ8HA
>>72 >MLも2chのスレも全然活気無い
はやってるはずがない。
eZ systemsってどうよ?
Zend PHP Frameworkの一番の宿敵になりそうって言われてるけど。
http://ez.no/ mod_rewrite使ってるのあたりが個人的に微妙。
eZ publishはドキュメントとかやたら張り切って書いてあるわりにサンプルコードが少なくて、結局使い方がイマイチわからなかったよ・・・。
機能が豊富そうっていう印象はあったけど。
eZ componentsは要はクラスライブラリ群?
>>72 モノは良いと思うんだけど……
とにかくドキュメントやサンプルが不足すぎて手を出しにくいこと、
作者がアレコレ色々なものに手を出していて完成品が全然出てこないこと、
利用者コミュニティがブログ周辺で完結してしまっていて参加しにくいこと、
などなどから、利用者はさほど多くない雰囲気。
気に入らないコードを自分でばんばん書き換えちゃえるくらいだと
けっこう良いフレームワークだと思う。
仕事で使ってるけど、良く出来てると思うよ。 ドキュメントないからソース読めないと困るかもしれないけど。
ソースを読まないとどうにも進まないのは大抵のフレームワークに言えるねぇ。 良いものでも、「Hello world を出力してみよう」ってくらいで・・・
フレームワークって楽に開発するための物なんだから、少なくとも ソースを読むことが必須な状態からは脱却してほしい。 いろんなレベルの人と協業するのに今の状態では辛すぎる。
ドキュメント化しよう、とは思わないんだね
ZPFが出れば流れも変わるんじゃない? Extreme Simplicityとか謳ってるくらいだし。 .NET、Struts、RoRのパクリがほとんどで真新しいものはないけど、逆にPHPでそれらが全て利用可能になるってのは大きいんじゃないかな。 PHPらしく多くをベタ書きで書きつつ自然にフレームワークの恩恵に与れるっていう形になるんじゃないかと。 今あるフレームワークはどれも癖のあるクラス設計を強いられるから、PHPらしくないんだよね。
Zendフレームワークって エクスパンションなのかなあ?
>>81 Zendのフレームワークも、べた書きなんてありえないバリバリのOOデザイン
だとおもうよ。なにせあのPHP5を作ったZendだからね...
>>82 PHPの拡張ってこと?
そうすっと今度は微妙な振る舞いをCソースがよめないせいで確認できなくて
困る人が多発する気が...
Zendのフレームワークみたら、PEARとか全然生かしてなさそうだね。
>>82 エクスパンション == extension ?
Webcastでは全てPHPでオープンソースで書くって言ってた希ガス
>>83 そうかなぁ。
フレームワークのコード自体はOOで書いてあっても、我々ユーザにはOOの設計を強要しないって感じになってもらえるとありがたいんだけど(つまりOOは「使う」だけであって「作る」必要がないって感じ)。
フレームワークのコンポーネントを最小限の部分だけ継承して2〜3行ちょろっと書いとけばあとは勝手に動いてくれる、みたいな。
>>84 Pearはおろか既存のものはSmartyなども含めて一切使わない方針で、完全に独自の設計になるらしい。
テンプレートも独自のものみたいだし。
そこに批判もけっこうあるみたいだけど。
ちょっとしたもんに使える、手軽な奴ってない?
使ったことないけどguessworkとかCakePHPとか。
フレームワークとか使ったことなくて、 とりあえずmaple見てみたんだけど、なんかディレクトリ深すぎない? 設定とかで変えれるのかも知れないが、 あっち行ったりこっち行ったり面倒なような。 どんな環境でどのくらいのファイル数になるのを想定してるのかな…。
89 :
88 :2006/01/09(月) 08:38:56 ID:???
補足。特に批難とかしたい訳じゃなくて、 単にああいう構成になってる理由が疑問って話。 他のは違うのかもしれんが…。
>>88 少ないディレクトリにファイルがゴッソリあるよりマシ。
agavi UPDATE 2005-01-08: 0.10.1b has been released!
>>86 cakeの場合、データ構造が単純ならscaffoldingが使えるから、死ぬほどお手軽。
Mapleは オレオレフレームワークのたたき台を目指してるみたいだね。 標準になるべくZendフレームワークが出てきたので 戦略的に正しいと思う。
94 :
86 :2006/01/09(月) 18:22:40 ID:???
>>92 いや、88ともダブるんだけどさ、なんかみんな大げさすぎない?
そういうのが必要な場合があるってのは分かるんだけどさ、、
ちょっとしたもん書く時にさ、ベタで書くより
なんちゃってMVCにしとけば、楽じゃん?みたいな感じなのないかな。
逆流してる?
カウンター作成専用のフレームワークつーのには興味無いな。 そのフレームワークが対象とするもののうち一番大掛かりなものになるのは当然と思われ。
フレームワークはリロード対策とかしれくれないのか?
>>96 MapleにはTokenフィルタってのがあるね
mojaviのaction.class.phpの上にあるライセンス表示って別に残さなくてもいいんだよね?
>>98 mojaviを改造でもしてんの?そうでなかったら編集する必要すらないと思うけど。
一応LGPLだしランセンス表示を含めどんな改変をしても構わないけど、改変後のプログラムはGPLかLGPLのもとでオープンソースとして再頒布しなきゃいけないんじゃないかな。
間違ってたら訂正よろ。
LGPL表記と著作権表示を削るのは多分よくないでしょう。空のファイルでもLGPL配布物の一部ならば。 ここは堂々と著作権者に自分の名前を追記して配布汁。 頒布っていうか、べつに広く配布する必要は無いし、ソースを売って金にしてもいいけど、 そのソースコードをもらった人にLGPLによるソース再配布の権利を認めないといけない。 だからLGPLコードを暗号化して顧客に納品しちゃダメ ...て感じだと思う。
>>100 なるほど。フォローサンクス。
ちょっと気になったけど、LGPLはソース保持者が配布することができる「権利」ではなくて、(要望があれば必ず)配布しなければならないことを使用条件とする(というか強要する)ものじゃないかな。
だから売って金にするってのはまずいのでは?
>>101 売って金にしても問題ないはず。
ただし同時に無料配布する必要もある(実費程度はとってもよい)。
成果物(ソフトウェア)の所有者にのみソース公開の義務が生じるだけだから、 広く一般に公開する必要は必ずしもあるわけじゃない。どんな高い金で売ってもOK ただし、ソースをもらった方はLGPLに基づきいくらでも再配布出来る。そしてそれを縛ることはできない。
LGPLで言う所の、"work based on the library(ライブラリを基にした著作物)" と
"work that uses the library(ライブラリを利用した著作物)"は違うから、
mojavi部分と独自のビジネスロジック部分とを分離して独自部分を配布する場合は
LGPLの範疇にならないんじゃないかなぁ。
まぁ、
>>98 のライセンス表示削除は確実にアウトですが。。。
mojaviをフレームワークとして通常の利用する分には今の話の流れとは関係ないよ(GPLではないのでこれらは売ろうが隠蔽しようが公開しようが自由だと思う)。 飽くまでmojaviを改変した場合の話。 ライセンス表示は削除したとしても、新たにLGPLの全文か全文へのポインタ相当のものを示せばいいんじゃないの? 著作者の表示に関しては、元の著作者(mojaviの場合Sean Kerr)を載せる必要ってあったっけ? PHP Licenseだとそういうのは明示的に書かなきゃダメってなってるけどLGPLはそういう項目ある?
変更する場合は変更箇所の明示と著作権の追加をすべしっていう項があった気がする。 ライセンスはどうか知らないけど、ファイル中の著作権表記の削除はGPL以前に著作権的によくないと思う。 あと、一緒に配布するかぎりはLGPLでもGPL的縛りを逃れられないような... このへんの成果物の扱いはGPL/LGPLで記憶も理解も混乱しているのでよくわからん。
107 :
98 :2006/01/10(火) 16:03:17 ID:???
というかMojaviを改変したわけでなく、新しくLoginAction.class.phpなどを 自分で作ったのです。 それの著作権は自分にあるのでサンプルにあるような著作権表示は削除しても いいと思っていたのですがどうですか? または、Mojaviからextendsしたファイルとかはどうなるんでしょうかね。 要らないと思っていたんですが、違うのかな。
108 :
105 :2006/01/10(火) 16:14:49 ID:???
>>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等によって使うことと考えて差し支えないと思う。
109 :
105 :2006/01/10(火) 16:25:47 ID:???
と思ったけど、「in isolation」ってなってるな・・・。 mojavi使って作ったソースって、GPL/LGPLを明記する義務があって且つ再配布されても文句言えないってこと? なんかわからなくなってきた。
work と Library を まじぇまじぇして配布するなってことでしょ?
まじぇまじぇさえしなければLGPLの呪縛から完全に逃れられるってこと?(mojavi本体がLGPLなことは除いて)
Mojaviみたいなフレームワークの場合、APIのみ同じであるようなフレームワークを 自分であらたに開発すればいいので、それを使うスクリプトは独立しているとみなしていいはず。 だから、自分の製品の一部に組み込んでmojaviを配布する場合はLGPL縛りで、 独立したものとして配布する場合のライセンスは自由なんじゃないかな。 スクリプトの場合、全部のファイルが独立しているという見方も出来るから、 このへんは難しいとこだとおもうけど。
113 :
109 :2006/01/10(火) 17:49:43 ID:???
紛らわしいこと書いて失礼・・・
> 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=作業員
116 :
nobodyさん :2006/01/11(水) 02:52:36 ID:0BNMEQyQ
フレームワークで作ってたら、 どこか変更する必要がある時、 「どのファイルをいじったらいいのか?」が パッとイメージしにくくない? とりあえずAction開いて、 そこから読んでるけど。 何かいい方法ないかなぁ…。
フレームワークで分けられてるだけマシだと思ってやってる。
118 :
nobodyさん :2006/01/11(水) 07:49:18 ID:SLuQbgaX
>>116 保守性を考えるならまともな仕様書/設計書を残しておけ。
120 :
98 :2006/01/11(水) 18:53:00 ID:???
>>116 やりかた次第じゃないのか?
わかやすいように機能ごとにファイルにしたりとかもできるんじゃない?
122 :
nobodyさん :2006/01/11(水) 22:58:55 ID:0mCKrO3o
agavi使ってるんだけど、エラー処理どうしてる? action の initialize で false を返すとexception投げて来るんだけど、 どこでどうやって捕捉すればいいのかわかんね。
123 :
nobodyさん :2006/01/11(水) 23:01:22 ID:SURfFh1U
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
>>124 またagaviのとこかw
つーかagaviのサイトってagavi使ってたんだ。
mojavi2でのポストフィルタの使い方がわかりません。 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);
}
}
}
128 :
nobodyさん :2006/01/12(木) 16:47:35 ID:9A+OuFoz
>>127 そんな感じでOKだとワシも思う。
それより、
>>126 まともにグーグル先生すら使えんもんが、何を作ると言うのだ。と、小一時間。
>>127 ,128
ありがとうございます。
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を実行
という順番で処理されることになる。
>>130 詳しい説明ありがとうございます。
動作順序がよくわかりました
なんでそういう複雑な感じになってるかはよくわかりませんがw
検索用用語
プリフィルタ ポストフィルタ prefilter postfilter mojavi2
132 :
nobodyさん :2006/01/12(木) 21:57:58 ID:9A+OuFoz
mojaviのlibとoptに入れるものってどうやって分けるの?
>>133 何かと思ったらMojavi2の話か。
libとoptってMojaviのコンポーネントのソースが入ってるとこじゃないの?
自分で作ったものは基本的にwebapp/libだと思うけど。
>>130 >Viewの実行(View::execute())はExecutionFilterの中で実行されている。
じゃあ、ExecutionFilter以降のPostFilterは何をしてるの?
>>135 それは君が決めること。
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
フレームワーク使ってると 仕込む場所と 使う場所が離れてるから、 知らないうちに使われない変数やオブジェクトが 増えて行ったりしない? あといつの間にか使わなくなった関数とかも増えがちだ。
誰か俺に一からフレームワーkとオブジェクト指向について教えろ!
本でも読め
142 :
137 :2006/01/15(日) 19:43:37 ID:???
いや 1:テンプレートにassign 2:テンプレート側の変更で使わなくなる 3:assignはされたまま みたいなことないかい?
あと使わなくなったリクエストパラメータの バリデータが残りっぱなしみたいなこととか。
145 :
324 :2006/01/16(月) 01:05:52 ID:VcFB/Doi
>142 すごい巨大な配列とかなら気にするけど、 普通のデータだったら、いちいちそんな細かい事気にしてられません。
>>146 分離してるからこその問題じゃん
MS公認コードコンプリートでも
変数のバインドは出来るだけ短くせよと説いているが
ファイルをまたいでバインドしてるわけだからなぁ。
>>147 テンプレートで使わない変数は渡さないって考え自体が分離を阻害している希ガス。
使わない変数は渡さないのは 防御的プログラミングの基本じゃない? でも一括で渡すフレームワークもあったっけ。
今までActionを記述する時は initialize,execute,getDefaultViewとかの主要メソッドを前において バリデーションとかコンバータとかgetRequestMethodsとかのサブ的なメソッドは 後に詰めてたんだけど、 サブ的なメソッドの中にこそゴミがたまりがちなので、 上の方に置くことにしてみたよ。 視界に晒されることで整理整頓が促されるかなと。
クラスファイルは大文字から始めるのがPHP風だけど テンプレートのファイル名は 大文字から始めてる?小文字から始めてる?
俺は大文字から始めてるな。どっちでも良いと思うけど何となく
そんな複数の変数をテンプレートに渡すのが普通なんですか? おいら、Viewでまとめてから、テンプレートに送ってんですが、 この下記かたはありですか?
ViewでHelperに変数をセットしてから Helperだけassignとかもやるお。
PEAR コーディング・スタイルで書けばいいのに。
PEAR コーディング・スタイルって、どんなん?
こーでぃんぐきやく
PEARのコーディング規約をeclipseでどう設定するのでしょうか? とりあえずタブが空白4文字でなく\tになってるのをどーにかしたいのですが…
>>145 Smarty使っているのなら、{debug}で送られている変数全てを確認してみればイイのでは?
>>160 truestudio使ってるなら
ウィンドウ>設定>PHP>Editor>Typingタブで
「Insert spaces for tab(〜)」にチェックをつける。
Zend Framework まだ?
あとちょっと
Zend FrameworkってPHP5専用?
今出ました
AgaviのUnitTestはどうやって行うんですかね? testsフォルダに生成された各TESTファイルにTESTケースを 記述し、「agavi test」をプロジェクトルートで実行しても、 実行されたのは0で、エラーも0・・・。 どうやったらTESTが実行されるのですか・・・。 Tutorialは抜けてますし。
zendが出たら俺の計画が始まるのに
Ajaxベース・・・、面白いけど誰も使わなそうだ
皆フレームワーク作るのが好きなんだなw 一ユーザからするとその熱意を既存のフレーム ワークのブラッシュアップに使ってほしいものだが。 そのうちフレームワークを作るためのフレームワークが 出てきたりしてなw
現状mojaviがそれにあたる。
mapleかなんかも作者がそんなこと言ってなかったっけか。 うろ覚えだけど。
AgaviってPHP4版もあるの?
176 :
172 :2006/01/21(土) 18:49:24 ID:???
あるのかよ・・・orz
>>176 mojaviから派生したフレームワークがある事を言ってるんじゃね?
>>175 php5だけじゃないかなぁ。mojavi3(php5)から派生してagavi って感じかと。
>>177 ということは実質PHP4のフレームワーク代表はMojaviと考えて
よろしいですか?
まあMojavi知っておけば 他もだいたい対応可能だろう
>>178 PHP4の代表はMapleだと思う。
俺はPHP5しか使ったことないのでMapleは
使ったことないけど、活動が活発だし、
面白そうだなぁと。
Phrameじゃないの?
国内ならmojaviかEthnaジャマイカと。
>>181 よくもまぁあんなキモいフレームワークを使う気になれますよね。
>>181 作者があっちこっち出没していろんなものの良い所を取り込もうとしている、という意味では活発だけど、
中途半端だし、ユーザーが活発かというと微妙。
でも期待はしているので、ユーザーが増えて、使い方のノウハウや
ドキュメントが増えて来ればいいなと思います。
zend frameworkはいつなのよ。
188 :
181 :2006/01/22(日) 17:27:44 ID:???
Mapleは中身は全然見たことないのだが、
作者の周りに結構(俺から見たら)すごい人がいるし、
>>185 が言ってる他言語の良いところを取り込もうとしてる
ところがいいんじゃないかと。生涯PHPだけって人にはいらん
機能かもしれないがな。
前にドキュメント強化月間かなんかやってた気がするが、
全然ダメだったの?
やっぱZend FrameWorkが出たらそれ使うだろうなぁ〜。
今はAgavi使ってる。
zendがんばれ ちょーがんばれ
>>188 全然ダメだった。ひとっつも強化されずアウトプットは何もなかったw
>>186 リクエストデータ毎にセッター・ゲッター作るところ。
>>191 それ作者もキモいと思ったらしくて次のバージョンではなくすとか書いてたね
例によって「次のバージョン」が全く外に出てこないわけだが
ゲッターは必ずしも必要じゃない。が、DIコンテナとか、PHPには無駄にヘビーなだけだと思うね。
まぁ土方用言語だしな。
DIはいらないけど、PHP4でAOPって実現できるの?
私も agavi使ってます。 mojaviと大して変わらないから覚えるの楽だし、それほど不満はないな。
197 :
nobodyさん :2006/01/23(月) 04:26:26 ID:sSJ3Zalm
入力フォーム作る時って 入力・確認・登録全部一つのActionに入れる? 入力・確認 / 登録 に分ける?
あとモバイル対応する時って Actionから別にする? Actionは共用でテンプレートだけ分ける? あるいは両方(共用可能な場合のみ共用)?
あとうんこする時って 便座あげてからズボン脱ぐ? ズボン脱いでから便座あげる? あるいは同時?
>>197-
>>198 はっきりこれと言う回答は無いよ。
アプリケーション内で統一すべきケースもあれば、画面ごとにバラバラにするケースもあり
もっというならパフォーマンス重視なのか
パフォーマンスを犠牲にしてでも実装しなければならない機能があるかとか
コーディング規約として統一する場合もあるだろうし
ActionとViewの切り分けなんて優先度的にはかなり後のほうだと思う
もっと柔軟に考えたほうがいい
MVCの概念やフレームワークにとらわれすぎてやしないかね
>>197 HTML_QuickFormを使ってれば全部一箇所になるでしょ
Model内で全部やっているけど。
>>198 個人的にはURLとActionを全部一緒にしているが認証関係をさせるなら
PCの場合でも負荷がかかるということに後で気づいた。
毎回IPチェックとか必要だからね。
203 :
198 :2006/01/23(月) 19:47:05 ID:???
204 :
202 :2006/01/23(月) 19:47:49 ID:???
さらにすまん。 名前欄の198は202な〜
205 :
181 :2006/01/23(月) 23:06:00 ID:???
俺が地雷を踏んでしまったために、 Mapleスレでもドキュメントの話が出たみたいだなぁ・・・。 Maple関連の上位エロの人のサイトで 「「Mapleはアウトプットが出てこない」と叩かれていたりするし(笑)。」 とか書かれちゃった・・・。すまんこってす。 やる気を削いでしまったのなら本当に申し訳ない。 かなり参考にしているサイトなので、これからも頑張ってホスィ。 関係ないけど、その上位エロの人って、実はMaple作者とあんま仲良くない? て思うんだけどどうだろ・・・。微妙にトゲを感じたのだが、気のせいかな・・・。
UPDATE 2005-01-08: 0.10.1b has been released!
agaviのトップページの記述が間違ってるってことだべ。
>>91 あたりでも言ってる人いるなぁ。
ここに書くより、本家に言った方がいいのに。
「上位エロ」って何?
>>209 普通に、上位のエロの人だと思うが・・・。
わからんて はっきり書け
上の位にいるエロの人だよ
つまりMapleはエロエロってことか
どっかの会社みたいに社員そうでで売名や貶めるのは好きじゃないなあ。
板違い
日経システム構築にPHPフレームワークの記事が少し載っていたが Mojaviに「もじゃび」ってフリガナがふってあったw
本来はモハビじゃなかったっけ?
だがしかし、俺はモジャビと読むからな! Jalapeno ハラペーニョ(辛いやつ) Fajita ファヒータ(メキシコ料理) Mojave モハーベ(砂漠の名前らしい) やっぱりモハービかな・・・
>>222 なにー、Sean Kerr公認ときたか。
残念。
でも頑なにモジャビでいきたい。
俺もモジャビって呼んでるけどね。
おれも心の中では mojavi はモジャビだし GIF はギフだ
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 俺もおかしいと思うよ。書き換えたらいいと思う。
>>227 cakeは後戻りできないくらいにまでソースが汚れてきてます。
あれはもうだめでしょう。
それよりsymfonyのslotsってちゃんと動く?
>>229 仕様だろう
おれもそれ、なんかバグくさいな〜って思っていた
仕様ってそうなることを意図して作った場合に使う言葉じゃないの? 単なるバグでいいと思うけど。
238 :
nobodyさん :2006/01/29(日) 09:48:17 ID:aQNUYPH4
バリデーションを済ませた 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名に関する整合性が少し保てなくなる)。
>>228 ざっとみたけど、おもしろいな、これ。
英語ページつくれ。世界に発信しろ。
>>240 ざっとみたけど、どのへんがおもしろいの?
ローマ字のところじゃないか?
ローマ字ページつくれ。世界に発信しろ。
ローマ字じゃ世界には発信できんだろ w
アニオタ外人ならなんとか。
SJISなのに文字エンコードに関する情報がHTML内に無いのがーおもしろいね そーゆーぺーじは多いがー外人SJIS読めんよ
稀に見る幼稚な文章だな。。。
そういう話はWeb製作板でやるべきだしな
まぁ面白いところといえば
<!-- *********************************************************************** -->
<!-- <HEAD> -->
<!-- *********************************************************************** -->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Frameset//EN"
"
http://www.w3.org/TR/REC-html40/frmeset.dtd ">
じゃないか
Zend Frameworkはまだ〜 もしかしてあの発表は世界規模の集団幻覚?
>>251 まだ今年はじまったばかりなのに来年かよ( ゚Д゚)
でも本当にそれくらいになりそうだね。 とにかく変化がなさすぎる。
agavi.jp終わってるな・・・
Symfony 0.6 is out!
Agavi使おうか、Symfony使おうか悩む・・・。 Symfonyは使った事がないのですけども、強みはAjax? Agaviと比較するとここが勝ってる、または負けてる っていう点があれば教えて下さい。
257 :
256 :2006/02/10(金) 22:24:02 ID:???
agaviはいいよ。不満はない。
Symfony 0.6 の Sandboxは良いね。 ダウンロードしたのを展開すれば、空のプロジェクトが出来るので、 導入の敷居が、かなり低くなる。
Ruby on Railsって何が良いの?
何か作った気になれるとこ
一過性流行なところ
>>256 手っ取り早くつくりたいならsymfony
保守性はagaviのがいい。
agaviのサブアクションの仕組みがいいね
Zendフレームワークはいつくらいになりそう?
おまいらagaviは0.10.1b使ってるのか?
>>267 リポジトリにあがってるのは
0.11.0(trunk-DEV)だよね>version.php
Mojavi4はいつ出るんだ?
>>267 今確認したんだけど、agavi-current.tgzは展開するとagavi-0.10.1bが出来るけど
0.10.0(stable)だね>version.php
ディレクトリ名とversion.phpの表記が違ってるのが不明・・
ソースの更新日付的には
>>268 が最新です
MojaviやAgavi系がPHPのフレームワークの デファクトと考えて差し支えないでしょうか?
Zend Frameworkが出ればデファクトになります。 出るのは来年だけどね。
新しいZendStudioの出来が良かったから 密かにZFも期待してる
ViewってActionの成果物をテンプレートにAssignするだけのいらない子と思ってたけど 主機能はむしろViewHelperで、 テンプレートから呼び出されるメソッドを保持する偉い子だったんだな。
>>277 web開発における MVCモデル そのものを勉強しろと小一時間・・
プレゼンテーション層に主軸をおいたStruts系の場合 M=Model及びAction V=Action及びView C=Controller だから明確な区別は難しいんだよ。
Agavi実際に稼働させてる奴いる?
PHP4でフレームワークって皆さん何を使ってますか? あと、PHP5だと何を使ってるかも教えて下さい。
>>281 最近ちと人が大目の職場に転職したんだが、そこではphp4+mojavi2を使うようにと言われている。
個人的な物には、php5+agaviまたはmojavi3を使っている。
海外のどっかのサイトのアンケートだとSymfonyを使っている人が一番多かったんだっけ?
まぁでも統計結果が実情を正確に表せるほどフレームワークが広まっているような気がしないんだが。
てか、
>>1 に乗ってるのを全部使ってみて自分にあったものを使えばいいんじゃないかねぇ。
俺フレームワーク使ってます。意外と多いのでは。
俺も先行き不透明だったんで俺フレームワーク使ってるけど 最初削っていた機能が必要になるたび付けて行ったら どんどんM3に似て来た。 Mojavi系はConverterがないのが不満。 勝手に改造したらバージョンアップ時の整合性が面倒くさいからなぁ。
Mojavi2でRendererクラスのexecuteメソッドの引数に Controller、Request、Userの三つのオブジェクトを渡しているんだけど RequestとUserは使ってないんだよね。何の為に渡してんの?
286 :
202 :2006/02/20(月) 00:13:35 ID:???
Rednererを派生させたクラスで使う
286だけど、他の板での番号が残ってました すまん202ではないです
Actionから別のActionへのデータの受け渡しってどうやってる? Request->Attributeとか User->Parameterに入れる? ネームスペースで区切る、区切らない等いろいろ考えられるけど。
Mojavi2ならRequestにデータを格納し ActionChainのsetPreserve()をtrueにして渡すのが順当かな
290 :
nobodyさん :2006/02/20(月) 15:25:19 ID:X62Wwkk2
最近フレームワーク触りだした初心者でかなり申し訳ないのですが、 orマッパがないフレームワークはやはり皆さん自前でこしらえてますか?
>>290 PEARのDB_DataObject使ってる
292 :
nobodyさん :2006/02/20(月) 19:01:00 ID:vRXDRBjP
日本はMaple
>288 漏れはActionChain::register()の第4引数に連想配列で渡してるんだが、 ひょっとして少数派? むしろ値の戻し方がよくわからん。 $user->setAttribute()してるけど、名前ぶつからないようにするのマンドクセ
ActionChainってそんなに頻繁に使うもの?
296 :
288 :2006/02/21(火) 06:51:44 ID:???
>>289 >>293 両方知らんかった
さんくす
Request->Parameterは$_REQUESTを
保持するだけじゃなかったんだな
PgSQLSessionHandler使ってるんだが、 ユーザ定義のDB接続と同時に使った場合、 コネクション別々に張るの無駄じゃね?
mojaviのDB接続はつかいもにならんよ。 どうしても使うなら、コネクションプールするべし
>>297 pg_connectなら第2引数にPGSQL_CONNECT_FORCE_NEW指定しなければコネクションは1つだけど?
Simplateの中の人は 技術力では桁違いな感じだね。 これは期待できそう。 今は俺フレームワークで作ってるけど いずれは乗り換えたいな。
>299 知らんカッタ 無駄はないんだな。安心したよ。
mojavi2 + xml-rpc やろうとしてるんだけど、PEARのはしんどい(大幅に手を加えなきゃならない) なんか良い解決法ある? mojavi2は確定(というか変えるのめんどくさい)
流れぶった切りで失礼します。 今PHPとFirebirdでD.B.の中にあるデータの値を取り込んで、 Excelのグラフを自動的に作成する、スクリプトを作ろうとしているのですが、 ここで便利なフレームワークはないものでしょうか・・・ Excelではなくただのグラフを作成してくれるもの、 有償のソフト、は見つけたのですが、 これをオープンソースで行っているフレームワークはないかなと思いまして。 何か、良いものがあったら教えていただけないでしょうか? よろしくお願いします。
そういうのはフレームワークではなくただのアプリと言うんじゃないか?
Pearにエクセル出力出来るClassがあったと思う 使ったことないからグラフ出力出来るかは知らんけど
すみません、説明不足でした。 そのPEARのExcelWriterClassを使って表を作るところまではできたのですが、 グラフ出力が出来なくて。 日本のフレームワークは結構見た(つもりかも)のですが、なかなか見つからなくて・・・
■■声を大きく再掲示■■ そういうのはフレームワークではなくただのアプリと言うんじゃないかぁぁぁぁ?
Mojaviってコントローラにモジュール名とアクション名の2つを渡さなくては ならないけど、なんでみんな何の疑問も持たずに使ってんだろうか? 面倒くさくない?アクション名だけでいいじゃんとか思う。
デフォルトのmodule名設定しておけば Actionだけでいけるじゃん ただある程度以上になるとModuleがないとやってられねーけどな。
311 :
nobodyさん :2006/02/22(水) 20:47:08 ID:PffjIGDj
このスレで言ってるフレームワークはあくまでもウェブフレームワークだからね。 エクセル操作系のフレームワークとかライブラリって言い方も出来るとは思うけど。
ImageMagick かなんかかませばグラフ作れるんじゃね? めんどいし、Excel 多分関係ないし、フレームワークも関係無いけどなー
>>311 語弊があるな。MojaviとかAgaviとか
コマンドライン用のフレームワークとしても動作するよう設計されてるぞ。
それと「エクセルのグラフを出力する」てのはViewの問題だから、
「エクセルのグラフを出力する」クラスや関数群はライブラリであってもフレームワークではないだろ。
それも含めてウェブフレームワークだろ。ま、PHPはウェブ専用言語といっていいし、PHPでフレームワークといえば、ウェブフレームワークと同義だな。
>PHPはウェブ専用言語といっていいし ウェブ用言語として開発はされているが 専用 ではないぞ。
おいおいおまいら勘違いするなよ。 ここはWebProg板であり、PHPのフレームワークについて語るスレですよ。 たとえ/(Moj|Ag)avi/やPHPがコマンドラインだのエクセルだので使えたとしてもそれは板違い・スレ違いなだけ。
>>315 「といっていいし」だからそう大きく間違えてるわけでもないと思う。
まぁ「おれはWeb用メインには使ってない」って言う人は必ずいるだろうけども。
PHPをWeb以外で使おうとする時点でキチガイ。
突然だけど、無かったから貼っておく
PRADO
http://www.xisc.com/ PHP5専用フレームワーク
(確か、PHP5のコーディングコンテストで優勝した奴だったと思う)
個人的感想:
・.NETっぽくて分かりやすい
・重い
使ってみた人居たら、感想聞かせて欲しい
320 :
nobodyさん :2006/02/24(金) 10:03:20 ID:UY/cDtzQ
漏れにはWACTが最高です。他を使った事がないんだけどね。 Mojavi+Smartyを使ってる隣の奴らはよくグチってるけど、 WACT onlyな漏れはさっさと仕事を片付けてる。
WACTの感想って全然聞かないね。 ってか、他を使わず、WACTだけって人はかなり珍しい。
だいたい出来る事は同じなんだから 今更マイナーFWに手を出そうとはなかなか思わナイ
Mojavi2を使ってみた感想 ・Rendererクラスがフレームワークと密接に絡みすぎ。 ・Validaterや認証を一箇所を一括管理できないので保守性に欠ける。 ・ソースが汚い。
↑あー失敗。 ×Validaterや認証を一箇所を一括管理できないので保守性に欠ける。 ○Validaterや認証を一括管理できないので保守性に欠ける。
>>318 未だにそんなこと言ってる時点で時代遅れ
>>319 3.0ではキャッシュ周りも強化されててなかなかいいんだけど、
XMLメンドイ…
mojavi2のvalidaterはアホなので使わない
だからValidatorだって。
どんな教育を受けたら validator を validater なんて打つんだ?
DSの英語漬けしる。
varideatar
こういうの見てると、Agavi とか使う気無くすなwww
>>334 もう直ってるね。
どういうエラーだったんだろ。見逃した。
>>335 agavi本家は定期的にエラーしてるからあまり気にしてないw
しかもチェックすればすぐ分かるエラーなんだよな。 ノーチェックでアップしているのかと。
公開鯖でデバッグ(*´∀`)
あるある探検隊!あるある探検隊!
素早く直せば 気づかない
あるある探検隊! ヽ(`Д´) ヽ(`Д´) | ヘ|ヽ | ヘ|ヽ | ̄ | ̄ あるある探検隊! (`Д´)ノ (`Д´)ノ ノ|∧ | ノ|∧ |  ̄|  ̄|
修正ばかりで 完成しない
学習コストが 高くつく あるある探険隊! あるある探険隊!
覚えた頃には、旧式だ。
中途半端なものばかり
倫敦どんより 晴れたら巴里
ぶゆうでんでんででんでん
symfonyをアップグレードしようと思ったら こんなエラーが返ってきたんだけど… Exception: corrupt registry, could not retrieve channel symfony information invalid package name/package file "symfony/symfony" pear.symfony-project.comにPINGしても反応ないし 落ちてるのかなぁ
symfonyなんてマイナーなFWを使うなよ。
agavi よりはメジャーだぞ。
>>349 え?どこがマイナーなの?
あなたがムチなだけでは?
mojaviはずいぶん取りざたされてたのにagaviはイマイチなのはどういうことだろう? やる気なくしたmojaviとagaviのサービス精神との対比はかなりインパクト強かったと思うんだけどな。 実はmojaviユーザ(=依然PHP4ユーザ)が大半?
PHPにそれほどでかいフレームワークは必要ないからだと思うよ mojaviに自分の必要な機能を付け加えるだけで十分なんじゃないかな お手軽さが売りのPHPにagaviほどの機能は必要ないかと
いやーお手軽さが売りってのは従来のPHPの話だと思うけど、今はお手軽にも使えるしそれなりの規模にも対応できるってのを売りにしてるんじゃない? Java風のOO導入したりSPL整えたりZend Framework作ってるのは、少なくともZendはそういう方向に向かっているからだとは思う(中途半端かどうかって話は別として)。 もちろんごく小規模なものにも使えるがゆえに厨が多いってのもあるけど、今のご時世PHPは小規模のみっていう感じではなくなってきてるよ。 まあagaviはそこそこいいとは思うけど「必須」って感じじゃないってのはあるね。 なんか上でせっかくSymfonyの話がでてきたからちょっとチェックしてみようかとは思った。
Agavi 普通にいいよ、使いやすい
PHP4で、フレームワーク探してるんだけど、何が良いだろうか? やりたい事。AJAX、XML-RPC、RSS辺りを組み込みたいんだけど。
M3とAgaviの違いって何?
>>307 遅レスですまんが一回Excelでグラフ作成したテンプレを作ってそれをSpreadsheet_Excel_Writerで開いてデータだけを操作する方法じゃだめかな。試してないからわからないけど
ロジックによってViewとかHelperに追い出すか テンプレートに書くか迷うなぁ 明確な線引きってしてる?
>>353 >お手軽さが売りのPHPにagaviほどの機能は必要ないかと
それこそいつの話だって感じだよね。未だにPHP3でも使ってるのかな?
agavi使えば保守性高いもんが手軽につくれるのに。
>>352 agaviが出てまもなくsymfonyが出たから。
PHP4でも5でも動くFWってどれ?
>>357 もともとAgaviは(たぶん)Mojavi3の開発の遅さにあきれた人たちが勝手にMojavi3の穴埋め+独自の開発を始めたもの。
でもMojaviとAgaviの開発者の間で話し合いがあったらしく、今はMojavi3の開発は終了し、Mojavi3の代わりにAgaviを使ってね、とMojaviのサイトに書いてある。
いちおうMojavi4の開発は進められているけどまだいまいち形になってないね。
AgaviとSymfonyではAgaviの方がまだ使ってる人多いと思ってるんだどどうかな? どっちが優れてるかは置いといて。 Symfonyの方が多いのかな? どうせZend FrameWorkが出たらそっちにいこうと思ってたので Symfonyは全然触ってないんだけど、不安になってきたなぁ・・・。
>>365 ないよ。
はっきり言って、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よりSymfonyの方がメジャーなのか
symfonyはphpだけのものではないわな。 英語で検索すりゃそりゃ多いわ。
>>363 たぶん両方で動くやつってないと思う。
つーか両方で動く必要がないと思う。
>363 4で動くなら5でも大体動くんじゃね?
symfonyのtgz落としても展開に失敗するし。 pearもダメだし。 とりあえずsvnでcoできた。 なにげにsymfonyもmojaviの派生かい。
>>368 >>370-371 php framework mojavi: 111,000
php framework symfony: 88,900
php framework agavi: 12,300
まぁこんな感じ。
>>363 cakeは4と5両対応ってのがキーフィーチャーのひとつらしい。
その点は問題なく動く。
>>363 あとは、日本の Ethna、Mapleあたりも動く
383 :
nobodyさん :2006/03/03(金) 12:57:54 ID:Tn8o6vdH
今日 agavi の勉強を始めたんですが、 agavi で任意のテンプレートエンジンを使うのって簡単にできますか? SmartyView.class.php ってファイルがあって Smarty は使えそうだってところまではわかりましたが、 できることなら patTemplate を使いたいのです。
>>383 今のところサポートされてないなら簡単にはできないね。
自分でViewクラスをガリガリ書くとかあきらめてSmarty使うとか妥協が必要。
385 :
383 :2006/03/03(金) 17:26:15 ID:???
>>384 ありがとうございます。
残念ですが、あきらめて Smarty を勉強することにします。
一応 View クラスを書こうとはしたのですが、
patTemplate を require した時点でエラーが出てしまって手に負えませんでした。
>>385 SmartyView.class.phpを参考に(=パクって)Viewクラスを継承する
PatTemplateView.class.phpを書けばいいんだけど
patTemplate を require した時点のエラーってどんなエラー?
もしかしてPHP5でVARを怒られているだけじゃないの
>>380 >その点は問題なく動く。
動くけど問題はめちゃくちゃ多いぞ。
両対応以外にもね
>>368 せめて頭10件の内容だとか、
フォーラムの賑わい具合だとかで判断しようぜ…
>>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
PatTemplateView.class.php というファイルを作成し、
その冒頭部分で
require_once 'pat/patErrorManager.php';
require_once 'pat/patTemplate.php';
を記述しています。
>>389 webapp/config.phpの中にエラーレベル設定出来るところがある。
E_ALLだけにすればよろし。
391 :
383 :2006/03/04(土) 01:26:56 ID:???
>>390 なるほど。もうちょっとがんばってみることにします。
ありがとうございました。
>>387 cakeのrc4のアプリをPHP4からPHP5に移行したけど、
バージョン違いから来る問題はなかったよ。
いやまぁ、Dboをほぼ全面的に書き直すハメにはなったけどね。
それはPHP4とPHP5両対応とは違う話ってことで。
ModelとDboのドロドロの関係とドキュメント以外はまぁ問題ないと思う。
Railsへの道ははるか遠しだけど、
まぁ開発は活発だしまだ判断は早いと思っとる。
>>393 ワロスwwwwwww
発表してからそんな時間経ってねえだろwwwwww
>>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の警告が出たほうがいいでしょ
>>393 どれだけ短気だよ
PHPフレームワーク界ではよくあること
関係ないけどRails本が出るみたいだね ベーパーウェアって何?
>>400 あのwebcastから3ヶ月。ようやくリリースですか。
チェックしてみよ。情報d!
>>400 サイトのセンスもいいな
これは期待できそう
Controllerまわりを見てみたけどフローがRailsっぽい
tar.gzで6MBytesっすか...
含まれてるファイルの数が半端ないな 資本の力SUGE-
>>402 マニュアルのページのスタイルは禿しく手抜きだけどなー
ベーパーウェア 呼ばわりした外人どうすんだよww
Luceneのインデックスがそのまま読めるとあったので、PHPでLucene互換エンジンを スクラッチで書いたのかスゲーと思ったら、結構.javaもあるんだね。 たぶん、検索はphpのみでできる...のかな? ていうか、テンプレートと思われるtpl.phpファイルを除くと.phpと.javaの 各ファイル数の比は6:4くらいじゃんか。
当然PHP5前提だよな・・・
interface、abstract、exception、stl、などなどつかいまくりですがな
想像以上に作りがショボい…。
Controllerのドキュメントがないと思ったら、まだまともに動かないのね。 しっかりしてよ>Zend
zend frameworkって知らなかったんだけど、マニュアル読む限り、strutsみたいなウェブフレームワークというより、PEARの代替なんだな。
vaporware扱いされるに至って、少々あわててPreview releaseを出したのでは。 でもPdfとかLuceneとかのコンポーネントの独立性が高くて単体でも使えそうなのはいいね。
>>414 俺もフレームワークを期待してた。
独自のテンプレート・エンジンとか言ってたのに、Zend_View を見て
愕然とした。どう見ても生 PHP です、本当にありg(ry
あるみたいよ、テンプレート。 ただし、あのなつかしきPHPLIBライクの奴らしいけど。 Smartyのようなミニ言語テンプレートとはアプローチが違って 少々判りにくい面はあるとおもうけど、ちゃんとロジックを分割する方を選んだんだね。
ああ失礼。
>>417 は勘違い。
やりたいならPHPLIBのTemplateを使うなり自由にしなさい、というだけだった。
しかし、今時PHPLIBを例に出すかなぁ...
目を引くのは Pure-PHP の PDF 用ライブラリぐらいか? 今の状態じゃデファクト・スタンダードのフレームワークになったりする ようなものではないね…。
>>420 しかし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にどうやってつなげるかもよくわからん。
Controllerといい、Viewといい、Routerといい、ほんっとにRails風なのね。
だったらActiveRecordまでインスパイアされて作ってくれればよかったのに。
なんだか、ActiveRecordとか、generatorとか、scaffoldingとかAjaxHelperとかの
Railsの便利機能のないRailsクローンという印象。
責める訳じゃないけど extremely simple っていううたい文句も
Railsから持ってきただけだったんですか、と思うとちょっとむなしい。
>>425 ドキュメントによると、アクションメソッドの中で
手動でViewをインスタンス化してrender()を呼ぶらしいよ。
>>427 Railsよく知らんけど、ActiveRecordはあるんじゃないの?
webcastでも導入するって言ってたしDBまわりにそれっぽいこと書いてあるよ。
>>428 ごめん、デザインパターンのActiveRecordってわけじゃなくて、
RailsのActiveRecord実装のこと。
>>430 マニュアルにはZActiveRecordとか書いてあるよ
ActiveRecordパターンってRailsのActiveRecordを実装した人が命名したんじゃなかったっけ?
ZendFrameworkにもActiveRecord実装は確かにあるみたいだね、だけど Zend_DataObjectにはRailsのモデルみたいにbelongsToにテーブル名書くだけで find()のときに自動でjoinしてくれる機能はないよね? むしろ使い勝手としてはPEAR::DB_DataObjectに近くない? 混乱させてごめん。 Railsのモデルの機能とActiveRecordパターンを混同してたみたいだ。
Zendの連中は「物事をシンプルに保つ」ということが本当に出来ないな。
zendの正式版というのはあとどれくらいですか
>>431 ZActiveRecordみたいにZで始まるクラス名とZend_DbみたいにZend_で始まるクラス名との間の相関関係がよくわからんな。
つーかZActiveRecordってどこに入ってんの?
関係ないけど、Rubyの開発者の職場と結構近い事を最近知って、超興奮。 PHP、Java、Perl、Rubyの垣根がだんだんなくなってきたと 個人的には思ってるので、これを機会にRuby学ぼうと思った。 チラ裏すまん。あまりに興奮して。
やっぱパッケージシステムなしにクラスライブラリを充実させるのって無理あるな。クラス名、長。
>>438 ソースにはないね。
たぶんちょっと前はZend_Db_DataObjectがZActiveRecordという名前
だったんじゃないのかな。ドキュメントがそれに追随していないだけだと思う。
>>440 パッケージシステムっつーか、名前空間な。
まあ、Railsのいいところはマネしてもいいんじゃね?ただ、PHPでRubyのマネ(メタプログラミングまわり)はどう考えてもできないから、そのへんをどうすんのか気になる。
メタプログラミングなんかはフレームワークじゃなくて言語自体の話だね。 やるとしたらPHP6で無理やりとりこむか。 ところで、なんか前スレかなんかで「PHPはどうせ汎用言語じゃなくてWebに特化したものなんだからフレームワークみたいなものは言語仕様で提供すればいいのに」、って感じの話が印象的だったのを思い出した。 リンク張ろうと思ったけど検索で見つからなかったorz
メタプログラミングって何?
Web Archive にもないな
classkitとAOP使って織り込んでいけばメタプログラミングもどきっぽい事は出来そう。
>>444 まさに言語設計時の問題だよね。
PHP6で実装されたとしても今更感がある。
そーいやnamespaceすらない言語なんだよな・・・・・。
namespace は PHP5 のリリース直前まで入る予定だったんだけどな……残念だ
phpのcreate_functionとかevalはメタプログラミングとは言わないの?
RORも使ってるらしい?けど、evalはやだなぁ。。
>>450 たしか Andy がいつものように火病でトチ狂って入れないことになったんだっけ?
PHPはHTMLを生成するメタプログラミング言語です。
>>452 使ってるどころか、使いまくりです。
たしか Maple の kunit さんのブログに書いてあったんだと思うけど、PHP 的には
生成したコードを eval するよりファイルに書き出して inlucde するほうが速いらしい。
>>453 パフォーマンスが悪いということで Zeev に却下されたんじゃない? かなり怪しい記憶だけど。
PHP 6では導入予定で、CVS HEAD ではパフォーマンス問題も改善されてるっぽい。
個人的にはスレッドを実装してほしい。
基本的にどの言語でも eval はデメリットがでかいと思うけど。 スピードだけじゃなくて。
俺がeval使うのはclassを動的生成するときだけだな。 create_functionならぬcreate_classみたいな関数あればよかったんだけど。
460 :
459 :2006/03/07(火) 18:43:57 ID:???
あ,しまった,「ならぬ」か。失礼。
>>455 >生成したコードを eval するよりファイルに書き出して inlucde するほうが速いらしい。
これは後に確認したらそうでもなかったんじゃなかったかな
Zend Frameworkの話題が止んだのは、みんなもう飽きたからですね。
>>462 なにか話せるような素晴らしい展開があるのなら、喋ってもいいですよ?
>>458 $name = 'Test';
$hoge = new $name;
つーかインスタンスの生成じゃなくてクラスの生成の話ね。
>それだと継承を要求できない 意味不明。
>>469 $className = "ArbitraryName";
eval("class $className extends RequiredClass {}");
$instance = new $className();
いや、458=470なんだが・・・
>>462 とりあえずZend Frameworkを見て、Symfonyを使い続ける決心がつきました
>>426 Rails以前に、pradoとかもそうじゃん
>>473 まあ今の状態じゃコントローラの実装が中途半端だしフレームワークとしては使い物にならんわな。
俺はちゃんと整ってきたらいつでも移行できるように定期的にチェックしようとは思うけど。
>>441 たぶんZActiveRecordは未実装なのでは?
ZSearchとかZFormみたいなのはphpdocのapiにのってるし。
早速アップデートか Zend Framework Preview 0.1.2 なんか実装に文句ある香具師は早めにメールしといた方がいいんじゃねか?
>>477 実装に文句あるやつは使わなければ(ry
と書こうと思ったが、よく考えると
「zendがやってるものなんだから一番いいに決まっている」
などと無理やり使わされる可能性もあるんだよな
>>478 それで PHP の案件が増えた。
「流行ってるんだから PHP が一番良いに決まっている」
死ねばいいのに。
JavaのStrutsの話かい?
ぱっと見だけど SymfonyのTemplateって生PHPなん?
>>479 >「流行ってるんだから PHP が一番良いに決まっている」
本当にそんなアホな理由の案件なら断れよ。
共用サバみたいなとこでも高速である程度セキュリティが確保された状態で実行できる環境が、
他の言語にないからだろ。
>>478 つーか嫌でも使わざる得ない状況になる可能性は高いな
リソースもありそうだから今ならちゃんとした要望ならすぐ
受け入れてくれるだろうし
良い提案なら早めに入れてくれると使う方もありがたいし
今のところZFの文句ってないのかな?
>>487 正解。
こんな2chでしか文句言えない奴が、、、死ねば(ry
>>487 客がZF使えって言い出した場合の話しではなかったのか?
どちらにしてもZFが業界標準みたいになるんだろうよ
良かろうと悪かろうと
だから使うようになってから文句言うよりも早めにチェックして
文句言っておいた方がいいってこと
なんだかなぁ・・
491 :
nobodyさん :2006/03/09(木) 16:47:22 ID:??? BE:29920223-
仕事でPHPいじるってるひとって大変やね
>>ZF 個人的な小さな小さな事なんだが、、 クラス名とファイル名が微妙に違うのは、ソース読みにくいなぁ・・と思った いや、、それだけなんだが
>>492 え?クラス名とファイル名違うってどの部分?
だいたい一致してた気がするけどな。
むしろディレクトリ名が全部ひっついてて長ったらしい印象。
とりあえず、phpのデフォでしょ>クラス名とファイル名が微妙に違う
LAMPスタックのコンポーネントのなかでも、 人気の高いプログラミング言語(笑)であるPHPだけは、 バグ密度が基準より高かったと、Coverityは述べている。
>>489 >客がZF使えって言い出した場合の話しではなかったのか?
自分が仕切る側になれば、そんな客とらなくていいだろw
現状WEB開発の仕事なんて腐るほどあるし、そんな客から仕事貰う必要がどこにあるの?
>>496 PHPでのWeb開発の仕事って腐るほどあるか?
あっても金安くね?
自分が有能なふりして(あるいは本当に有能でかつ性格悪いかで) 話の前提を壊して話題を逸らす人って鬱陶しいですよね
どこからともなく精神論持ち出す人も鬱陶しいですよ
>>503 詳しくは知らないが、AliasMatchって使えんかな?
試してないでスマンが
AliasMatch ^/(action1|action2|action3) /var/www/html/$1/index.php
とか
いずれにせよ、スレ違い。
zendにもRailsのconfig/routes.rbみたいのあればいいのに
>>507 Zend_Controller_Router_Interface を継承してそういう Router クラスを
作って、置き換えたら?
Zend_Controller_Router は何で Zend_Controller_Router_Interface を
継承してないんだろう…。
ZF wikiとかZF ユーザ会とかできるかな?
ブログで見たんだけど Symfonyのヘルパーはグローバル関数らしいね。 グローバルをView用の空間に使うなんて大胆だけど ありっちゃありかもしれないなぁ 俺フレームワークでもそうしようかな…
(´・ω・`)しらんがな
DBから取ってきたコンテンツをサニタイズとか改行コードを<br />にする処理は どこでやってますか? ViewかActionかModelで迷ってます。
>>509 > Zend_Controller_Router は何で Zend_Controller_Router_Interface を
> 継承してないんだろう…。
それのせいで引数が渡せなくてフロントコントローラが動かないんだよね。
しかもメソッドの実装が両者で微妙にズレてるし。
無理やり書き換えたらいちおうアクションメソッドまで呼び出せたけど、やっぱりちゃんとドキュメントとか出てからにしようと思った。
>>513 サニタイズはDBに保存する前にやるのが普通。
nl2brはDBからとってきた後にやる設計でやってるならビューで。
> サニタイズはDBに保存する前にやるのが普通。 うそ? SQLのサニタイズは、SQL発行直前 HTMLのサニタイズは、出力前 というのが基本と思っていたけど... どっかに書いてなかったっけかな 後で調べてみる
>>516 あーサニタイズってそういう意味で言ってたのか。
で、HTMLの整形だとわかっててView以外でやる理由はどこにあるの?
519 :
nobodyさん :2006/03/10(金) 22:19:12 ID:fDWXlAX4
HTMLってサニタイズなんて言葉使ったっけ?
zend使うか自分で作るか悩むな〜
zend待つか・・・
お前らは「サニタイズ言うなキャンペーン」でも読め。
>>527 あれはどうしようもない素人が書いてるから無視
>>528 いま丁度読んでたんだけど
もし良ければ具体的な突っ込み所を知りたい
書いてることは大体間違って無いけど、書いてるコードがキモかったので俺は敬遠してる
>>528 の理由知りたい
>>531 確かにPHPは変な書き方してるよね
あまり使ったこと無いんだと思って変に納得した記憶があるけど・・・
言いたいことは分かるんだが、じゃあなんて置き換えればいいのか悩む セキュアプログラミングは当たり前だから言うこと自体がおかしい、といわれても 実際そういう処理がどこかにあるわけだし・・・
つか、あれは極端な例だろ? 本人だって、まさかあれをそのまま使わせるつもりはないだろうし。
>>533 良く読め、ちゃんと書いてある。
浩○に怒られるぜwww
eRuby の「h」はいいよね。
最近よくある [大タブ1][大タブ2][大タブ3] 小タブ1 小タブ2 小タブ3 こんなナビゲーション作る時(例:Appleのサイト)は、 大タブ用Actionと小タブ用Actionを、 コンテキスト用Actionからforwardするのが普通?
ZFのマニュアル読んでってるけど 分かりやすいね。 Mojavi系よりとっつきやすそうな印象。
ZFさらっと見た印象では フレームワーク内でも疎結合を目指してるんだね。 理解しやすい反面、とっちらかった感じもある。 他のフレームワークは PHPをラッピングしようとしてるけど ZFは生PHPそのままでいい部分はそのまま使おうという感じ。 フレームワーク固有の知識習得のハードルを 出来るだけ低くしておこうというのは、 戦略としてはアリと思う。
Mojavi系みたいに最終的にはZFをベースにしたフレームワークが出回りそうな感じだな。
え、MojaviってZFをベースにしてたの?
>>543 mojaviをベースにしたFWが何個も出たように
ZFをベースにしたFWが出回るってことじゃない?
Mojavi3やAgaviではActionChainがなくなったってホント? やっぱりいらない機能だから無くしたってことなのかね。
>>546 ほんと。 それぐらい自分で調べないでどうする
ActionChainの代替がDecorator
有限会社レアル
http://www.e-real.jp/ SE募集 Fedora Core + Apache + MySQL + PHP
自注の場合はクライアントに合わせる
勤務場所 ご自宅
雇用形態 正社員 アルバイト フリーランス 副業
WEBアプリケーション開発をしている会社で、簡単な資料を基に仕様書を作成し、翻訳家を通してセブのPGに作業させて、完成させる。
若い会社です。一緒に夢を追いかけませんか?
>549 転送メアドワロス(w
スレ違いもほどほどにして欲しいな、宣伝とか
>>552 require 失敗してるんじゃね?
>>554 のチュートリアルにもあるけど、 require 'Zend.php' して、
Zend::loadClass() する方がいいと思う。
>>554 公式にリンクあるのになんでわざわざ載せるの?
>>557 それ俺は楽しみにしてるんだけどいつ出来るのやら…
ZF、いまのところ複合View実現する方法が提示されてないね forwardとかdecoratorとか
ZFなんてキモくて流行りそうもねーな。
いじくってみたけど、そこまでキモイとは思わなかったな。 未完成って感じはするけど。
俺としてはなかなか好印象
モジュール+アクションとアクションのみってどっちがいいですか? 俺フレームワークではアクションのみでやっているんですけど、 モジュールもあった方が便利ですか?
用途によるだろ
用途っちゅーか規模によるな
アプリの規模と開発チームの規模の両方な モジュールでナントカ空間を分割するんでお互い干渉しませんなんてのも 実際には命名規則だけで普通に問題なかったりするんで あってもなくてもいいけどあった方が便利って程度じゃないかと思う
モジュールなんて概念はいらない。 hiddenでactionとmoduleの二つのパラメータを 持ちまわすのか?うぜぇ。 アクション名にいろいろな意味を持たせればいいじゃん。 ホントMojaviの作者はセンスねーよ。
>>567 へルパでどうにかすりゃいいじゃん。
ほんとセンスないねおまえw
パラメータ一つだろうが二つだろうが たいして変わらんやん 言ってる意味が分からん moduleがないと一つのディレクトリが Actionだらけになって視認性が低下するしな
例えば、訪問者用ページと管理者用ページ、とかだと、 いくら命名規則とかあっても、同じ名前空間にあるのはキモイ。 まぁ、サーバーごと別にする場合もあるだろうが。 でもそもそもモジュール名をhiddenとかで持ち歩く必要性は無いよな。 例えばSCRIPT_NAMEとか使って、 hoge.php にアクセスされたら define('MODULE_NAME', 'hoge') になるような設計でいい気がする。
つーかMojavi系でモジュール名やアクション名ってhiddenフィールドに入れるのが一般的なの? 普通にURIのクエリストリング中($_GET)かパス(mod_rewrite)に入れればいいだけの話だと思ってたけど。
>>570 でも結局は大抵は「同じファイルシステム空間にある」ってことになりそうだよ
action しかないフレームワークでも
hoge.php にアクセスされたら "hoge_{$action}" って action に行くようにすれば
やっぱ命名規則でどうにかなる問題な気がする
ものによって「別モジュールにすると何を分割できるか」が違うだろうから難しいけど
どうしてもモジュールが必要になるのってどんな場合なんだろう……
分割統治せよ。 mojaviなんぞなら、フィルタの適用を変えるとかいろいろ。
>>572 同意。actionの命名規則でどうにでもなるからmoduleなんか必要なし。
「モジュール」って考え方自体がそもそも必要性を求めるものじゃないよ。 理屈の上だけではたった一つのPHPファイルで全てを処理することも可能なわけだし。 俺はFWには普通にモジュールあったほうがわかりやすいし管理しやすいと思うけどね。 そんなに必要のなさが気になるなら使わなければいいし。 「命名規則でどうにでもなる」なんて、程度の差こそあれ「マシン語で何でもできる」と言っているのと同じようなもの。 こういうのは適材適所でいいよ。
hiddenに入れるってどういうこと? ページ遷移を必ずpostで行うのか?
moduleいらなかったら 全部Defaultにほうりこんでactionだけ使えばいい あって困るもんじゃない
でもmodule名は指定しないといけないだろ?
モジュール機能を提供してる大抵のフレームワークは モジュール名が指定されなかった時に デフォルトモジュールを決める手段を何かしら提供してるんじゃないかな?
>>578 それじゃ何のためのデフォルトだよw
省略された時に補完されるのがデフォルトの意義だろ
Mojaviでforwardするとき、 RequestParameterがパラメータコンテナに使われるみたいけど セキュリティー的にどうなんだろ? forward用のActionが外から直呼びされたりしたらヤバスな感じがするんだが
>>581 setAttribute/getAttributeを使うのでは?Mojavi2止まりなので間違っていたらごめんなさい。
583 :
582 :2006/03/23(木) 22:56:43 ID:???
補足。setAttributeで目印を付けてgetAttributeで確認するという意味です。
やっぱりそんな感じにするしかないかな 直接呼び出し禁じる設定メソッドがあればいいんだけど isSubAction?とか
>>584 アクションクラスにメソッドを準備すると仮定すると、アクションクラスがイ
ンスタンス化されるまでチェック不可能なので、Mojavi2なら
ExecutionFilterに手を入れる形になる。
それ以外の手としてはどこかに置いてある直接アクセス許可/禁止リストを
チェックするグローバルフィルタを準備することもできるかな。
>>581 forwardされたのか直接読まれたのかをRequestのパラメータmoduleとactionから判断すればよろしい。
589 :
nobodyさん :2006/03/25(土) 14:29:31 ID:89IwyN4m
590 :
nobodyさん :2006/03/26(日) 19:04:39 ID:CBEzlswa
みんな ZF いじってる?
>>590 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 を強制している(?)のもどうかと。
この間のwebcastではmod_rewriteには依存しないって言ってたのにどうなっちゃったのかね?>ZF
596 :
nobodyさん :2006/03/26(日) 23:06:30 ID:DeU9y+sO
>>595 フレームワーク全体は 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);
とかやればいいんでないかな。
しかしクラス名が長くて眩暈がするな。大したことやってないのに・・・
601 :
598 :2006/03/27(月) 12:04:29 ID:???
つーかサニタイズはdispatcherの仕事だな。 デフォルトのdispatcher使えば598のままで問題ないと思われ。
$module = @ $_REQUEST['module'] or $module = 'Default'; っていう書き方はじめて見た。 変数に値がない時の書き方が冗長になるなぁと ずっと思ってたんだよな。
@演算子は好きじゃないな。 書くならむしろこっちでは。 $module = isset($_REQUEST['module']) ? $_REQUEST['module'] : 'Default';
>>603 isset()で確認した変数をもう1回書くのが面倒なんだよねそれ
連想配列なら関数書けるんだけど、普通の変数は空だと引数に渡せないしなぁ
@は理解が深まると癖になる不思議な演算子。 まあそれ以前にPHPのorがboolしか返さないのがそもそもの難点なんだが・・・
まあもちついてくださいよ
いくつかのActionをChainさせた場合、 別々のActionからDBの同じデータにアクセスしてることあるじゃん。 いくつか方法はありそうだけど どうやって対処してる?
富豪プラグラミング
>>608 ただアクセスするだけならそのままでもいいし、データの書き込みに関してお互いの整合性が必要なら別口にDAO的なModel作ったらどう?
>608 agaviのSingletonModelとか、自前でSingletonするとか。 Actionに直接DBへのアクセス書くのはなんか抵抗があるな。
612 :
608 :2006/03/28(火) 14:59:45 ID:???
いや、DAOはSingletonなModelでActionの外においてるんだけど、 同じデータを取るのに複数回クエリ発行するのが気になったんだ。 そのへんはあまり気にしないが正解かな。
>>612 DAO 側でデータをキャッシュしておいて,
同じデータと判断できるような何かがあったらキャッシュを返すとか……
結局は DB アクセスとメモリキャッシュのどちらかでリソースを食うので
状況次第ではどちらも富豪的な発想ってことに.
oracle なんかだと RDBMS 側でもキャッシュしてるから
同じデータを触りに行くクエリとかだと連打しても大して負荷なかったりする場合も.
>>613 >oracle なんかだと RDBMS 側でもキャッシュしてるから
mysqlもね
MySQLのクエリキャッシュってMyISAMだけだよね?
>>615 MySQL 4.1.1 以降では、 InnoDB テーブルの使用時、クエリキャッシュはトランザクション内でも機能します
フレームワークつかわんでプログラムするとき おまいらはdaoとかつくりますか?
だおとフレームワークは独立概念だお
>>615 時代の流れに置いていかれないようにね。
「香具師がいた」とかどこの誰かと思ったら m-takagi.org って php-doc で名前よく見る高木氏じゃないか 心底から感謝を捧げたい!
おっ!いいね。 やっぱリファレンスが充実しなきゃ良いものも 広まらないからな。良いものかどうかは知らんが。
>>622 彼は結構いい仕事してるなー。他にも色々翻訳しているね。
で、ZF使ってる香具師いるの?
俺時間なくてまだ見ることもしてない...
まだプレビュー版だから本サイトで使ってる人は殆どいないんじゃない?
実運用のサイトを作るのに使う香具師はいないだろうが、ちょっといじって みたいって人はいるでしょ。というか使ってみたいんだけど、なかなか時間が まわりのツールが集まってくると面白いことになるんだろうけど ドキュメントは結構早く出てきてる感じがする サイトはまだかなー
>>628 「携帯用」って時点で話にならん。
基本的にPC用サイトも携帯用サイトも一つのフレームワークに収められるようにするのが基本。
基本というからには、他のすべてのフレームワークに、 日本の携帯に適したものが当然のごとく実装されてんのか? そいつは知らんかったな。
630みたいのは「汎用厨」とでも名づけましょうかね
う〜ん。。どっちもどっちジャマイカ?
PC 用には Smarty があるんだから ケータイ用に KEMP でいいと思うよ。
その二つを並べるのは変だろ KEMP って Smarty 使っているんじゃないの
>>631 拡張すればいいじゃん。
おまえはわざわざ別々のフレームワーク使うの?
・PC用、携帯用のどちらにも対応したフレームワーク ・PC用に特化したフレームワーク ・携帯用に特化したフレームワーク どれもあっていいと思うけどね。 そりゃどちらにも対応しててどちらに対しても最高の拡張性を備えてるなら文句ないけど、ないものねだりしても始まらない。
>>637 最高の拡張性なんて全く必要ないよ。既存のフレームワークでPC用も携帯用も作れる。
どっちもWEBアプリケーションで、作成に大した差もないのになぜ特化する必要があるの?
>>632 一生懸命作ったものを否定されちゃったら、そりゃ厨扱いもしたくなるよね。
携帯って独特の機能(端末IDを使った認証とか、絵文字とか、ユーザーエージェント毎の振り分けとか) があるから、それに特化したフレームワークがあっても面白いかと思う。 PC版と携帯版があるサイトとかだと、別々のフレームワークが必要になったりして 不便かもしれないけど。
641 :
637 :2006/04/02(日) 16:52:30 ID:???
>>638 俺自身は携帯向け自体作る気ないから別にほしいとは思わないしお前もいらないんだろうけど、欲しい人もいるんじゃないの?
特に携帯の機種依存な処理とかどれくらい面倒くさいのか知らないが、ぱっと見た感じフレームワーク的なものあったら便利になるんだろうとは思った。
別にお前が要らないと考えること自体に対して異論はないよ。
人それぞれだから。
mojavi を例に取ると、filter と renderer 書く方がスマートって気もする。
おいおい、何のためのフレームワークだよ。
>>642 の言うようにFilterとかちょこっといじれば
携帯用のフレームワークになるだろ。
ちょこっとですむならちょこっとで済ませたらいいんじゃないの。 適材適所だし。誰も咎めてはいないよ。
>>643 なんの話というか…、こうやって専用にしか使えないフレームワーク作るより、
汎用のフレームワークに対する、いわばプラグインって形で提供すれば、
使ってくれる人も多くなるし、うまく行けば流行るかもしれん。
と言う意味で、スマートじゃないかな、と思った。
どうかな?PHPのWebサイト全体に対するMojaviの使用率なんてそこまで高くないしな。 もし今後ZFが標準になったりとかすれば、プラグイン製作って考えも当たるかもね。 現時点では何とも言えないけど。
>>647 いや、別にmojavi は例として挙げただけだから、あまり気にしないでね。
少なくとも、携帯専用フレームワークよりは、mojavi でも何でも良いんで、
そこそこ知名度のあるフレームワークに寄生した方が、使う側にしても敷居が低くて良いと思うよ。
いや、携帯用のデファクトスタンダードに育て上げるんだ、
って意気込みでやるってんなら、それはそれで良いのかもしれんけど。
ま、個人的感想だと思って頂戴。
まあ俺の個人的な感想を言わせてもらえば、そっちのほうがいいと思うなら自分で作って公開してみたらどうだろう、と思うけどな。 どっちみちどうでもいい結論しか出なさそう。
携帯サイトは、絵文字対応とか端末IDの取得など、PC用サイトとはかなり違う構成になる。 それ専用のフレームワークは十分需要があるよ。 絵文字ライブラリだけでも売り物になるんだから。
あ、もちろん、個人で勝手サイト作る分には、どうにでも適当に作ればいいけど。
>>650 だからその処理をFilterに入れるんだろうよ。
だいたい携帯でもPCでも見れるようなサイトを作る場合
わざわざフレームワークを分けるわけ?
その技術を世に公開するならSmartyやMojaviなどの
プラグインにした方がマシだと思う。
携帯サイトのコンテンツとPCサイトのコンテンツはまったく違ったものにならざるを得ない。 まあ、公式サイトを作ったことあるやつならすぐわかる話。
>>653 多感な年頃ですね。
どうせMojavi専用+携帯専用プラグインなんて出てきたらまた文句言いたくなっちゃうんでしょ?
>>654 おれもこないだまでは
「MVCきちんと分離しとけばVだけ変更して携帯サイトできあがり〜」とか思ってたんだが
仕事で公式やったら
>>650 の通りで、
>>630 なんてのは空論に過ぎねーと思い知った
ていうかもう携帯の仕事はやりたくなくなったw
>>656 それにしたってわざわざフレームワークを分ける必要は無くね?
えーと、後に引けなくなっちゃったのかな?
>>657 653のやり方に反対しているわけじゃないんだ
同じフレームワーク(以下FW)上で656に書いたみたいな大きな違いまで吸収できるならそれでいい
ただ実際、特化FWの代わりができるほどに「こなれた」汎用FWは見たことがない
654も言うとおり、実際「まったく違った」サイトにせざるを得んのだから、
それなら携帯の方は分けて考えて特化FWで作っても問題になりにくいだろうな、ってこと
もちろんFWの学習曲線を2回登らないといけないとかのデメリットも忘れてるわけじゃない
でも携帯サイトの不自然な制約はそれすら凌駕するくらいだと思うってこと
(これは個人的意見だしどこまで対応しなきゃならないかっていう要件にもよると思う)
>>659 mojavi使える?他のフレームワークでも構わない。
filterとrendererで対応できないのって、どの辺?
別に煽ってるとかじゃないよ、携帯コンテンツとか作ったこと無いから、知的好奇心。
携帯の開発はNDAがあるから、あんまり喋れない。 だから、ウェブの資料とかあんまりない。 CP剥奪とかなったらシャレにならない。 まあ、携帯の開発って、フレームワークを適用できる部分が多いと思うよ。 PCのサイトなんかよりずっと。
>>661 どーせ大した情報も持ってないんだろ?
携帯サイトごときでフレームワーク変えるようなアホに
何も聞くことねーよ雑魚。
>>662 良く知らないことを"ごとき"と評価できる貴方は素晴らしい。
このスレらしからぬ荒れ方をしているな 春休みって奴か
>>630 ,636,638,644,653,657,662
春具合テラワロスwww
>662 が携帯の特殊性についての、どのような情報に 基づいて、携帯専用のフレームワークは不要と判断 しているのかを知りたい。
>>660 結論言えばfilter/pluginやrenderer/decoratorでもやればできる。
さらに言えばフレームワーク使わなくてもやればできる。
さらに言えばPHP使わなくても(ry
作ろうとしているサイトの規模に応じて適切なものを検討してね。
あとはご勝手に、と
サイトの作りによるからなぁ 携帯独自のコンテンツを提供するサイトだったら 専用フレームワークが必要十分だろうけど、 両方提供する場合は専用だと嬉しくない ただまぁ、現状の一般のフレームワークでは 携帯の邪魔くさい部分に対応しきれないのは 間違いないので、携帯向けフィルタ集みたいな ものもあったらいいね
携帯だと、課金方法とかもある程度決まっているから その辺の処理とかもフレームワーク側で便利にこなしてくれるといいんじゃない? いらないいらないって叩くやつからは何も生まれてこないので、どっちかというと 作って公開してくれる人を大切にしたい。
>>656 わかるー!おれも「viewを変えるだけでいいだろ」と思ってたけど、技術的な制約が全然違うから、作り方も別にならざるを得なくて、すごい苦労した。
なんかね、パソコン向けと携帯向けって、使っているのがHTML(とそのサブセット)というぐらいしか共通点ってないんじゃないかと思った。
GET/POSTとかないし、クッキーないし、URLの文字数に厳しい制限あるし、CSSやJavaScriptないし、Sessionはれなかったりするし、認証方式まるで違うし、そのくせ情報少ないし、これでどうやって作れっての?と思った。
もうフルブラウザしかサポートしませんといいたかったよ。
>>659 >でも携帯サイトの不自然な制約はそれすら凌駕するくらいだと思うってこと
はげどー!誰が考えたんだよ、あんな仕様・・・特にi-mode。
>>653 FilterやPluginで対応できる・・・そう思ってたときが自分にもありました。
最初から携帯も視野にいれて設計されたフレームワークならともかく、そうじゃないフレームワークではFilterごときでは対応できなくて、Controllerにも手をいれないと難しい。
「MojaviにFilterいれればクラサバアプリが作れる」というのと同じようなもん。
>>670 GET/POSTとかがないってどゆ意味?
>>670 実際のブラウザシェアをキャリアが公開してくれると
嬉しいんだよな。例えばこれこれのスペックの端末が
これくらいのペースで減ってるからこの時点で非対応
に、とか判断できる。
この辺は新規開発じゃまったく情報ないから
古い仕様に合わせるってことになるわけだけど、
そうすると制約だらけで何もできないに等しく
なっちゃうんだよな。
実際には 3G じゃなくても PDC の後期の機械は
結構ハイスペックなんで、いろんなことできる。
これは仕様外の端末独自のものだけじゃなくて
仕様上も結構制約緩くなってたりする。
どうでもいいけどキャリアは端末情報をすべて XML で
提供してくれんかな。PDF じゃ全然使えねーよ。
673 :
659 :2006/04/03(月) 13:08:34 ID:???
ごめん,めっさ長文になっちった
>>660 FilterやらRendererやらで対応は,原理的にはそりゃ何だってできるだろうけど.
あるUAには複数画面に分割したHTMLフォームで入力は932+携帯独自コード,
別のUAにはFlash読ませてエラーもFlash生成して返しますよ,なんてのは
実質的に単なる別プログラムでしょう.
あるいは認証とかで,古い端末はセッションIDをURLにくっつけてください,
でもブックマークしてもらうページにはつけちゃダメだからhiddenで渡してください,
あぁでもCookie使える新しい端末は逆にCookie以外は禁止してください,とか.
個別に考えれば「こうすればいいじゃん」とか浮かぶだろうけど,
つまりは対応できないってのではなく,汎用FWの機能内で無理して対応するより
特化FWで支援機能バリバリで対応した方が
コードの見通しもメンテ性も良いだろうなって話だわ.
まぁ「お前の設計が糞」とか言われりゃそれまでなのだが.
>>670 同志がいてくれて嬉しいw
>>673 そそ、可能か不可能かといわれれば、可能。
でも、事実上不可能。
単なるフォーム入力画面でも、PCなら一画面ですむのが携帯だとHTML最大サイズが小さいから複数画面にしなきゃいけなかったりとか、
その最大サイズも端末ごとに違うから端末ごとに画面数が違うとか、
そもそもキャリアごと・端末ごとに使えるタグが違うとか。
画面数が変わるとVだけでなくCもかわるし、入力データのバリデーションもやり方が変わってくる。別の画面で入力されたデータとあわせてチェックしなきゃいけないとか。
おれの場合、共通化できたのはMだけだった。
ちょっとスレ違いになってすまんかった。でもこのスレはフレームワーク設計者もみてると思うから、携帯対応も考慮してくれるとうれしい。
それは、そもそも、フレームワークになんて、ならんのでは無いのか? としか思えん。
>>675 理由や具体例を述べよ。
それだけじゃ主張したいことが全然伝わらない。
独り言だったらチラシの裏に書くように。
>>673 >つまりは対応できないってのではなく,汎用FWの機能内で無理して対応するより
>特化FWで支援機能バリバリで対応した方が
>コードの見通しもメンテ性も良いだろうなって話だわ.
なんで汎用だと「無理して対応」になるの?なんで特化だと「バリバリ対応」になるの?
君の上げている理由じゃぁ普通のWEBフレームワークに普通に突っ込めるじゃん。
むしろPCと携帯でVIEWだけ分けてロジック共通にしたい時なんて、特化フレームワーク
なんて使ってたら偉い手間。
>>677 なんでループさせるの?
特化してるのも汎用の拡張もやりたいように
やればいいじゃん。
作ることそのものを否定する必要はあるまい。
専用のものから汎用のものへインポート
できるかもしれないんだし。成果が誰かを
幸せにすりゃそんでいいんだよ。もちろん
まず最初に自己満足を満たすのも大事。
>>677 > 君の上げている理由じゃぁ普通のWEBフレームワークに普通に突っ込めるじゃん。
↓
> 個別に考えれば「こうすればいいじゃん」とか浮かぶだろうけど,
> なんで汎用だと「無理して対応」になるの?なんで特化だと「バリバリ対応」になるの?
なんで?って……ならない理由がわからないんだが.
すごく簡単な喩え話でいうとさ,mb_send_mail()が使える環境と使えない環境で,
日本語のたいていのMUAで正常に読めるように日本語メールを送るのはどっちが楽よ?って話.
結論から言うと、俺はMojavi3で商用携帯サイト作った。 当然、対応させるためにフィルタやらViewやらなんやらを作ったし、 キャリアごとに異なる認証機構もフレームワーク内で収まるようにした。 具体的な方法はいえないが。 もちろん、専用フレームワークをきちっとした形で作り上げてくれるのなら大変ありがたいよ。
だからーそのごちゃごちゃした携帯専用の処理を Filterに突っ込めって行ってんだよ! そんなこともで出来ねーならプログラマなんか辞めちまえよ!
だからー小規模ならそれでも構わないって行ってんだよ! そんなことも理解できないなら人間なんか辞めちまえよ!
人のやり方に過剰にケチ付ける意味が分からん 色んな意見参考にして自分に取り入れていったらええやん もともとそういうスレだし
>>681 お前はPHPもApacheも使わずに、とっても便利で何でもできちゃうアセンブラでHTTPデーモン書いて携帯サイト作ってやっとけ。
そんなこともできねえならプログラミングやめろ。
どうせなら、OSからつくろうぜ。
まあ、公式サイト作ったことあれば、どういうことだかすぐに分かるよ。
filterでできると言ってるやつが、それを作って公開してくれればよいと思いました。 2chで叩いてる奴より形にして公開してるやつの方が100倍えらい。
>>685 OS作るの?ご苦労さん。
俺だったらウェブサイト作るためだけにOS作るなどというばかげたことはやらずに、普通に既存のプラットフォームを使うけど。
じゃあ俺はCPUから作りゅ
作れば。トランジスタでもシリコン基盤でも何でも勝手にどうぞ。 スレ違いだからもう来なくていいよ。
とりあえず携帯用フレームワークなんてイラネ
だったら喪前が使わなければいいだけだろ。 他人の自由を制約する必要は一切なし。
>>692 はいはい、携帯用フレームワークは不必要だね、無意味だね、馬鹿だね、ウンコだね、チン毛だね。
誰かにそう同意してもらえるまで駄々こねるだけの甘えん坊さんは(゚听)イラネ
一行レスによくこんな食いつくよなぁ
で?
そうだね。これ以上粘着されると困るからな。
最近スレの伸びがいいようだから、期待して久々に来てみたら、、、
>>670 辺りの一連の話、参考になるなー。てか携帯って大変なんだね。
携帯電話はバッドノウハウの巣窟。 だからフレームワークがあると助かるよ。KEMP 期待してる。 そしていい所は俺フレームワークに取り込んで フリーライドさせてもらうよ。
>>701 それを取り込んだ「俺フレームワーク」を公開してくれたら幸せになれる人が多いのではないか
例えばおれとか
>>702 もう間に合ってますのでこれ以上オナニーフレームワークを
世に垂れ流さないでもらえません?
今一番モリ上がってるスレはここですか?違いますか? 本当にありがとうございました。
>>703 おまいさんに使ってくれとは誰も強要してないが何か嫌なことでもあったのかな?
KEMP 以外のケータイ・フレームワークってあるの?
>>708 ありがと!
む、2003-12-08 で更新が終わってるのか。
どういたましてし
mojavi2で携帯サイト対応しようと思っていたので、なかなか勉強になった やっぱmojavi2で携帯に対応するより、専用FW使った方が工数が低くなりそうだ 公式でなく勝手サイトだけど、そう思う。 勝手サイトでなく公式サイト作ればわかるってのは、どの辺を言ってるの? 課金がらみのセキュリティとか認証とか?
>>711 一番面倒なのは、「300円払ってるのに見られネェゾ!」って
言ってくるユーザーの対応。
>>712 絶対落ちないようにしないといけないから大変だよね
そのへんの荷が重いから有料コンテンツにはなかなか手を出せない
携帯向け開発の話だけで十分話題が成り立つような気がするんだけど、 専用のスレってないの?
そのKEMPとかいうFWをごっそりパクって Mojaviのプラグインにしたら怒るかなw
こっそりパクって発表しないんなら好きにやればいいじゃないの
Mojavi On Mobileとして公開するつもりなんだけど。
AgaviやSymfonyもMojaviを堂々とパクってる。 好きにしなさい。 どうせできやしないでしょ。
今更mojaviの作ってもねぇ。誰も使わんでしょ。
とりあえず俺は使うぞ!!
mojavi2 or 3 or 4をベースにするの? というかプラグインってどのバージョンでも問題なく動くようにできるのかな? 私も期待しております。
期待しても無駄だろうね。 作る前から何か作るとか言ってる場合、口だけな厨か途中で投げ出すケースが圧倒的に多い。
それなんてtadashi?
ゴールデンウィークを過ぎるまでこの調子なのか。。。
パクルのは無理ってことか? じゃあ、一から作るとして携帯用のフィルタでどんな機能が欲しい?
とりあえずethnaで色々作ってるけど、 Ruby on Rails本読むと、もっと頑張って欲しいなぁ〜って思った。
Zend FrameworkってPEARと同じような位置づけになりそうだよね。 結局使われるのはPEAR DBよりADODB、DB_DataObjectよりPropelみたいな。
mojavi2使っています。 みなさんは画像のアップロードは、どうしていますか? HTML_QuickFormを利用しようかと思ったのですが、利用を推奨していないようなので…
$_FILES
cakeって何がまずいの?便利に使わせて貰ってるんだけど。。
StrutsはView=Templateで、MojaviはViewとテンプレートが 切り離されてるんだけど、これってどっちがMVCとして正しいのかな?
MojaviでもテンプレートはViewの一部でしょ。 そういう意味ではどちらも間違っているということはないと思う。 Viewクラスはプレゼンテーションロジックの中でテンプレート上ではやりづらい部分を書くために用意されているだけの話で。
どっちでもいいと思う テンプレートだけでViewを完結させようとすると どうしても、制御文入りのテンプレートになってしまうからね
MojaviのViewはViewHelperパターンってこと?
そう考えるのも悪くないかもね
ViewHelperはテンプレートから動的に呼び出されるロジックだけど、MojaviのViewに書くプレゼンテーションロジックはテンプレートが呼び出される前に実行される点が違うんじゃないか?
Viewがおのれ自身をtemplateにassignしたら、 ヘルパーになるよ。 おれはthisという名前でassignして {$this->hoge()} で呼んだりしてる。
>>745 Viewの中で$smarty->assign('this', $this);ってこと?
おもしろいやり方だな。俺もやってみようかな。
まあthisに限らず、smartyで言えばregister_functionやregister_modifierでViewのメソッドを登録しとけばばヘルパーになるね。
つーか、register_function自体がヘルパーを登録するものか・・・
zendはいつになったら完成するんですか!!!
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使ってるのかな。
750>> 書き忘れ。 $db = sfContext::getInstance()->getDatabaseConnection('pdo');
symfonyって ContextをgetContextじゃなくて sfContext::getInstance()で取得してんの? 確かにそれだと、各主要インスタンスにcontext渡さなくていいから 便利っちゃ便利そうだな
>>752 フレームワーク1年生のヘタレなので分かりませぬ。
普通はgetContextを使うんでつか?
>>750 訂正:
PDOの場合のdsnは
mysql:host=localhost;dbname=ccc
でした。スマソ
しかし、DBから引いたデータは文字化けする模様。
>>747 Preview 0.1.2で止まってますね。
Zendよ、早くしてオクレ兄さん。
情報少ないんでezpdoは分からないけど、 O/Rマッピングにはあまり魅力を感じないんです。<オイラだけ? $this->getContext()でもいけるんですね。 もう少し勉強してみます。
久しぶりに行ったらmojavi.orgダウンしてやんの。 少なくても二日前かららしい。完全終了ですかね。
も、Mojavi兄さん… 金が尽きたのか?
mojaviはもういいzendを出せ!
前スレの初めのほうでやってた寄付金は返ってくるの?
合掌
4/10の23時頃には見れてた。 ブラウザに表示したままPCを休止状態にしたりして、 2日前くらいに次のページを見ようとしてリンクをクリックしたら、 しばし待つのだぞのページになった。。。
リニューアルするまで待ってね、と言っているのだから まあ待とうじゃないか。
>>762 往年のジャンプ漫画の「第二部を楽しみにしてくださいね」に思える俺は、ひねたやつなんだろう。
欧米のフレームワーク関連サイトで出てくる scaffoldingてどゆ意味? excite翻訳で調べたら「足場」って意味わがんね
scaffoldingって、テンプレ作成のことじゃない? symfonyだと、symfony init-appとかのコマンドでいくつかファイルをまとめて作ってくれるし。
日本語でいったら……「雛形」とかか? 雛形を(大抵は自動的に)生成したりするのを scaffolding というような気がする
なるほど!thanks!
どういたまして♪
symfony触ってみたけど最強じゃんこれ? 今まで俺フレームワークで来たけどレベルが違うわ…
>>769 好き好きだけど、Templateが生PHPなのが、ちと気に掛かる。
>>770 PHPそのままをtemplateにすると、どんな不都合があるんでしょうか。
おれてきには、Smartyとか使われるとまた覚える量が増えてしまうし、SmartyでやってることはPHPでもできてしまうので、
templateにPHPを使った場合の不都合を教えてください。またはSmartyを積極的に使う利点。
誰か asp_tags = on にしてる兵はいないのか? てか、まだそのオプションあるのか?
Mojavi系ではsymfonyが圧倒的だから もうM4は出ない予感。 Zend V.S. symfonyって感じに収斂していきそう。
PHP5の案件が少ないのですけど… なんで? おれも、synfony を使って見たいよ
>>736 ModelがmySQL前提だからとか、マニュアルがいつまでたってもいまいちとか、
RCになってから大きな変更をホイホイ加えるとか、そういうことじゃないかな。
折角Dboを苦労してAdo-mssqlでまともに動くようにしたのに、インターフェイスが
変わってもう新しいバージョンでは使えないよ...orz
ただ、開発は遅くないと思う。でも本格的に使うなら正式リリース後がいいと思う。
あとはRailsの劣化コピーってのに我慢できるかどうか。
>>774 symfonyって、漢字でUTF-8以外の、EUCとかSJISの文字コード使えるの?
UTF-8しか使えないとなると、国産も生き残るものがある様な気がする。
まあ、AJAXとかしだすと、UTF-8にせざるを得ないケースが多いんだけど。
smartyいらいんよね。遅くなるだけ。覚えることが増えるだけ。
ethnaってmojavi2とどの位互換性がありますか? mojavi2がPHP5で使えないので、module以下を移せば使えるかなぁと思いまして…
>>779 そもそもが別物だから
コードレベルの互換性はないと思う…
概念レベルならフレームワークはだいたい似通っているけど
>>778 Smartyの実行速度や、覚えることが増える事を気にする人が、
フレームワークを導入しようと考える事が信じられない。
>>778 smartyの覚えることよりphpの覚えることのほうが100倍多いわな。
やっぱ生が一番だよな
short_tagなんて、それを使うことが問題になるケースもあるってだけ。 sedで置換しても数秒で終わる話。 まったく本質じゃない。 SmartyというのはJSPにあこがれた、そんな時代もあったねということ。 実際、すでにンプレートエンジンは使わないという流れが出来てるじゃないか。
フレームワークは、多くの人が使えないと意味がない。 フレームワークを採用することで、経験の少ないPGにも一定の品質を強いることができる。 無駄に覚えることを増やす理由はどこにもないということ。
> 実際、すでにンプレートエンジンは使わないという流れが出来てるじゃないか。 はつみみです。 そういうことにしたいのですね?:)
voidたんナツカシス Smarty は,ちょっとHTMLコーダがやっちゃっただけでもすぐ PHP エラー吐くのが 気に入らないといえなくもない テンプレート側の誤記に関してはもーちっと堅くあってほしいね
Smartyの遅さは異常
>>785 > 実際、すでにンプレートエンジンは使わないという流れが出来てるじゃないか。
どの辺を根拠にしているのか、具体例を挙げてもらえると分かり易いですね。
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
で直りますた。
O/Rマッパと分散DBの両立させてる人いる? こういうのってO/Rマッパの上に一層かぶせるんかな。
>>791 横からレスするけど...
Symphony,Cakeはじめ、Railsの影響を受けた後発のフレームワークは
テンプレートエンジンを備えてないか、デフォルトで無効になってる奴が多いよ。調べてみ。
Railsの作者もはっきりeruby以外のテンプレートエンジンは
Railsには不要と言っていたような気がする。
ま、これはRailsっていう流行の影響なわけで、
>>785 のように
テンプレートエンジンを使わん流れと見なすのには解釈が分かれるとこかもしれないが。
795 :
nobodyさん :2006/04/16(日) 19:24:48 ID:LCwI0Ihf
SMARTYは面倒で遅い。 面倒だけど速い。楽だけど遅い。これなら検討するが、SMARTYは考えるまでもない。
たしかにSmartyは時代のあだ花くさいな。 流れを見ていると。
デザイナに対して、アプリケーションロジックを壊させない、サーバーリソースに無闇にアクセスさせない、などの環境が楽に作れることが利点になるなら積極的に使ったらいいんじゃないか? サイトの規模とかプロジェクトメンバーの人数とレベルなど色々検討して利点にならないと判断できるなら使わなければいいだけだし。 あとsmartyのラッパクラスをそのままViewにすることもできるし、デコレータやレンダラに組み込むのも容易にできるような仕組みになってる。 ヘルパーを拡張する機能(register_functionやregister_modifier)もちゃんとある。 だいたい<?php echoが頻出するソースよりテンプレートのほうがずっと見やすいしレイアウトの編集しやすいよ。 実際にはコンパイル結果はPHPのコードをキャッシュしててincludeするだけだから、生PHPと比べて極端に速度が落ちることは考えられない。 むしろ体感速度として遅くはない。
railsは、<% %> だっけ? phpもasp形式のショートタグをデフォルト推奨にしてくれたらいいのに。どうだろう?
Smartyそのものの是非は割とどうでもよく、 今現在WEBデザインの効率を考える上で どのような手法がホットなのか、 Smartyからどこへシフトしているのかが知りたい
phpなら生で
まあsmarty不必要論自体に関してはこれ以上議論の余地はなさそうだしな。 phpタグはxml宣言とかぶって仕方なく「<?php」にした歴史があるから、どうも記述形式が宙ぶらりんなんだよな。 「<?=」が使えたらかなりすっきりするとは思う。 でもこれもまた「<? echo」のショートカットであると定義されてしまっていて、short_open_tagの一種なのでどうにもならない。
<% %> もうにしちゃえばいいのに
>>802 zendが移植性を意識しすぎてる間は無理でしょ。
しかもphp6では<% %>は廃止という噂も。
サイト見てたらsymfonyもAction=メソッドじゃん? Zendもそうだし。こういうの流行ってるのかな? guessworkもそうだね。
>>797 アプリケーションロジックを壊させないっていっても、どうせデザイナが
信用できない以上、コードチェックとテストはしなきゃいけないから手間は一緒じゃないかな?
オープンタグだけが問題ならそれこそrails風に h() という関数とか書けば?
あった方が好ましいとか、簡単に組み込めるからくらいの理由で余計なレイヤーを
追加するのはいやだな。
そういうのはどうしても無きゃダメっていうときだけ積極的になるべきじゃないか。
>>805 なんか言いがかりっぽいけど・・・
> アプリケーションロジックを壊させないっていっても、どうせデザイナが
> 信用できない以上、コードチェックとテストはしなきゃいけないから手間は一緒じゃないかな?
ぜんぜん一緒じゃないよ。smartyでヘンなことしようとしてたらくっきりわかるよ。
少なくとも不意に介入してしまう危険性の方は減るでしょ。
> オープンタグだけが問題ならそれこそrails風に h() という関数とか書けば?
<?php h($var) ?>って<?php echo $var ?>とほとんど変わんないじゃん。
{$var}と比べてごらんなさい。このすっきり具合。
> あった方が好ましいとか、簡単に組み込めるからくらいの理由で余計なレイヤーを
> 追加するのはいやだな。
> そういうのはどうしても無きゃダメっていうときだけ積極的になるべきじゃないか。
なんじゃそりゃ。フレームワークって楽するために余計なレイヤーをはさむものでしょ。
まあ好き好きなんだろうけど。
>>806 > <?php h($var) ?>って<?php echo $var ?>とほとんど変わんないじゃん。
> {$var}と比べてごらんなさい。このすっきり具合。
普通の知能があるなら、どれも全部変わらないよ。
ウェブデザイナをバカにしすぎ。
それに<?=$var?>でもいいじゃん。
XML宣言したいんだったら、その部分だけoutput buffering処理で付け足せばいい。
> なんじゃそりゃ。フレームワークって楽するために余計なレイヤーをはさむものでしょ。 他の部分はともかくここにはとても同意 余計なレイヤを挟みたくないなら素の PHP で書けばいいしね
>>807 > 普通の知能があるなら、どれも全部変わらないよ。
修正子が入ると、見易さの差が大きくなって来る気がする。
{$var|escape}の代わりの<?=esc($var)?>ってラッパーを書けばいいってこと。 {$var|escape:"url"}と<?=urlesc($var)?>、どちらが簡潔か? プログラマーにとっても、カスタム修正子作るより関数作る方が簡単だし、柔軟なものが作れる。 当然関数の方が処理速度も速い。
<% %>がデフォルトで使えるようになってくれたらいいのになぁ。
>>810 カスタム修正子より関数の方が簡単って、register_modifierのたった一文を書くか書かないかの違いだけだし。
あと処理速度は変わらんて。同じphpコードに変換されるんだから。コンパイル済みのコード見てみ。
そろそろ「単に言い張ってるだけ」になってまいりました この話題たぶんずっとループだからやめにしない?
Railsの作者は「<% %>じゃテンプレートのプレビューができないじゃマイカ」という 声に対して、「Railsは動作確認のためにセットアップするのが簡単だから、デザイナー にもRailsの動く環境を用意してあげて、そこでプレビューさせればいいじゃない」という スタンスなんだけど(別途Webサーバを用意する必要がない)、SymfonyとかCakeは そのあたりどうパクるつもりだろう。
>>810 {$var|escape|nl2br} は?
修正子にパラメータが付いたときの表記は、確かに冗長だけど、
変数の後ろに処理を記述する方法は、直感的に理解し易い表記
方法だと思う。
>>813 確かに、宗教論争っぽくなって来ている。
>>807 >普通の知能があるなら、どれも全部変わらないよ。
>ウェブデザイナをバカにしすぎ。
この人はできるウェブデザイナとしか仕事したこと無いんだろうね。
(この「できる」は「普通にできる」の範囲で)
もうどうしようもないの居るから。本当に。しかもかなりの確率で。
<?って入った時点で思考停止させるやつとか。
でも仕事は終わらせないとダメだからさ。
俺らにとって変わらないと思うくらいのことでもすり寄ってあげないとダメなんさ。
ここでのsmarty不要論ってのは、smartyが異常に遅いという前提があると思うんだけど、 私の経験と、この前提は一致しない。(ベンチとった訳ではないけど) レイヤー増えるんだから、早くなることはありえないけど、通常は十分な速度が出ていると 思うんだけど、どうだろう? FW入れるという前提があって、そこで使うテンプレートが生PHPで記述するタイプと、 smartyを使って、初回起動時にsmartyが生成したphpを使うのと、速度的に、どの程度 の差があるのか比較した場合、実質的に差が無いのではないかと言う気がする。
>>814 デザイナーは、スペックの高いマシン使っていることが多いから、
XAMPPとsandbox入れてあげればOKとか?
>>817 速度の差がないなら、なぜSmartyを推すの?
どうもsmarty擁護論の前提はデザイナとの連携みたいだけど、
デザイナとの連携が必要ない場合のメリットていうと
(例えば、見本ページが全ページ用意されていて、そこにデータを
流し込むだけとか、デザインはどうでも良いという客とか)
見やすい以外になにかあるのかな?
#◯◯は必要ありませんからその分安くしてください
#っていう客の是非はこの際おいといて...
patTemplateてのはどうなん?
>>819 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>
# # 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)
ちなみにSmartyのescapeはださいと思う。 もっと短くして欲しいし、もっといえば デフォルトでエスケープされるようにして欲しい。
おまけ s.php(キャッシュなし) Requests per second: 52.26 [#/sec] (mean)
>>826 デフォルトでescapeの設定はできたんじゃなかったっけ?
フレームワークスレで、not_s.phpみたいなコード見るとは思わなかった。 こんな竹槍戦法じゃ仕事にならないから、速度を犠牲にしてでもFW使う訳で・・・。 中のコードが、もう少し現実的な分量になっただけでも、差はかなり縮まる。
速度差10倍超
とうとうこんなくそコードまで出してベンチ取り出す始末 単なる意地の張り合い(というか否定派だけか意地張ってるのは)になってるから もうやめろってのに
832 :
nobodyさん :2006/04/17(月) 17:15:06 ID:r0ZxVhnD
まあグラフィックボードが速くても、CPUが遅ければシステム全体の処理は速くならない。 しかし、高い金を払って遅いビデオボードを買うのは不思議な行為だな。
俺はsmartyに最初にケチつけた書き込みを見た瞬間に頭の弱い子のレスなのだと悟ったよ。 まさかここまで再確認させてくれるとは思わなかった(唖然)
>>832 マトモな会話をしたいならたとえ話は話が発散するだけだからやめた方がいいぞ
ぜったい「例えが違う、それを言うなら……」って奴が出てきて話がそれるから
マトモな会話をしたくないならチラシの裏とかへどぞー
>>823-825 そんな小規模なサイトしか作れないなら確かにSmartyは不要だねw
いちおう同意してやったが、うれしいか?
836 :
776 :2006/04/17(月) 19:10:11 ID:???
>>776 なんだけど...
ちょっとフォローしとくと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は生のPHPに比べて劇的に遅いというのは事実だから。 CPUやディスクが遅ければグラフィックボードが速くても全体のパフォーマンスが上がらないというのは事実だが、 そのグラフィックボードが遅いという事実を否定するものでもない。
例えば、Perlの場合、低機能だけど軽いH::Tと高機能だけど重いTT、どちらを使うかはケースバイケース。 はてなやmixiは組み合わせて使ってる。 しかし、smartyの場合どうか? smartyのメリットを挙げれば、 ・<?=h($var)?>より{$var|escape}の方が見やすい(と感じる) ・smartyの文法は知ってるけど、PHPの文法は知らないウェブデザイナが担当の場合 これくらいか。 デメリットは、 ・10倍の遅さ ・smartyの学習コスト ・smartyの文法から来る柔軟性の制限 これでどちらがいいか選べばいい。 はっきり言って自明と思うけど。
>>841 >はっきり言って自明と思うけど。
じゃあ何でそんなたいしたメリットが無くデメリットが多いにも関わらず
楽天は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を採用した積極的な理由というのを教えていただきたいです。お願い。
同じ人かな? 別に俺はそこまでSmartyをこき下ろすつもりはなかったんだが…
>>843 >・テンプレートエンジンを使ってるオレってカッコいい。
オレって?君は一人で開発してるの?
遅さが嫌なら Smartyとほぼ同様の機能で速度は数倍のSimplateがあるよ。 だから結局どっちでもいい、と思う。
前にテンプレートエンジンのスレにも Smarty のみならず PHP でテンプレートエンジンを 使うこと自体を断固として否定する人いたよね。
>>844 >例えばJavaのMayaaだとテンプレートのHTMLデザインがまったく崩れないという特徴があるんですが、
ならphptalとか使えば
なんか数年前のMLのログでも見かけたんだけど 同じ人だったらある意味すげぇ
>>844 >それを考えても、なんでSmartyを選ぶのかがわからないので、Smarty(だけじゃないくて他のテンプレートエンジン)を選んでいる人に、Smartyを採用した積極的な理由というのを教えていただきたいです。お願い。
俺ただの傍観者だけど、誰も844の問いには真正面から答えないの?
>>851 そこのMLの人も、インチキくさいベンチ結果で遅いとか言ってたの?
じゃあSmartyを使う理由は 「特に意味は無いけどカッコイイから」 ってことでOK?
>>849 Smartyを使う理由を聞いているんだから、phptalだしても意味ない
で、Smartyの利点って何?
>>844 echo まわりだけとはいえテンプレートの機能使用のほとんどはそこなんだから
それだけでも大きく違うと思うけど……
生PHPではちょっといじるだけですぐにPHPエラーとか吐くようになってしまうから,
それをいじる非プログラマから見て心理的抵抗感が大きい……とかー
Smarty はテンプレートの変更で致命的エラーを起こせるので個人的にはちょっとイマイチ.
生PHPでは出力する変数をグローバルに置いたりするので名前空間汚染が嫌,とかー
Smarty の場合でいうと,デフォルト変数修飾子で出力値の自由な加工をする枠組みを用意してある,とかー
> Smartyでできることは、同じようにPHPでもできる。
Smarty は PHP で書かれてるんだから,そりゃできなきゃ困るw
フレームワークってそういうものでしょ.
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ディレクトリをコピーしたけど…。 なんか納得(´・ω・)イカナス
>>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 で書かれてるんだから,そりゃできなきゃ困るw
SmartyでできることはPHPでもできる。だからわざわざSmartyを使う理由は何?ってことだろ。
SmartyはPHPで書かれているうんぬんは回答になってない。
つか、SmartyでできることはPHPでもできるけど、PHPでできることがすべてSmartyでできるわけでもないのか。
>フレームワークってそういうものでしょ.
今はテンプレートエンジンの話。
メリットがわからないなら、使わなきゃ良いだけだろ。 何をうだうだ言ってるんだか…
どっちでもいい派だから各々好きにすりゃいいと思うんだが、 肯定派の頭ごなしの「これだから嫌Smarty派は…」的なレスは正直どうかと思うが… 否定派の方が"まだ"論理的だわな。
話自体は面白いんだけど、フレームワークとはあまり関係ないよね。 テンプレートのスレで続けたら?
>>861 好きにすればいいものを否定派がムキになって否定して回ってるように見えるが
ところでフレームワークって言葉はこのスレではWeb構築フレームワーク以外には使わない方針なの?
テンプレートエンジンやらDAOやらも広義のフレームワークだと思うが
>>862 に言われるまでSmartyスレ読んでるのかと思ってた・・・。
俺もどっちでもいい派だけど、ただSmartyって言うほど覚える事ある?
余計な機能使いすぎじゃないの?柔軟性なんてそんなに無くていいんだけど。
Viewでいろんな事させ過ぎちゃいかんよ。あくまで分離が目的なのだから。
だからPHPで出来ることがSmartyで出来ない事があるのは当たり前だと思ってるけど。
{php}ってあるけど、あれは使ったらいけない、裏技的なものだと思ってるし。
また、「h()のように定義してしまえば」って言うが、なにかWebアプリ作成するたびに、
何か表示させるたびに定義するの?使い回せばよい?じゃあそれを他人に勧められる?
それはメンテしたり引き継いだりする人がかわいそうかなって思うな。
保守性があがると(速度面での)パフォーマンスが落ちるってのはしょうがない。
Symfonyなどのように「最初から色々用意されている」なら、慣れた方で良いと思うよ。
865 :
864 :2006/04/18(火) 08:45:25 ID:???
>>863 あ、すまん、せっかく話題変えようとしてくれたのに・・・。
俺はAgaviでDB_DataObject使ってるな。
>>863 だな
テンプレートを使う必要があって、性能的に仕様を満たしていれば
採用実績が多く情報も豊富なsmartyが選択肢に入ってもおかしくない
遅くて仕様を満たせなければ使わなければいいだけの話でしょ
フレームワークにしてもテンプレートエンジンにしても
採用実績が多い事自体が採用基準になるのは良くある事
潜在的なバグ出しがされていて情報も多いと判断できるから
なんでむきになって否定派が否定するのかがわからん
Smartyは結局最終的にはPHPに変換されるんだから 最初っからPHPでかけばいいじゃない。 馬鹿かお前ら?一度ならずニ度三度死ね。
どうもsmartyを否定してるやつら(一人?)はsmartyの難点を踏み台にして「PHPテンプレートでいいじゃん」という結論を共有したかったのではないかとエスパー。
俺も一人でささっと作るときはPHPテンプレート使うし、PHPをそのまま使えることは利点だと考えてる。
一つのファイルで済ませるくらいのときもテンプレート部分は下部にまとめてロジックに一切依存させないようにしたりとか。
でもSmarty普通に良いよ。
Smartyオブジェクトの構築とキャッシュチェックくらいしか実質上オーバーヘッドないんだし。
>>864 の
> Viewでいろんな事させ過ぎちゃいかんよ。あくまで分離が目的なのだから。
に禿同。触れようと思ってたけど先に書かれてしまった。
>>866 の
> 採用実績が多く情報も豊富なsmartyが選択肢に入ってもおかしくない
これも禿同。
それに記述の簡潔さ、View周りの機能(フィルタやカスタム修正子/プラグイン)もそろってるなら、Smarty使う理由としては特に文句のつけどころないと思うけど。
あと、エスケープの話が出てたけど、Smartyのラッパクラス作ってassignメソッドをオーバーライドすれば、テンプレートに渡される全ての変数に自動的にhtmlspecialcharsを通すようにもできるよ。
>>867 PHPは結局最終的には機械語に変換されるんだから
最初っから機械語でかけばいいじゃない。
馬鹿かお前ら?一度ならずニ度三度死ね。
肯定してる馬鹿どもは思考停止してるだけだろ。 なんとなく賛成派の方が多そうだから賛成しとくみたいな。 このまま「各々が・・・」と逃げられたら、否定派の理論も書くだけ無駄。 論理的に反証してくれないとどうにもならん。
そろそろフレームワークの話に戻そうよ。 この話題は結局結論が出ないし、面白くない。
873 :
nobodyさん :2006/04/18(火) 10:44:14 ID:NsVFQKmo
>>872 たしかに。
871のような非論理的な書き込みがあると話の発展性に欠けてきてダルくなるな。
煽り方のパターンが微妙なんだよね。
smartyはPHPのコアに入れるか、バイナリのモジュールにしない限り、 PHPの組み込み関数に比べて大幅に速度低下するのは避けられない。 比べる方がアンフェアといってもいいくらい。
ZFのサイトが変わった。 くるのか?
>>876 本当だ。変わった。
でも見た目だけだw
かっちょいいロゴマークになってるね。
smartyはtemplateとキャッシュが簡単に利用できるのが利点だと思ってたよ 静的キャッシュと動的キャッシュができるフレームワークってあるの?
そうそう。キャッシュが使えるのは大きなメリット。 smarty擁護派はなんでこのメリットを主張しないのか不思議。 もっとも自前でキャッシングの実装しても大して手間じゃないけど。
そうだね。
Pear DBとかsmartyは、どういうものか把握せずに使ってる人が多そうだな。 DBエンジンが変わっても、DBクラスをそのまま使えるのがメリット、みたいな説明あるけど、 DBエンジン変えたら、SQLやアルゴリズムの全面見直しは必須だつーの。
だっちゅーの♥
>>864 >また、「h()のように定義してしまえば」って言うが、なにかWebアプリ作成するたびに、
>何か表示させるたびに定義するの?使い回せばよい?じゃあそれを他人に勧められる?
>それはメンテしたり引き継いだりする人がかわいそうかなって思うな。
PHPには標準ですでにnl2br()とか便利な関数があるのに、わざわざプラグイン覚えなきゃいけないほうがかわいそう。
Smarty使っているけど、PHPとSmartyの両方をマスタした要員を確保しなきゃメンテできないので失敗したと思ってる。
>保守性があがると(速度面での)パフォーマンスが落ちるってのはしょうがない。
生PHPなら保守性もパフォーマンスも落とさずに済む。保守性をあげるために必ずしもパフォーマンスを落とす必要はない。両立させることは可能。
でもSmartyってそんなにパフォーマンスわるいのか?内部でPHPファイルにコンパイルしてキャッシュするからそんなに遅くないと思うんだが。
体感的には、Smartyによる速度低下は感じない。それよりDBまわりのほうが体感速度に直に効いてくる。
>>866 >テンプレートを使う必要があって、性能的に仕様を満たしていれば
>採用実績が多く情報も豊富なsmartyが選択肢に入ってもおかしくない
今はその「テンプレートエンジンを使う必要があるのか」という話だろ。「どのテンプレートエンジンを使うか」という話じゃない。
採用実績でいうなら、Smartyより生PHPのほうが実績も情報も上。
>遅くて仕様を満たせなければ使わなければいいだけの話でしょ
だから、Smarty使ってる人になぜ使ってるのか聞いてるんでしょ
「使わなくていい」と開き直るまえに明確な利点をちゃんと説明してやれ
>なんでむきになって否定派が否定するのかがわからん
べつに肯定派も否定派もむきになってないだろ。イタイやつはいるけど。
正当な理由が示せないからってそんな話にもっていくなよ。
>>884 Smartyの覚えることってめちゃくちゃ少ないじゃん。
テンプレート側でかわいそうなほど覚えることがあったってことは、PHPからテンプレートに渡すデータが複雑すぎたんじゃないか?
極端な話がSmarty側は変数の出力、if、foreach(or section)と、修正子を2、3個覚える(覚えさせる)だけで十分効力を発揮するよ。
テンプレートにはほとんどHTMLしか書いてないのが理想だし、それなりに実現可能だと思う。
SmartyにPHPと同等のロジックを無理やりやらせたようなテンプレートだったら、そりゃメンテもキレるわな。
>>885 「Smartyを使う理由」自体はいくつも挙げられてきたじゃん。
それで魅力を感じなければ使わなければいいって話。
みんながみんなおまいと同じ立場、視点、論点から話してるわけでもないしな。
まあとりあえずもちつけや。
>>887 Smartyだってフレームワークだろ。
そんなに別の話題がよけりゃ自分でネタ出せ。
おもしろいネタなら皆自然にそっちに流れるだろ。
>>869 >Smartyオブジェクトの構築とキャッシュチェックくらいしか実質上オーバーヘッドないんだし。
そうだよな。Smartyが遅いと問題になったことは、自分のところでは今までない。
>
>>864 の
>> Viewでいろんな事させ過ぎちゃいかんよ。あくまで分離が目的なのだから。
>に禿同。触れようと思ってたけど先に書かれてしまった。
生PHPよりSmartyのほうがうまく分離できることを示せばいいんじゃないか。
3秒考えたけど思いつかんかった。
>それに記述の簡潔さ、
それはechoまわりだけじゃないかという指摘があったんだが。それ以外でも簡潔だと思うか?
echoまわりだけでも見やすくなるのはたしかにうれしいんだが(おれも最初はそれが理由で使ってみた)、
そのわりには労力が多いし欠点も見えてきたから、労力に見合うほどじゃなかったと反省している。
>View周りの機能(フィルタやカスタム修正子/プラグイン)もそろってる
これはPHPの関数で済むな。
Smartyのmodifierが、PHPの関数より便利だということを示せば、Smartyを使う理由になるんじゃないか。
2秒考えたけど思いつかんかった。
>あと、エスケープの話が出てたけど、Smartyのラッパクラス作ってassignメソッドをオーバーライドすれば、テンプレートに渡される全ての変数に自動的にhtmlspecialcharsを通すようにもできるよ。
デフォルトでhtmlspecialcharsを通して、ある箇所だけ通さない(エスケープしない)ということはできる?高木ひろみつ氏のブログで書かれてたような、セキュリティ重視の仕様。
そういう仕様なら、Smartyを使(r
1秒考え(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アプリで使うべきであるほど完璧な出来だとは考えてないから、嫌いな人がいるのも普通にうなずけるよ。
このスレ読んでてもよくわかるな。
反対派の人は「使いたい人がいてもおかしくはない」とすら考えられないほど熱烈に反対してるの?
>>879 キャッシュ機能が目的でSmartyを使っているやつってどのくらいの割合でいるの?
おれんところでは、Smartyが遅くて問題になったことはないから、出力キャッシュを使ったことはない。
そういうやつのほうが多いんじゃない?もしそうなら、出力キャッシュ機能以外が目的でSmartyを使ってるんだから、その理由を知りたい。
>>880 共有サーバじゃなくて、自前でサーバを用意しているなら、アプリケーションサーバレベルでのキャッシュがいちばん楽だよ。
あるURLにマッチしたら、サーバがキャッシュを返す。PHPすら呼び出さないから高速だし、バックエンドの言語に依存しない(Javaでも使える)。
ただし、ポートレットのようにひとつのページに複数のキャッシュを持たせる必要がある場合は使えないけどね。
>>886 Smartyの覚えることが多い少ないじゃなくて、そもそもSmartyのようなテンプレートエンジンが必要なのかどうかってこと。
生PHPと比べてSmartyの強い利点がなければSmartyを使う必要がない。じゃあSmartyを使う利点とは何か、あるいは利点といわれているものが本当に利点なのかを議論してるんじゃないか。
どうしても覚える量にこだわるなら、生PHPなら覚えることすら必要ない。
>テンプレート側でかわいそうなほど覚えることがあったってことは、PHPからテンプレートに渡すデータが複雑すぎたんじゃないか?
>極端な話がSmarty側は変数の出力、if、foreach(or section)と、修正子を2、3個覚える(覚えさせる)だけで十分効力を発揮するよ。
>テンプレートにはほとんどHTMLしか書いてないのが理想だし、それなりに実現可能だと思う。
それは生PHPでも同じこと。if, foreach と関数を2、3個覚えるだけで十分効力を発揮する。わざわざSmartyを使う理由にはならん。
>SmartyにPHPと同等のロジックを無理やりやらせたようなテンプレートだったら、そりゃメンテもキレるわな。
だれがキレたのかしらんが、うちのメンテがキレるとしたら、生PHPでもおんなじことがおんなじようにできるのに、
わざわざテンプレートエンジンを導入してしまったおれに対してだなorz
正直すまんかった
>「Smartyを使う理由」自体はいくつも挙げられてきたじゃん。
それがほんとうに意味のある理由かどうかを議論しているんだが。
>それで魅力を感じなければ使わなければいいって話。
なんか勘違いされてるっぽいんだが、おれはSmartyを使ってるやつを非難してないよ。
今までSmartyタイプのテンプレートエンジンを使う利点とされてきたのが、ほんとうに意味のある理由なのかどうか、
生PHPと比べてほんとうに魅力があるのかを議論して検証したいだけ。
今まで挙げられた理由のなかで、いちおう理由として成り立ちそうなのが
・echoまわりが簡潔になる
・キャッシュ機能がある
ぐらいか。あとの理由はあんまり理由にならんな。これがtapestryやmayaaだと明確な理由があるんだが。
892の言ってることは的確だな。 「本当に」魅力があるのかと問われてる以上、肯定派の言うことはどれも弱い。 それでいいんじゃないか? 最初からたぶん誰も熱くはなっていないし双方落ち着いてるとは思うが、 話すんのめんどくさくなっちゃった人はかなりいるだろうから。
Smarty使うと不便なことの方が多いと感じたよ。 そのままでは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で済むならアダプタ作んなくてすむから俺フレームワークが簡潔になってウマーと思ってるのは内緒
896 :
nobodyさん :2006/04/18(火) 16:38:57 ID:PuLKXxqh
確かにそろそろsmarty外してもいい気がしてきはするが、 逆にADODBみたいにダイナミックリンクやスタティックリンク可能な標準的テンプレートモジュールが出てもいいかなとも思う。
>>859 で書いた extract()とinclude()のコンビって、どっかのblogかなんかで紹介されてて読んだ覚えがあるんだが、みつからんかった。
誰か知らない?それ読んでから生PHP派に転向したんだが。
それから、Smartyのエラー表示ってどんなんだったっけ?生PHPより分かりやすければ、Smartyを使う利点といえるはず。
でも今手元にテスト環境がないんで確かめられない。
Railsのエラー表示をみて驚いた覚えがあるから、Smartyのエラー表示がすごかった覚えはないんだよな。
最近フレームワークに興味が出てきただけなんで、なぜこんな流れになったんか分からんが とりあえず、smartyが気に入らないのは同意。 気に入らないから、自分でテンプレートエンジン作ってみたんだけどな、 途中で、flexy見たりして、要素でアクセスできるといいな・・・とか思って作ってみたら、 途中でテンプレートの文法に矛盾みたいな部分が出たりしてきたので断念した。 結局、出来合いのものを使うのが一番楽かな?とsmartyだな。 まぁ、結局ん所さ、smarty使うにせよ使わないにせよ、あるものを使いこなせるんならそれでいいんじゃね? (って、この間、PHP5でDOM関数がサポートされてるのを初めて知ったんだが、 DOM APIでXHTMLをテンプレートみたいに使ってみている人居ない? 遅すぎて使い物にならんかな?)
それこそ遅くなりそうだけど、興味はあるね
>>897 > それから、Smartyのエラー表示ってどんなんだったっけ?
うちでちょっと出してみた所、
{hoge}
で
Smarty error: [in テンプレート名 line 1]: syntax error: unrecognized tag 'hoge'
ってな感じ。
特に分かりやすいってもんでも無いと思うけど・・・
>>898 概ね同意。
なんか初めは「Smarty不要」を無意味に連発されてる状況だったから、「使いたくないなら使わなくていいよ」って流れになったけど、それを返すように「Smartyは真の意味で必要なのか?」に論旨がずれてきたって印象。
結局は結論は「使いたくないなら使わなくていいよ」にしかならんよ。
smartyそんなめちゃくちゃいいわけじゃないし。
生phpだって悪くはないし。
一長一短じゃん。
俺はsmartyは記述が短いってだけの理由でも十分使う理由になってるし、とやかく言われる筋合いなし。
「使いたいなら使えば」でいいじゃないのよ。
>>895 > この方法では、「ある箇所だけエスケープしない」というのが実現できないな。
> テンプレートに書かれた情報をもってこれないから。なんかいいアイデアあるといいけど。
prefilterのこと?
>>895 どういう結論を期待してるわけ?
Smarty使って損したなら使わなければいい、以外に言いようがないけど。
まさか再びSmartyを使いたくなるような革命的な理由探しなんかしてないでしょ。
そんなもんないから諦めれ。
俺は記述が簡潔、分離のしやすさ、あとは不満のない程度に拡張もしやすいって理由でSmartyはよく使ってる。
それとも、あなたの書き込みを見てSmarty使うのをやめることにしました。ありがとうございました。って結論じゃなきゃ嫌かい?
「Smartyを使うのをやめる理由」として挙げられたものの方が俺にとっては弱いのでやめる気にはなれない。
おそらく、 生PHP?テンプレートエンジンも使ってないの? というテンプレートエンジン優勢の風潮があったのに対して、 いや生PHPでいいでしょ?むしろこっちの方が使いやすいよ。 というゆり戻しが起きているのが今なのでは。
XOOPSのテンプレートってDWでデザインするプラグインがあったけど 生PHPってDWでくずれずデザインできるの?
906 :
nobodyさん :2006/04/18(火) 17:48:02 ID:N+jyBKUQ
railsがプレゼンテーションに埋め込み型ruby使ってるからね。 railsにインスパイアされたフレームワークは軒並みそれを真似てる。 もともとオレは自分が設計に参加した案件ではテンプレートエンジン使ってこなかったけど。 必要ないから。
>>874 喪前にはがっかりだ。
。。。。。まぁ馬鹿はほっておこう。
否定的な人:特段のメリットが見出せない
肯定的な人:使いたいから使う、イヤなら使うな。
ってのが今の主流派。
で、否定的な人達は今まであがったメリットだけでは利用するに値しないから、
何か他にメリットがあるのか?と聞いている。
要するに自分の意見に対する論理的な反証が欲しいんだよ。
その反証が検討に値するものだったら、このままSmarty使うかもしんないけど、
今まで出てきたメリットしかないっていうなら、たぶんもう使わない。
ただそんだけの話で、誰も「いまどきSmarty使ってる奴wwwwww」
とか言ってるわけじゃない。
なんで技術スレで煽り合いになるのかサッパリ分からん 人は人、おのれはおのれだし。 参考になるならパクればいいし ならないならスルーすればいいし。
>>908 じゃメリットを感じる人が、Smartyを使うことのをやめる必要がない、という意見に対する論理的な反証が欲しい場合はどういう反証してくれるの?
結局「好きにしろ」の以外の結論ねーべ。
そこで御託を並べる意味がわからん。
template toolkitパクればPHPもJSPになれるって考えたんだろうけど、 テンプレートエンジン必須のPerlと埋め込み型のPHPじゃ立ち位置が違いますから。
重いし、覚えるの面倒だし、自由度下がるけど、<?=h($var)?>より{$var|escape}の方が見やすければ、smartyをどうぞ。
記述量が少ないって、ものスゲーメリットだと思うんだけど。 あと、<?=は論外な。
>>912 初めから素直にそう言いなさい。別に重くないし覚える量もごくわずかだしな。
hなんて関数名つけてるやつリアルで見たら張り倒したくなるけど、勝手にどうぞ。
915 :
nobodyさん :2006/04/18(火) 18:57:12 ID:cLSmooAO
静的なHTMLを吐き出す場合でも、そのまま出力する場合でも、 Smartyならあんまコード変更しなくていいから良い
>>914 prototype.jsを張り倒してください
なんでショートタグをオフにするのにこだわるのか分からない。 理由は?
ああ、ちなみにh()ってERbの実装だよ。世界中のrailsユーザを張り倒しにケンカ旅行しにいってください。
>>920 いや、rubyはpからして張り倒し対象な前提で始まってるからな。
まあ、PHPの場合、何かにつけJavaを意識しすぎて、自分自身を見失った感じがあるね。 railsは真逆の方法論を提示したわけで。rails見てると、いちいちPHPに対する皮肉に思えてくる。
>>923 あ、でも改行は常に出力しない今の仕様がいいかな。
<%=h %> だけパク、取り込んで欲しい。
ところで<?=が駄目なのは何故?
マニュアルに移植性が低いと書いてあるようだ。
現実的に問題になるのは、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'とやってもいいし。 かなりどうでもいいこと>ショートタグ使うか使わないか
だから <% %> をデフォルトで有効にすればいいのでは
>>930 好きにしたら。
short_open_tagはオフにしている環境ことがわかってるから、マニュアルにも移植性が低いって書いてあるんでしょ。
それでzendも推奨はしていない。
互換性の問題もあるから廃止にもできない宙ぶらりん状態。
934 :
932 :2006/04/18(火) 19:38:07 ID:???
日本語ヘンだったorz ×環境ことが ○環境が多いことが
だから、どうでもいいことっていってるジャン。 後になって困っても、sedで置換して終わりだよ。 <?=だけ引っ掛ければ、問題ない。
936 :
776 :2006/04/18(火) 19:49:44 ID:???
>>914 おーい、いまをときめくRailsにケンカ売っちゃやばいよ
まぁRuby(eruby)の文法は <%=h @product.name %> みたいに、いちいち括弧を
要求しないからPHPよりはテンプレートにプログラム臭がしなくて比較的いいんだけど。
それにこういう書き方でもヘルパーメソッドだから、なんていうかぱっと見のキモさも少ない。
あ、ごめん。名前消し忘れ。
>>935 一つしかシステム作ってないならそうかもね。
しなくても良いことはしないに限るんじゃないか?
どうでもいいって事は仕事で使ってないから言えるんだと思うが。
カッコ省略可能になんねーかなw
>>935 だから好きにしたらっていってるジャン。
phpをruby風にする妄想をするスレになってまいりました
>>910 喪前にはさらにがっかりだ。
メリットを感じない側は、メリットがないことを証明するのは難しいから、
メリットを感じてる側に反証してくれと言ってたんだよ。
今更取り上げるのも虚しいが、喪前が求めてるのは悪魔の証明と一緒。
ホントにメリットを感じてんだか、ただ暴れたいだけなのか分からん奴よりも、
メリットを感じない人の方が論理的だと言われてた理由がまだ分からんのか?
つーか、もはやいつまでも取り残されてるのは喪前だけなんでこれで終了。
>>942 ちげうよ。使っているものをわざわざ使うのをやめるための理由があるかどうかを論証してごらん。
別にできないならできないでそう言えばいい。
俺だってお前のような頭の固い人間にsmartyを使ってもらえるメリットを論証することなどできない。
お前は自分勝手な論理展開しすぎ。
>>942 >メリットを感じない側は、メリットがないことを証明するのは難しいから、
何で?悪魔の証明とは全然違うじゃん。smartyのデメリットを挙げて
そのデメリットを持たないsmartyより優れていると思われる他の選択肢を
示せばいいだけじゃん。
結局あんた悪魔の証明と言いたいだけちゃうんか
>メリットを感じない人の方が論理的だと言われてた
自分で自分を論理的と言っているだけじゃないの?
>つーか、もはやいつまでも取り残されてるのは喪前だけなんでこれで終了。
逃げるのね、別にいいけど
>>942 論理を振りかざすなら誤謬をなくすことから始めようね。
おれはどっちかっていったらテンプレート言語から出発して、まだその特徴が 強くのこっているphpにおいて、smartyタイプのテンプレートエンジンを採用する意味は あんまりないなって思うけど、javaでのxmlcのような奴なら使う価値があるとおもう。 しばらくEnhydraを使っていたんだけど、デザイナーからもらった見本に ちょいちょいとid属性を振るだけでデザインの変更はおしまい。 あらかじめid属性をつけるように頼むか、既存のものへの小さめの変更なら使用中のものを ひな形として使うように決めておけばその手間だって必要ない。 文書をDOMツリーとして扱うので、タグマークアップ言語にしか使えないけどね だれか作らんかしらん。
> テンプレート言語から出発して、まだその特徴が強くのこっているphp たしかにphpが出てきたばっかりのころはhtmlにコードを埋め込める感覚は新鮮だったけど(まあSSIとかもあったか)、テンプレートエンジンで書くようになったら、「埋め込んで使うphp」はやや冗長に感じるな。 つーかたぶんsmartyって食わず嫌いの人もけっこういそうな希ガス。 そういえば俺も最初はキモくて使う気がしなかった。
ちょうどその食わず嫌いだったんだけど、 この議論(とも言えない部分はあるが)みて、 自分で細かく調べてみて結構使う気になってきたよ
>>770 あたりからSmarty話だけでこのスレ終了かよw
埋め込んで使うといえばColdFusion。あれ最低だった。
Smartyでも生PHPでもいいけど、コードとHTMLの混在だけは勘弁だ。
>>950 そうか?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の予感?
954 :
テンプレ案 :2006/04/18(火) 23:44:36 ID:???
956 :
953 :2006/04/18(火) 23:50:16 ID:???
>>955 しまった。SessionContainerってM2にあったのかorz
PHP4.4のヨカーン
wasp 使った人いる? 今英語のドキュメントを見てます。 余裕があれば土日でいじってみますが 他にも試したい物があって・・・ 英語苦手です。
>>959 なんか主観入りまくりの紹介がついてモメそうな予感w
>>954 は行数制限ギリギリなんでこれ以上は無理ですよ
紹介はモメるから俺は入れない
962 :
nobodyさん :2006/04/19(水) 09:22:09 ID:1t4rF7dP
>>962 デファクトスタンダードって
de facto standard
って書くんだ。
イタリア語かスペイン語由来?
symfonyは重さ的にはどんなもんでしょう?
symfony使ってみたいけど、 詳しい日本語サイトがないな。 英語はアホだから読めん。
>>968 俺は「英語漬け」で読めるようになったぞい
まあ技術英語はパターンが決まってるから読みやすい
>>969 えいご漬け買ったけど、
パッケ開けてないw
やるか!!!
>>968 symfony使う前に英語を覚えることだね。
mojaviサイトちゃんと復活してるね
symfonyのルータよくできてるなー なんか、どのフレームワークも一長一短だから フレームワークキットみたいにして バラ売りして欲しい。 っていうかそれがZendか…。
symfonyのルーターの /:module/:action/* の*ってどういう意味ですか?
エラーメッセージの判定と、メッセージ自体は、action と model どちらに書いてます?
agavi萌え
Symfony使いたいのにPHP5の案件がない・・・(´・ω・`)
SymfonyってVirtual Host使わないと使えないの?
SymfonyってPear使うと簡単インストールみたいな感じになってるけど あれできないとなんかややこしいよな 説明も投げやりだし
SymfonyやZendFrameworkやMojavi3やAgaviはDIコンテナ搭載してんの? もし搭載してないならMapleにも劣ってね?
>>986 釣りだと思うが、DIコンテナがあるから勝ってると思うのは
大きな間違いだよ。
>>987 いやいや、今やJava界隈ではDIxAOPは大盛り上がりだよ。
実際に業務で使われるレベルでな。
もし、今PHPでリリースされてる数々のフレームワークが
DIxAOPに対応してないのであれば、2年遅れてるね。
なんで典型的な釣りに引っかかるのか理解に苦しむ
>>990 話題が無いから
そろそろ埋めたいから
暇だから
992 :
987 :2006/04/25(火) 22:04:18 ID:???
>>988 JavaとPHPでは使われる規模が違うだろ。
あと多分あんた最近DIとAOP知ったんだと思う。
俺も1年前そう思ってたから。
PHPでDIなんか使う(必要とする)場面がほとんどないと思うのだが。
逆に使うと解りにくいと思う。
だが、Seasar.PHPは応援する。
実際に業務レベルで使えるかどうかでは無くて、
可能性を示してくれた事に対して。
次スレまだ
たてたる
無理でしあ
次スレの ZendFramework が ZendFramewoekになってる
本当だ
ついでに1000げと
1001 :
1001 :
Over 1000 Thread このスレッドは1000を超えました。 もう書けないので、新しいスレッドを立ててくださいです。。。