【総合】PHPフレーム� ..
2:nobodyさん
07/10/17 16:04:52
過去スレ
【PHP】フレームワークについて語るスレ7【総合】
ｽﾚﾘﾝｸ(php板)
【PHP】フレームワークについて語るスレ6【総合】
ｽﾚﾘﾝｸ(php板)
[PHP]フレームワークについて語るｽﾚ5[総合]
ｽﾚﾘﾝｸ(php板)
[PHP]フレームワークについて語るｽﾚ4[総合]
ｽﾚﾘﾝｸ(php板)
[PHP]フレームワークについて語るｽﾚ３[総合]
ｽﾚﾘﾝｸ(php板)
[PHP]フレームワークについて語るｽﾚ２[総合]
ｽﾚﾘﾝｸ(php板)
【PHP】フレームワークについて語るスレ【総合】
ｽﾚﾘﾝｸ(php板)
3:nobodyさん
07/10/17 16:12:32
【洋モノ】
symfony
URLﾘﾝｸ(www.symfony-project.com)
code igniter
URLﾘﾝｸ(codeigniter.com)
Zend Framework
URLﾘﾝｸ(framework.zend.com)
CakePHP
URLﾘﾝｸ(www.cakephp.org)
【和モノ】
ちいたん
URLﾘﾝｸ(php.cheetan.net)
Ethna
URLﾘﾝｸ(ethna.jp)
guesswork
URLﾘﾝｸ(classic.guesswork.jp)
maple
URLﾘﾝｸ(kunit.jp)
4:nobodyさん
07/10/17 16:47:33
乙。
話の続きだが、MVCの分離がいらない（利点がつかめない）というやつは、オブジェクト指向も理解していない可能性が高いな。
5:全スレの994
07/10/17 17:00:11
すまん。こっちのスレで質問すればよかったorz
6:全スレの994
07/10/17 17:01:12
転載
990 ：nobodyさん ：sage ：2007/10/16(火) 19:21:01 ID:???
コントローラとビューって
本当にファイルとして分ける必要あんのかな？
大抵のFWはディレクトリが根本から分かれてるから、
対応関係の確認が微妙にもたついたりする。
同じファイルの前半はコントローラ、後半がビューでもいい場合も
多いんじゃないか。
991 ：nobodyさん ：sage ：2007/10/16(火) 19:32:35 ID:???
990 ：nobodyさん ：sage ：2007/10/16(火) 19:21:01 ID:???
コントローラとビューって
本当にファイルとして分ける必要あんのかな？
大抵のFWはディレクトリが根本から分かれてるから、
対応関係の確認が微妙にもたついたりする。
同じファイルの前半はコントローラ、後半がビューでもいい場合も
多いんじゃないか。
>>990
MVCを理解してくれ
992 ：nobodyさん ：sage ：2007/10/16(火) 19:38:00 ID:???
mvcは名前つけただけだからどうでもいいが、mvcが表す概念の価値が理解できないならいまの主流のフレームワークは使えないな。
993 ：nobodyさん ：2007/10/17(水) 15:10:03 ID:deo3V8qx
>>990
大昔はそうしてたよ。
処理を終えてからHTML部分に組み込んでいたyよ。
でも、それってMVCではないんだな。
7:全スレの994
07/10/17 17:01:54
転載その２
994 ：nobodyさん ：sage ：2007/10/17(水) 15:35:13 ID:???
>>990ではないんだが、俺もmvcあまりよくわかってないと思うんだ
相乗りさせてくれまいか
mが独立してるべきってのは納得なんだが、
c１にv１のとき１ファイルでもいいんじゃまいか？
とかおもっちまうんだが、１ファイルにしちゃだめな理由って何なのかな？
smartyとか使ってる＝なし崩し的にvをsmartyで独立実装
って感じになってるだけで、本当の意味でcとvを独立させる理由
ってのを理解してない気がするんだ＞俺
といいつつ、cとvが独立してれば、vを他のテンプレートシステム
での置き換えが用意なんだろうな。とは思うんだが、
cとv分けることのメリットってこんなもん？
経験豊富な人教えてくれまいか？
8:全スレの994
07/10/17 17:02:58
転載その３
995 ：nobodyさん ：sage ：2007/10/17(水) 15:41:10 ID:???
vにロジック書くと共有しにくいとか。
たとえばロジックは同じだけど状態によってviewが変わるケース
996 ：nobodyさん ：sage ：2007/10/17(水) 15:46:31 ID:???
ｖとｃを１ファイルにするくらいならｖとｍじゃね？
997 ：nobodyさん ：age ：2007/10/17(水) 15:47:15 ID:???
ロジック（プログラム）とデザインの分離で、C+MとVは分かれる。
ロジックは、データと処理に分離すると、MとCに分かれる。
だから、全体としてMとVとCに分かれると。
大雑把にはこんなかんじになるのでしょうか？
9:nobodyさん
07/10/17 17:15:25
cがmとv、その他環境や条件などを制御する
c→m1→m2→v1、条件によってはv2・・的なことを実現する場合もある
そのcとvを１つにソースにって俺的にメリット無し
mとvを１つにってのは処理によっては考えられなくもないかな・・
つまりあれだ、簡単にいうとcはindex.phpと考えれば解りやすいかな？
10:nobodyさん
07/10/17 17:25:02
index.phpは画面の遷移だけをするのがきれいじゃない？
FrontControllerで各々のControllerにディスパッチするのがMVCの主流なはず。
11:9
07/10/17 18:19:58
>>10
994さん宛てに、そこ(MVC)にたどり着く前の説明(例)として書いただけ
ついでに
＞index.phpは画面の遷移だけをするのがきれいじゃない？
index.phpはリクエスト受取り、cにdispatchするだけ。
画面遷移うんぬんはcの仕事
12:nobodyさん
07/10/17 20:08:50 deo3V8qx
フロントコントローラーってちょっと好きじゃなかったけど、
最近はやっぱ便利だな～って思えるようになった。
13:nobodyさん
07/10/18 20:17:36 v9duWMwk
■Akelos
URLﾘﾝｸ(www.akelos.org)
■Rhaco
URLﾘﾝｸ(www.rhaco.org)
これらについても語ってくれ。
14:nobodyさん
07/10/18 21:27:32
いじったことない
15:nobodyさん
07/10/18 23:17:20
股間は毎日いじってるくせに！
16:nobodyさん
07/10/19 00:47:54
なんで知ってるんだ
17:nobodyさん
07/10/19 08:29:44
おいおい俺にこたえさせろよ同士
18:nobodyさん
07/10/20 13:49:23
Python、Djangoを使ったことないから、Rhocoのメリットは正直分からない。
Djangoを使ってる人が、仕事でPHPを使わなきゃいけないときに役立つのかな？
いずれにせよ、選択肢が広がっていいことだ。
開発者さん、頑張れ！
19:nobodyさん
07/10/20 13:52:01
チュートリアル、ドキュメントの乏しいFWは、あまり取り組みたくないかも。
中を調べるのが楽しい人はいいだろうけど。
携帯電話に対応したページを作るときに、セッション管理はどうしていますか？
各フレームワークは、簡単に対応できるのでしょうか？
20:nobodyさん
07/10/20 19:03:06
よくブログで厨二病発言してるﾂｷﾐﾔﾀﾝが出来る言うてたよ。
21:nobodyさん
07/10/21 22:37:42
PHP4ってpublicじゃないメソッドは_付ける作法あるじゃん
プロパティーは、
普通はpublicなものはない（protectedまたはprivate)から、
必ず_付けるの？
あるいは非publicは前提として
privateだけ_付けてprotectedは付けないとか？
22:nobodyさん
07/10/21 22:48:40
多分privateだけ_つける。
CakePHPでは、__でprivate _でProtectedをあらわしている。
本来のオブジェクト指向でいえば、プロパティは隠蔽すべきだからおっしゃるとおりだね。
本当なら、作法とかのレベルじゃなくて言語的に間違った実装したらエラーだすべきだよね。
Rubyなんかは、自然とオブジェクト指向で組めちゃうから組み方だけは、ペチパーも真似しちゃえばいいかも。
23:nobodyさん
07/10/21 23:04:54
ありが㌧
__でprivate _でProtectedって発想はなかった
分かりやすいからcake方式でいこうかな
24:nobodyさん
07/10/22 00:28:30
お役に立てて何よりです。
25:nobodyさん
07/10/22 03:32:38
あまり気にする必要はないだろうけど
__（2つのアンダスコア）から始まるメソッド名はPHPによる予約とされてるので
そこだけ注意
26:nobodyさん
07/10/22 18:56:38
関数の返り値で数字を返す時、
phpdocsの説明にintって書く？mixedって書く？
phpの場合、整数を返す時にも実際には文字型だったりするわけで・・・
27:nobodyさん
07/10/22 20:11:51
んなわきゃねえ
integerで返せばintegerで返る
おまえが数値表現できる文字列を返してるだけだろう
28:nobodyさん
07/10/22 20:22:01
いやその通りだけど
返却する時に、
数値表現文字列をわざわざintvalで数値型に変換してから返したりは普通しないだろ？
そうなるとphpdocにintと書くのは正確ではなくなる
とはいえ、意味としてはint…
という時に、他の人はどう書いてるのかと思ったのさ
29:nobodyさん
07/10/22 20:50:12
ふむ
そういう場合で文字列が返るなら@return stringにする
数値表現できる文字列が返るってのを
明示的に書いておいた方がいいようなケースはその後にコメント書けばいい
integerって書くならちゃんとキャストして返す
とにかくPHPとしての型を厳密に書く
30:nobodyさん
07/10/22 21:08:21
うーん
やっぱりintを明示したらキャストしなきゃいけないか…
31:nobodyさん
07/10/22 21:48:58
>>30
当然のこと。
マニュアルでintとなっていれば===で比較できるものだとユーザは思う。
32:nobodyさん
07/10/22 23:02:10
確かに===の比較の可能性があるな
勉強になりました
33:nobodyさん
07/10/23 16:46:28
フレームワークって本当に生産性あげてるかと言えば微妙じゃね？
ファイルがやたら増えて、訂正の必要があっても
どのファイルを直せばいいか考える→それを探す
の人的シーク時間の累積が重い
railsで2年かかって完成できなかったのがphpだと3ヶ月で完成できたって話が
前にあったが
あれもruby vs phpというより
フレームワーク使用 vs フレームワーク非使用
に近いだろうし
34:nobodyさん
07/10/23 16:57:48
それは何も考えずに適当につくってるからだろ
35:nobodyさん
07/10/23 17:03:18
ファイルがやたら増えるのは
適当だろうが適当じゃなかろうが同じじゃん
設定ファイルがやたら分かれてるFWもあるが
必要が発生してからどこ触ればいいか直感的に分からん
36:nobodyさん
07/10/23 17:08:37
フレームワークの生産性を否定するなら
もうちょっと説得力のある理由を提示しろよ
修正でどのファイルを直せばいいか探さないと分からないって
全然そのFWに慣れてきってもいない状態なのに
その時点で生産性も糞もないだろうが
37:nobodyさん
07/10/23 17:12:28
探すって言ってもソースを見るんじゃなく（見ることもあるが）
ファイルを目で探すんだよ
でもそれにだんだんイライラしてくる
なんでこんなにファイルがバラバラにあんだよと
38:nobodyさん
07/10/23 17:23:02
いったい何のファイルを探してるんだ。
基本的にMVCのそれぞれ、外部ライブラリ、設定ファイルぐらいしか無いだろう。
39:nobodyさん
07/10/23 17:54:32
そんな苦労したこと無いよ。
どうやったらそんな事態になるのか、煽りじゃなくて教えてほしいよw
40:nobodyさん
07/10/23 18:08:16
フレームワークという言葉に、生産性だけを
期待するのは幻想
フレームワーク使うことのメリットが小さいと
思うなら、使わなければよいさ
まぁ、生産性って何なのか？定義にもよるがな
41:nobodyさん
07/10/23 19:21:21
module/C005105Action.class.php
module/E103592Action.class.php
module/E214163Action.class.php
module/S118626Action.class.php
module/S118629Action.class.php
template/C005105Template.class.php
template/E103592Template.class.php
template/E214163Template.class.php
template/S118626Template.class.php
template/S118629Template.class.php
みたいになってんじゃね？ｗ
42:nobodyさん
07/10/23 20:22:03
findもgrepもできない奴が
FWの生産性がどうとか100年早いよ廃業しろ
43:nobodyさん
07/10/23 21:13:26
フレームワーク病の患者が多いな
44:nobodyさん
07/10/24 00:43:18
%%04^044^04484218%%Facdevfr.tpl.php
%%08^080^080A2CE8%%CedefrghRegistInput.tpl.php
%%09^094^094CDD11%%MailswdeTemplatexxx.tpl.
%%0A^0A2^0A2BEB0A%%DiaswdefrgtLoose.tpl.php
%%0A^0A5^0A593314%%WdefrvfbgInput.tpl.php
%%0A^0AD^0AD7EC35%%CfrxsnhSuccess.tpl.php
%%0E^0E4^0E407559%%footer.tpl.php
%%0E^0E8^0E807051%%CkodenbSuccess.tpl.php
%%0E^0EA^0EA391ED%%editsssfser.tpl.php
%%10^103^103D5C31%%GlpbcdgeExec.tpl.php
%%10^107^1072EA43%%CbgmqbcSuccess.tpl.php
%%11^115^115E53D5%%CksbwczyqInput.tpl.php
%%13^132^1324373B%%DlskdjfInput.tpl.php
%%13^134^134E030D%%Mailowksncty.tpl.php
%%13^13C^13C3A5EB%%addqs231.tpl.php
%%14^141^1411511F%%O1jsncb6t.tpl.php
%%14^141^1415AFDA%%Ekwiqofff.tpl.php
%%17^175^17581685%%inquirylwecoo.tpl.php
%%1A^1A5^1A56EE3E%%GbsvxoooImage.tpl.php
%%1A^1AF^1AF524A1%%Aixos9Mail.tpl.php
こんなとこ探してるんじゃね？ｗ
45:nobodyさん
07/10/24 01:01:11
フレームワーク病って言葉があるなんてはじめて知ったｗ
HTMLでサイト作っているやつが、
PHP病と口走っているのを
見ている気分だｗ
46:nobodyさん
07/10/24 06:04:52
フレームワーク病も知らずにフレームワークを使ってる技術者なんて・・・
銀の弾丸は存在せず
あらゆるソリューションはトレードオフでしか判断できないのだから
マイナス面も直視しなくてはいけないよ
47:nobodyさん
07/10/24 06:36:26
>>45はPHPのくだすれにも出没して、見当違いのちゃちゃ入れてそうだなｗ
48:nobodyさん
07/10/24 09:53:53 0Hsdskfh
ファイルが分散したり、ドキュメント見ながらディレクトリ名やファイル名つけたりしなきゃならなかったり、余計めんどくさいことが多い。別に分業するわけでもないしよ。フレームワークに限らず、テンプレートなんかもそう感じる。
49:nobodyさん
07/10/24 09:55:14
適材適所って言葉知ってる？
50:nobodyさん
07/10/24 09:57:50
>>48みたいな人って汚いソースを書いてそうだな
51:nobodyさん
07/10/24 13:05:26
俺は、フレームワークのおかげでソースがきれいになった
いままでが糞すぎただけだが・・・
乱雑なものが整列するさまは、まるで歯科矯正みたいだわ
俺にはこの縛りが心地よいよ
52:nobodyさん
07/10/24 13:08:47
どMじゃん
53:nobodyさん
07/10/24 13:14:03
俺もソースのキレイさに拘ってきたが
Google adsense for mobileのGooglerのコード見てちょっと考え変えた
グローバル空間を平気で汚してるんだぜ
俺は思ったね
これで必要かつ十分じゃないかと
PHPをJavaのように使う風潮が広まっているが
PHPはPHPの良さを活かして使うのが正しいと
54:nobodyさん
07/10/24 13:17:11
「フレームワークのおかげでソースがきれいになった！」(51歳/無職)
友人に勧められて軽い気持ちで始めてみました。
戸惑う暇もなく、すぐにフレームワークの虜になってしましました！
乱雑なものが整列するさまは、まるで歯科矯正のよう。
この縛り心地は本当に癖になっちゃいます。
55:nobodyさん
07/10/24 13:18:12
グローバル空間を簡単に汚せるのがPHPの良いところ、と？
ソースコードがきれいかどうかってのと、
コードの動作がきれいかどうかってのは、別問題だと思うよ
56:nobodyさん
07/10/24 13:20:08 0Hsdskfh
動きゃ良いよ。あとは慣れてる方で。
57:nobodyさん
07/10/24 14:56:51
>>54
ちょっｗおまっｗｗ
俺のプロフ晒すなよｗ
ちなみに、プライベートでは縛るほうが好きです
58:nobodyさん
07/10/24 15:00:04
他人の書いた綺麗なソースより
自分の書いた汚いソースが読みやすいのは当然だからな
59:nobodyさん
07/10/24 15:31:24
１ヶ月前に自分の書いた汚いソースより
今自分が書いた汚いソースが読みやすいのは当然だからな
汚いソース量産無限ループ
60:nobodyさん
07/10/24 16:01:43 0Hsdskfh
ファイル1枚で済ませられる用事を、わざわざドキュメントルート外の深いところにスクリプト作って、それを呼び出してぐちゃぐちゃやる必要が本当にあるのか。
他人や未来の自分にとっても、ちょっとコメント書いてあれば済むのに、わざわざドキュメント書いたり読んだりしなきゃいなんて手間もかかるし、いったい誰が得するのかと。
いくらソースが美しくても、追いにくかったらそれは美しくないよ。
もちろん規模によりけりだが。
61:nobodyさん
07/10/24 16:06:39
ちっさいバリーデーションクラスも一クラス一ファイルにしたりするからな
やってる処理はたいしたことないのに大げさすぎ
62:nobodyさん
07/10/24 16:09:20
小さい処理は小さい処理をまとめたクラスとかにすればいいのにな
63:nobodyさん
07/10/24 17:53:43
ファイル 1枚で済む用事にすべてフレームワーク使えだなんて
どんなフレームワーク信者でも言わないと思うが……
64:nobodyさん
07/10/24 18:19:10
フレームワークじゃないoopが最強じゃね
65:nobodyさん
07/10/24 18:32:36
hoge.php ←アクション
hoge_input.php ←テンプレート
hoge_confirm.php ←テンプレート
これを全部同じディレクトリに入れる形にすれば、
アクションとテンプレートが並んでいていいきゃもしんない。
アクションとテンプレートを大本でディレクトリから分けてたから
絵あわせするのが面倒だったが
66:nobodyさん
07/10/24 19:28:39
ちーたんが変な名前じゃなかったらなぁ
67:nobodyさん
07/10/24 19:54:58
なんで「ファイル 1枚で済む用事に」とか極端な例を出してくるんだろうね？
好きにすりゃいいのに。
詭弁で主張したいだけ？
JavaでStruts、PHPでSmartyを最初から使っている俺には
フレームワークは普通です。
68:nobodyさん
07/10/24 20:06:44 0Hsdskfh
それは良かったね。
69:nobodyさん
07/10/24 20:20:14
>>67
Smartyがフレームワークだとでも?(w
語るに落ちるとはこのことだな。
70:nobodyさん
07/10/24 20:23:00
Smartyは糞だってことくらい
今じゃ小学生でも知ってます
71:nobodyさん
07/10/24 20:25:29
ふーん、ごりっぱですねｗ
72:nobodyさん
07/10/24 20:29:37
>>69
君の勝利！！！
あんたが大将！！！
73:nobodyさん
07/10/24 20:38:32
語(かた)るに落・ちる
《「問うに落ちず語るに落ちる」の略》問い詰められるとなかなか言わないが、
かってに話させるとうっかり秘密をしゃべってしまう。
日本語って難しいですねｗ
74:nobodyさん
07/10/24 20:51:44
フレームワーク使うのと使わないのは
結局トレードオフを考慮して決めるもんだからな。
たとえばphpinfoを呼び出すだけのものに、
フレームワークを使ったら時間がかかる。
逆に、データベースを読み書きするもので、
リクエスト(post・get)を投げるアドレスが
5つ以上あるようなページではフレームワークを使ったほうが早い。
まあ、そういうトレードオフの間隔さえ持っていれば良いよ。
75:nobodyさん
07/10/24 20:59:12 /fPlTtD8
フレームワーク != テンプレートエンジン
76:nobodyさん
07/10/24 21:04:23
YOU、フレームワークって何時も喧嘩の種になるからワクワクしちゃうYO!
77:nobodyさん
07/10/24 21:11:11
普通はプログラムが大きくなれば、
開発・管理しやすくするために
ファイルを分けるもの。
これには誰も異存はないと思う。
そういうときに、どういう風にフォルダを作っていくか。
ロードするパスをどうするか
そういう決まりが作られているだけでも
フレームワークは便利だと思うな。
もちろん、URLにアクセスしたら、どのメソッドが呼ばれるかや
データベースにアクセスするにはどうするかというような基本的な土台が
できていることが一番便利なところなんだけどね。
78:nobodyさん
07/10/24 21:28:26
>>75
お前はもういらない子
79:nobodyさん
07/10/24 21:29:45 0Hsdskfh
SEOのために、URL短くしたり、あるいは指定されたりした場合、どうすればいいの？
パラメータは良いけど、アクション名とか、イミフだからやめてって言われちゃったりした場合。
80:nobodyさん
07/10/24 21:31:11
>>79
お前はフレームワークを無理して使わなくていいからw
81:nobodyさん
07/10/24 21:32:14
自分が必要ないと思うなら使わなきゃいいだけの話。
他人にまでそれを押し付けるなよ＾＾；
82:nobodyさん
07/10/24 21:33:03
routingの設定変えりゃいいだけじゃね
最近のFWならどれでもurl routingの機能ついてるっしょ
83:nobodyさん
07/10/24 21:33:25
なぜパラメータは良くてアクション名がダメなのか？
84:nobodyさん
07/10/25 00:13:09
seoとかいってるやつは大体業界のクズ
85:nobodyさん
07/10/25 00:18:06
そのクズに仕事とられたのか？ｗ
86:nobodyさん
07/10/25 00:33:39
yamadaフレームワークって知ってる？文字通り、日本人が開発したみたいなんだけど、
今度使う事になったんだ。
87:nobodyさん
07/10/25 00:40:58
でまた、フレームワーク毎のお約束事を、ドキュメント読んだり覚え直したりググったりしなきゃならん訳だ。
88:nobodyさん
07/10/25 09:25:35
同じフレームワークを使っていれば
一度覚えるだけで良いから楽なのにね。
89:nobodyさん
07/10/25 09:36:28
それだとスキルが鈍磨していかね？
90:nobodyさん
07/10/25 10:02:05
>>88
同じ言語を使っていれば
一度覚えるだけで良いから楽なのにね。
91:nobodyさん
07/10/25 11:28:44
フレームワークを使わなければ、
フレームワークを覚えなくて良い代わりに、
自分でアプリの構成・骨格（＝俺俺フレームワーク）を
作らなくてはいけないから大変だな。
自分ひとりでやるのならそれでかまわないが、
複数人で開発（それが普通）するのなら、
他人は、俺俺フレームワークを覚えなくてはいけない。
92:nobodyさん
07/10/25 16:34:22
フレームワークは効率いい流れをつかむもので
それ自体を使ってはいないな。アレンジして理解しながら
やってるんで時間はかかるｗあくまで参考書的位置づけだな
93:nobodyさん
07/10/25 16:35:52
>>91
覚えるならまだしも、不具合が恐いな
有名なフレームワークなら使っている人も多いから
致命的な不具合はだいぶん取り除かれている
94:nobodyさん
07/10/25 21:41:05
フレームワーク使ったら負け
そんなの常識だろ
95:nobodyさん
07/10/25 21:47:15
>>94
見えない敵と戦っている人がこんなところにw
96:nobodyさん
07/10/25 22:49:22
戦士に敬礼ッ
97:nobodyさん
07/10/26 01:52:41
ある程度の規模のWebアプリを、
生産性や保守性、拡張性を考えながら何回か開発してると、
結局FW的なものに行き着くんだよね。
それでFW的なものが色んな所で開発されると。
仮にそのプログラマが十分に優秀な人なら、
それなりに出来の良いオレオレFWになるわけだけれど、
企業として考えるとオレオレFWだと学習コストやら、
何やらでトータルコストがかさむ。
雇われるプログラマ側としても、
第三者からは得体のしれない社内FWを使いこなす技術なんて、
身に着けても資産価値が大してない。
それに、優秀な人っていうのは数が少ないから優秀と呼ばれるわけで、うんこFWが世界中で開発されて、それを使わざる得ない状況なんてうんこな場面も世界中で繰り広げられていると。
実際、メジャー所のFWのソース読んでると勉強になるよ。
本当に良く考えられてるなぁ、頭いいなぁ、と。
巨人の肩に乗ってるから、っていうのは当然あるだろうけど、
巨人が気前良く肩を空けてくれてるんだから、
普通の人は戦うんじゃなくて乗ればいいんじゃないのと。
98:nobodyさん
07/10/26 03:02:34
プログラマはプライド高いから無理だな
プライドすてれるやつがビジネス的に成功すんだが
99:nobodyさん
07/10/26 12:58:48
プライド捨てても成功できない奴、沢山いるんだがｗ
100:nobodyさん
07/10/26 13:13:18
×プライド捨てると成功できる
○成功する奴はプライド捨てれる
101:nobodyさん
07/10/26 13:42:22
×捨てれる
○捨てられる
102:nobodyさん
07/10/26 16:43:45
このスレを見ている人はこんなスレも見ています。(ver 0.20)
【トイプードル】プードル Part26【ﾐﾆﾌﾟｰｽﾀﾝﾌﾟｰ】 [犬猫大好き]
103:nobodyさん
07/10/26 16:58:52
>>102
俺もそれ気になってたんだよなｗ
PHPerがトイプードルなんかに興味持ってんじゃねえぞ
PHP書きが飼っていいのは金魚までだ
104:nobodyさん
07/10/26 19:27:54
フレームワークの勉強を教えてください。
よろしくお願いします。
（オススメのサイト、本など）
105:nobodyさん
07/10/26 20:59:08
このスレの最初に出てるサイト見ていったらいいじゃん
106:nobodyさん
07/10/26 23:23:37
>>101
言語学に詳しくないやつがそういうつっこみすると浅いからやめた方がよい。
107:nobodyさん
07/10/27 00:26:14
いやそれは普通につっこまれるところだろｗ
言語学とかいうレベルじゃねー
一般常識の話だ
108:nobodyさん
07/10/27 00:39:12
ら抜き言葉が微妙なのは認めるけど、いちいち指摘してる奴は気持ち悪いと俺は思う。
109:nobodyさん
07/10/27 00:43:33
君がどう思うかには興味はない
110:nobodyさん
07/10/27 00:45:27
そうですか。興味はなくても、まぁそう思う人もいるという事で。
俺以外にも結構いると思いますよ。
111:nobodyさん
07/10/27 01:15:45
ら抜き言葉はいけません。
×ほれる
○ほられる
112:nobodyさん
07/10/27 01:16:22
普通にらぬき言葉と呼ばれる表現は方言として存在している。つまりは関西人が関西弁話したら、正しく日本語を話なさいというのと同様に、方言を認めないということになる。
らぬき言葉が方言としてしゃべられているかは別として、言語がさらに日々、経済的になっているだけの話し。（無駄は口語では省かれていく法則）
100年前の年寄りも現代の言葉は乱れていると嘆いたそうだぞ。つまりは、繰り返される無駄な議論。
無知が半端な知識で語らないほうがよい。無知同士の馬鹿な話し合いならいいが、知識人にそんなこと言ったら恥ずかしいぞ。
長文失礼。
113:nobodyさん
07/10/27 01:19:59
> 話し
はなしし?
114:nobodyさん
07/10/27 01:26:54
揚げ足とろうとするまえに辞書引いたらいかが？
115:nobodyさん
07/10/27 01:27:31
受身と可能をら抜きか否かで区別できるくらいまで
どちらかがどちらかとして定着してほしいなーと常々思っている
日本語は気をつけて使うとかなり論理的な会話が可能な言語だと思うのだけど
ここだけが非常に曖昧なんだよねー
フレームワークの話に結び付きそうで結びつかないが気にせず投稿
116:nobodyさん
07/10/27 08:45:10 R02pgmdg
なーにが知識人だよｗ
ら抜きが通用してるなんてことは、誰でも知ってるだろ。
117:nobodyさん
07/10/27 08:54:01
「話」は名詞
「話し」は「話す」の連用形
118:nobodyさん
07/10/27 10:36:45
言葉には文法がある。
フレームワークにも使いかたがある。
言葉が乱れている人の思考回路では、フレームワークをうまく使いこなせない可能性はあるのだろう。
「ら抜き」言葉はよく聞くけど、会話ならOK＝言いたいことは分かる。文章に書くときは、らを入れるように気を付けている。
バグに敏感なプログラマーなら、「ら抜き」言葉に抵抗を覚えるはずに、一票。
119:nobodyさん
07/10/27 10:50:12
perl プログラマなら気にしないかもしれないよ？ｗ
そもそも「乱れている」と捕らえること自体が
多様な受け止め方のひとつでしかないわけで。
自然言語と、自発的に変化できないプログラム言語とを、
混同して考えるのもよろしくないな。
120:nobodyさん
07/10/27 10:51:22
いくらなんでも頭固すぎ。
121:nobodyさん
07/10/27 14:50:34
smarty とか prado とか mojavi とか symfony とか、
なに使えばいいんだYO！
122:nobodyさん
07/10/27 15:09:27
agavi
123:nobodyさん
07/10/27 15:27:04
派生しすぎでよくわからん…
124:nobodyさん
07/10/27 15:29:38
>>121
このスレでsmartyの名前を出すといろんな意味でバカにされるぞw
125:nobodyさん
07/10/27 15:31:51
>>124
そうなの？テンプレート使った出力用のライブラリとしては
手軽だしいいと思うんだけど。
126:nobodyさん
07/10/27 15:33:36
>>125
そうなの？と聞く前に過去レスくらい読め
127:nobodyさん
07/10/27 16:11:49
ここでsmartyって見るたびにsymfonyと間違えてるのかと思う
128:nobodyさん
07/10/27 17:35:23
smartyがﾃﾞﾌｫﾙﾄｽﾀﾝﾀﾞｰﾄﾞなのはｶﾞﾁ
129:nobodyさん
07/10/27 17:39:18
smartyは昭和の遺物
130:nobodyさん
07/10/27 17:39:55
smarty使うとトイプードルに噛まれる
131:nobodyさん
07/10/27 17:51:13 qKhZXt50
smartyでちょっと聞きたいんだけど、デザイナーがdreamweaverとか使ってる時はどうしたらいい？
例えば、htmlとimgディレクトリが実際の場所と違う場所に置くことになるから、相対パスで指定できないじゃない？
src="/hoge.gif"と、ドキュメントルートからのパスで指定して貰えば良いけど、やりにくいらしく嫌がられるんだが…
132:nobodyさん
07/10/27 18:17:49
Smarty使ったことあるけど、何であんなもん使うのか理解不能。
普通にPHPで書けばいいじゃんって思う。
133:nobodyさん
07/10/27 18:58:30
>>132
１人で全部できるHPやｼｽﾃﾑ作ってるならそれでいいんじゃね
ちっちゃいちっちゃい規模ならね
134:nobodyさん
07/10/27 19:34:38
俺、それなりの規模のアプリも作ったことあるけど、個人開発したことしかないからなぁ。
135:nobodyさん
07/10/27 19:56:05
symfonyでも使われているらしいphpmailer触ってるが
setter,getterなしでプロパティーに直アクセスすんのな
これだからphpのoopは( ﾟ,_･･ﾟ)ﾌﾟﾌﾟｯ
136:nobodyさん
07/10/27 19:59:11
smarty( ﾟ,_･･ﾟ)ﾌﾟﾌﾟｯ
137:nobodyさん
07/10/27 20:18:05
Smartyのメリットを上げる時に、「プログラムとテンプレートが分かれているので云々」って
見かける事多いけど、Smartyじゃなくても普通やるだろｗｗって感じだからなぁ。
138:nobodyさん
07/10/27 21:01:17 euGofwdi
URLﾘﾝｸ(ihc.mydisk.jp)
139:nobodyさん
07/10/28 00:26:50
Smartyの最大のメリットは、<?php echo $hoge ?>が { $hoge }と書ける事。
(<?= $hoge ?>でいいじゃんってツッこみしないでね。宗教戦争になるから。）
これだけでいいから、Symfonyもなんか考えて欲しいよ、テンプレート機構。
そこが解決されれば、文句無し最強PHPフレームワーク、だと思う。
CakePHPはその辺連携取り易いのにな。
140:nobodyさん
07/10/28 00:28:35
CodeIgniterが軽い理由は、Vが良いせいか？
141:nobodyさん
07/10/28 01:03:20
>>135
> setter,getterなしでプロパティーに直アクセスすんのな
setter,getterなんて使うのはJavaぐらいなもんだろ？
142:nobodyさん
07/10/28 01:05:58
> Smartyの最大のメリットは、<?php echo $hoge ?>が { $hoge }と書ける事。
ところで、 { } を使っている人いる？
違う記号に置き換えたりしない？
<{ }>とか。
143:nobodyさん
07/10/28 01:41:41
>>142
jsやcss部分を{literal}～{/literal}なんて面倒だから
普通は変更してるんじゃないか？
<{}>とか<!--{}-->とか{{}}とか・・
144:nobodyさん
07/10/28 02:00:29
>>141
PHPとJavaしか知らないのかな?
145:nobodyさん
07/10/28 02:10:03
わざわざ煽ってないで「こういうのもありますよ」って事例を示せばいいのに。
日本人ってなんでこうなんだろうね。
146:nobodyさん
07/10/28 02:26:30
異邦人乙ｗｗｗ
147:nobodyさん
07/10/28 02:45:16
たとえば C# とか getter/setter あるじゃん。
148:nobodyさん
07/10/28 02:47:57
まともなOO言語は普通getter/setterあるだろ
簡単に書けるようになってる言語もあるが
PHPはそうじゃないし
149:nobodyさん
07/10/28 11:10:18
C# の Property 機構は良いねぇ．言語的にきれいにまとまってるし．
でもそれをもって C# に getter/setter ありといえるなら
PHP だと __get()/__set() があるから言語的には「getter/setterあり」といえると思うけど？
（どうせ後付け条件で「あんなのはgetter/setterじゃない」と言い出すんだろうけど）
ていうかむしろ Java にこそ getter/setter が存在しない（ただの命名慣習）わけだが．
Java 7 では getter/setter を廃して property 構文を新規に作ろうって動きもあるわけだし．
150:nobodyさん
07/10/28 11:34:46
ｱｸｾｻﾒｿｯﾄﾞ
151:nobodyさん
07/10/28 13:53:09
OOPって面倒くさいですね。
お役所の手続き事務みたいに決まりごとが多すぎる。
でも、それを悪いとは思わない。
仕組みを考えた人は頭がいいと思う。
152:nobodyさん
07/10/28 13:55:53
プログラムって面倒くさいですね。
お役所の手続き事務みたいに決まりごとが多すぎる。
でも、それを悪いとは思わない。
仕組みを考えた人は頭がいいと思う。
153:nobodyさん
07/10/28 14:13:15 gVsdL0KD
PDTでsetterとgetterの生成やってくれればいいのに
154:nobodyさん
07/10/28 14:30:51
getterはgetXxxって名前よりもプロパティ名そのものが好き
155:nobodyさん
07/10/28 14:37:31
それだとプロパティーと区別付かないじゃん
156:nobodyさん
07/10/28 14:41:17
ｱｸｾｻﾒｿｯﾄﾞ
↓
ｿｻｱｯ('A`)ﾒﾄﾞｸｾ
（操作、面倒くせ）
157:nobodyさん
07/10/28 14:44:03
むしろアクセサ介さずにアクセスする方が気持ち悪い
内蔵に直接手を入れてうんこ取り出してるようなもの
158:nobodyさん
07/10/28 17:47:48
readonly/writeonlyなプロパティは別として
読み書き可のプロパティをpublicにしない納得いく理由を挙げてくれ
気持ち悪いとかそういうもんだからとかは無しで
159:nobodyさん
07/10/28 18:48:21
セックスって面倒くさいですね。
お役所の手続き事務みたいに決まりごとが多すぎる。
でも、それを悪いとは思わない。
仕組みを考えた人は頭がいいと思う。
160:nobodyさん
07/10/28 20:34:39
まったく関係ないセックスの話がしたいのならよそにいけ
161:nobodyさん
07/10/28 20:36:22
スレ違いだ。
よそ行って来い。
162:nobodyさん
07/10/28 20:50:16
まったくだ、このスレの人間はセックスなんて・・・
163:nobodyさん
07/10/28 21:36:08
>>158
後から変更する可能性があるから
164:nobodyさん
07/10/28 23:19:35
プロパティを大量に晒すクラス書いたことないから、
セッターとかゲッターとかもあまり書いたことない＞おれ。
165:nobodyさん
07/10/29 07:49:04
>>137
>Smartyのメリットを上げる時に、「プログラムとテンプレートが分かれているので云々」って
>見かける事多いけど、Smartyじゃなくても普通やるだろｗｗって感じだからなぁ。
同意。それをさもSmartyの利点のごとく語るやつがいてさ、は？とか思った。
Smartyなんていらない。PHPで十分。
つか、Smarty遅くね？PHPファイルをincludeするほうが3倍速かった。
166:nobodyさん
07/10/29 10:29:25 rume0jLE
>>165
Smartyはページキャッシュが欲しくて使ってる
167:nobodyさん
07/10/29 10:58:01
つ PEAR::Cache_Lite
168:nobodyさん
07/10/29 13:29:27
>>137とか>>165が作ったオナニープログラムよりはよっぽどマシ
速い遅いとかっていつの時代のサーバを使ってるんだ？w
169:nobodyさん
07/10/29 13:32:34
ネイティブとSmarty比べてるのにSmartyのほうがマシらしい。
170:nobodyさん
07/10/29 14:11:54 cAFvFwpp
おまえらにSmartyの何がわかるんだよ！
171:nobodyさん
07/10/29 14:16:11
Smartyはデビュー作だけ大ヒットしたものの
その後まったく鳴かず飛ばずで
今は地方のスーパーとかを回っている演歌歌手みたいなもの
172:nobodyさん
07/10/29 14:30:56
テンプレートってのはそもそもが
htmlを吐き出すときに、コードで書かないといけない。
コードで書いたらごちゃごちゃして見にくい。
htmlをそのまま書いて、その一部に変数等を埋め込めばいいんじゃね？
という発想で作られたもの。
だからhtmlをそのまま書いて、そこにphpコード埋め込むことが
できるphpでは最初っからあまり意味が薄いものだった。
173:nobodyさん
07/10/29 14:35:25
デザインとロジックは分離するよ。だけどディレクトリ構造まで分離させると、あちこちに散らばってめんどくさい。
変数出力の記述がシンプル、なんて利点をあげる奴もいるけど、出力用の関数を作っといて、
function o($arg,$escape=true){
if($escape){
$output=htmlentities($arg);
}
echo $output;
}
↑たとえばこういうの作って<?o($hensu)?>てな感じで書けばHTMLもスッキリでしょ。
ええとtruncateはー･･･ああマルチバイトだめなんだ、じゃあ自作修飾子をー･･･とかsmartyのドキュメント見ながらやったりするよりよっぽど早い。
大体、修飾子が連なると読みにくいから、そんなのはロジックの出力直前くらいで整えておく方がいいし。だったらSmartyの必要が無い。
キャッシュはPEAR::Cache_Liteなどで事足りる。
Smartyの素晴らしさを教えてくれ。マジで。
174:nobodyさん
07/10/29 14:43:53
o('obj.arr.value') という書き方で
$obj['arr']['value']の値を表示させるってのもありだよな。
175:nobodyさん
07/10/29 14:47:35
PHP自体がテンプレートだから
テンプレート(＝PHP)の上層に作られたテンプレート(＝Smarty)
って構造
SmartyはPHPに無い＋α提供してくれる
と理解してて、Smarty使いこなしてるなら何も言わないけど、
大多数はなんとなく時代の流れ（？）で Smartyって便利だぜー
って言ってる様な気がするんだヨナー
176:173
07/10/29 14:51:28
ごめん、$escape==falseの場合はもちろん$output=$arg;しといてね。
スレチだけど、似たようなパターンでよく使ってる関数をひとつ。
d($arr){
echo "<pre>";
print_r($arr);
echo "</pre>";
}
デバッグ時によく使う。
177:nobodyさん
07/10/29 15:52:16
そうそう、Smartyはほんと良く出来てるよね
<?php echo $hoge; ?>なんて書かずに{$hoge}だけだし
{foreach}{foreachelse}や{section}{sectionelse}、{if}まであるし
{strip}なんかも便利{$hoge|nl2br}なんてこともできるし・・その他多々いろいろ
まあつまり>>173みたいな素敵なコードをわざわざ書かなくていいってことだ！
178:nobodyさん
07/10/29 15:57:28
制御構造とかの文法がださいのが嫌
自由度も低いし
179:nobodyさん
07/10/29 16:06:08
177だが、要は使いたい奴は使えばおｋってこと
自分で作れる奴はそれを使えばおｋってこと
>>178
SmartyはHTMLテンプレートですよ
デザイナーが使えりゃいいんです 使いやすけりゃいいんです
180:nobodyさん
07/10/29 16:13:21
>>179
実際デザイナーにsmartyのtpl丸投げできてるところってあるの？
foreachとか入ってて、結局デザイナーが作ったHTMLを
Smarty形式にマが組み込んでるほうが多い気がする。
181:nobodyさん
07/10/29 16:20:46
>>180
まったくだ
182:nobodyさん
07/10/29 16:23:21
デザイナーに使える奴がいないと、結局自分の余計な仕事が増える
ってか今まで使えるデザイナーに出会ったことが無い･･･orz
183:nobodyさん
07/10/29 16:30:01
>>178
＞自由度も低い
とかいっているヤツは、だいたい使いこなせなかったヤツだったりするｗ
184:nobodyさん
07/10/29 16:32:26
>>183
Smartyで自由度を使いこなすとデザイナがわからなくならない？
185:nobodyさん
07/10/29 16:38:11
使いこなすほど醜くなるのがSmarty
186:nobodyさん
07/10/29 17:17:03
PHPでSmartyのようなテンプレエンジンがなぜ必要なのかわからん。
デザイナーにシステムに組み込んでからHTMLなんぞいじらせるべきじゃない
デザイン云々はCSSでやらせるべき
その方が効率的
187:nobodyさん
07/10/29 17:56:21
ｻﾞﾜｻﾞﾜ…
188:nobodyさん
07/10/29 18:08:23
smartyが作られた国ではデザイナとの分業がはっきりしてるケースが多いのかね…。
日本のIT土木と違って。
189:nobodyさん
07/10/29 18:17:10
使いにくいとか言うやつはだまって使わなければいいだけなのに、
なんでいちいち欠点をあげつらうのかね？
オレオレテンプレートエンジンを自慢したいだけか？
190:nobodyさん
07/10/29 18:25:31
○ITドカタ
191:nobodyさん
07/10/29 18:26:24
>>189
使わなくて済むならいいけど、つかうことを強要されてるんで
どこかで愚痴りたいとか
192:nobodyさん
07/10/29 18:29:05
プログラマチームが全員完全にSmartyを理解していて、ドキュメント等を何も見なくてもサクサク書けるレベル、
かつ、デザイナーチームもテンプレートとドキュメントルートの位置関係とか、{Smartyのコード}等をちゃんとわかってる現場なら、使う意味はあるかも。
っていう程度。
193:nobodyさん
07/10/29 18:30:09
>>191
日本には仕事をやめる自由くらいはあるぞｗ
194:nobodyさん
07/10/29 18:30:12
>>189
お前の論調で行くと
使いやすいと言う奴は黙って使ってればいいってことになるな
195:nobodyさん
07/10/29 18:30:55
なぜフレームワークのスレでここまでsmartyの話をするのかｗ
196:nobodyさん
07/10/29 18:33:16
2007年ももう過ぎ行く季節だというのに
Smartyてｗ
Smartyてｗ
197:nobodyさん
07/10/29 18:35:11
とっくの昔に結論出てるのに今更SmartySmarty言ってる奴は原始人
198:nobodyさん
07/10/29 18:36:50
そこでPOHPですよ。
PHPではKwartzぐらい?
199:nobodyさん
07/10/29 18:43:26
>>194
使いやすいと言う奴については何も言及はしていない
論理を勉強して来い
200:nobodyさん
07/10/29 18:49:20
>>199
屁理屈の練習は別でやればいいよ。
ここはフレームワークを語るスレ
201:nobodyさん
07/10/29 19:00:15
Smarty派頭悪すぎワロタ
202:nobodyさん
07/10/29 19:49:56
>>200-201
おまえら頭悪すぎ
ろくなプログラム組めないんだろうな
203:nobodyさん
07/10/29 19:50:53
>>202
外の空気吸ってきなよ
深呼吸すると落ち着くぜ
204:nobodyさん
07/10/29 20:26:34
まあ、高校生くらいなんだろうな
匿名掲示板でも底は見透かされるから無理はすんなってことだ
205:nobodyさん
07/10/29 20:35:22 gR7ARslJ
言っとくけど>>202はスーパーハカーだからすごいプログラム組めるよ？
206:nobodyさん
07/10/29 20:37:23
長期休みみたいなどうでもいい流れになってるな
207:nobodyさん
07/10/29 20:42:02
smartyという単語が出てきた時から嫌な予感はしてたが
208:nobodyさん
07/10/29 20:48:53 gR7ARslJ
・・・そろそろ、やめようか・・・。
・・・そうだな・・・。
（ガッチリ握手）
209:nobodyさん
07/10/29 21:26:13
俺がここらへんでペチパー全体を馬鹿にすりゃ丸くおさまるんじゃないか？
210:nobodyさん
07/10/29 21:31:51
Ruby脂肪ｗｗｗｗ
211:nobodyさん
07/10/29 22:11:39
底は見透かされるから(笑)
212:nobodyさん
07/10/29 22:59:42
ここではSmartyイラネ派が優勢なのか・・・時代も変わったものよのう。
昔は、いくら「include()で十分」といっても、だれも賛成してくれなかったのに。
いい時代になったのう。
Smartyはのう、テンプレートのデザインを崩してしまうタイプのテンプレートエンジンじゃから、デザイナーにはウケが悪かった。Dreamweaverと相性が悪いでの。
XOOPSがはやっておった時代、XOOPSがSmarty使ってたもんじゃからデザイナーでも試してみた人がけっこう居たんじゃが、Dreamweaver使いからはいい評価を聞かんかった。テキストエディタ派は黙々と使っておったがの。
しかし素のPHPは <?php echo htmlspecialchars($var); ?> があまりにめんどいからの、プログラマーの中には嫌うものもいた。
しかしこれも>>173みたいにちょっとしたユーティリティ関数かけば済む話での。そんなことすらできんやつもいるから、PHPユーザがばかにされるでの。
>>177
>まあつまり>>173みたいな素敵なコードをわざわざ書かなくていいってことだ！
数行のコードを書く手間と、Smartyのマニュアルにらめっこする手間とを考えれば、結論はおのずとわかると思うんだがの。
だからPHPユーザがばかにされるでの。
213:nobodyさん
07/10/29 23:02:24 rume0jLE
今Smartyと遊んでいる俺に謝れ！
214:nobodyさん
07/10/29 23:19:43
時代は変わったっていうか
2005年頃既にSmartyは終わってたと思うけど。
ちょうどsymfonyが出てきて
「templateは生phpでいいじゃん」「Smartyいらなくね？」「むしろ氏ね」
みたいな流れが大勢になった。
まさか今更Smartyなんて言葉をこのスレで見るとは思わなかったな
215:nobodyさん
07/10/29 23:23:30
今テンプレートエンジン前提にしてるFWってどんだけあんの？
216:nobodyさん
07/10/29 23:30:06 gR7ARslJ
xoopsやらのwebアプリはsmarty使うのやめて欲しい。
217:nobodyさん
07/10/29 23:30:27 rume0jLE
Ethnaって違ったっけ？
218:nobodyさん
07/10/29 23:50:00
>>216
お前が人間をやめれば解決する
219:nobodyさん
07/10/29 23:54:33
smarty派のタチの悪さが
smartyの評判をますます落としていくｗ
220:nobodyさん
07/10/30 00:23:47
Smartyはプラグインが蓄積されてたら{$hoge|huge|hage}で簡単にオレオレ関数呼べるし、
そう悪くはないと思うけどなあ。確かにOSSでの採用は微妙だけど。
そもそも重量級のサイトには使えないし、
DWで崩れちゃヤダヤダなデザイン屋にはPHPTALでも使うしかない？
221:nobodyさん
07/10/30 00:24:04
とりあえずSmartyに限らずテンプレートエンジンが必要か否か、
から始めようじゃないか。
Smartyを使ってる人、
Smartyは使ってないけど別のテンプレエンジン使ってる人
生PHPの人がそれぞれいるだろう。
222:nobodyさん
07/10/30 00:30:37
>>221
まだやる気か
○しますよ？
223:nobodyさん
07/10/30 00:58:09
>>219
タチの悪さ( )笑
２ちゃんねるは初めてなのか？
224:nobodyさん
07/10/30 01:04:32
>>214
>2005年頃既にSmartyは終わってたと思うけど。
>ちょうどsymfonyが出てきて
>「templateは生phpでいいじゃん」「Smartyいらなくね？」「むしろ氏ね」
>みたいな流れが大勢になった。
それはないのう。生PHPよりSmartyのほうがもてはやされてたし、いまもその傾向が強い。
Smartyイラネ派はいつもマイノリティーじゃい。今日がはじめてじゃないかの？勢力が逆転してるのは。
流れが悪くなったら船をコロコロ乗り換えるおまえさんみたいなやつは昔から多いがの。
まあ、生PHPだとテンプレートに何でもかけてしまうから、できることを制限させるという目的でSmartyを使うのはありだとは思うがの。
225:nobodyさん
07/10/30 01:08:36
過去スレ読んでない奴多いなｗ
このスレでは毎回Smartyﾌﾙﾎﾞｯｺだったよ
てかもう飽きた
テンプレートエンジン専用スレなかったっけ
そっちでやってくれないか
226:nobodyさん
07/10/30 01:09:56
２ちゃんが世間と一致していると思っている奴ハケーンw
227:nobodyさん
07/10/30 01:15:25
smartyとか言いだしたのプードル飼ってる奴じゃね？
このスレじゃ歴史的に禁句なんだよ
毎回無駄に荒れて何も得るものがないから。
228:nobodyさん
07/10/30 01:18:28
お前の職場にトイプードルを飼ってるPHPerはいないか？
そいつが犯人！
229:nobodyさん
07/10/30 01:30:17
なんかこういう流れは前にもあったなー、と思ったら、JavaでのEJBとPOJOの流れによく似とらんかいの？
昔、EJBが全盛だったころは猫もしゃくしもEJBを使おうとしておっての、EJBが使えないと一人前とは見なされなかった。
その時期に「EJBは複雑すぎる。もっと簡単なソリューションがあるはずだ」といってみても、お前の頭が悪いからEJBを使いこなせないだけだろ、と一喝されたものだ。
でも結局はIoCだのDIだのPOJOだのがでてきて、SpringやHibernateが主役になった。あれだけベンダーが金をつぎこんだEJBはもはや誰も見向きもしない。
あの当時、EJBを誇らしげに語ってたやつやベンダーは、今はそんなことはまるでなかったかのように「これからはDIだ」とか語ってんの。自分たちが今まで間違ってたことはなかったことになってるらしい。
Smartyから素のPHPへの回帰も、規模は小さいけどよく似てないかの。みんながSmartyだと言ってたから、よく考えもせずにSmartyを採用してたというのが本当のとこじゃないかの。
みんながSmartyといえばそれを持ち上げ、Smartyいらないという流れになれば立場を変える。EJBのやつらとなんも変わらんわの。どっちも自分の頭を使ってない。
Ruby on Railsは変なテンプレートエンジンを使ってなくて、eRubyをそのまま使ってるけど、単に使ってるというんじゃなくて、自信を持って「他のテンプレートエンジンはいらない」と言い切ってる。
Railsの作者はよくわかってる。PHP陣営も見習ってほしいのう。
さて、アニメでもみるかの。今日は何があったかの。
230:nobodyさん
07/10/30 01:40:31
>>229
それがこのｽﾚでとっくの昔に出てた結論だよ
PHPer馬鹿にすんなよ
231:nobodyさん
07/10/30 01:44:53
言ってる内容は陳腐とはいえ特に問題ないが
「自分は分かってる。自分以外はバカだから分かってない」みたいな口ぶりがムカつくので
賛同してやらん。
232:nobodyさん
07/10/30 01:53:53
またもやアニオタはダメだとの論拠が強化された。
233:nobodyさん
07/10/30 01:53:57
>>176
単純だけど便利になったわ
今まで単にvar_dumpしてた
234:nobodyさん
07/10/30 01:55:01
>>232
駄目っていうか思いこみが激しいな
まあどうでもいいけど
235:nobodyさん
07/10/30 02:51:06
URLﾘﾝｸ(journal.mycom.co.jp)
Rubyは公式ロゴが決定したというのにぺちぱーは醜い内部抗争ﾜﾛｽｗｗｗ
次ページ最新レス表示スレッドの検索類似スレ一覧話題のニュースおまかせリスト▼オプションを表示暇つぶし2ch
5366日前に更新/226 KB
担当:undef