【PHP】フレームワークについて語るスレ10【総合】

【PHP】フレームワー� ..

232:nobodyさん
08/03/15 00:11:35
>>231
URLﾘﾝｸ(blog.ohgaki.net)

233:nobodyさん
08/03/15 00:13:21
>>231
そのサイトはひどい釣りにしか見えんな
確かに、既存サーバのPHPが硬直してしまっているっていうのは必要な指摘だとは思うんだけど、
その書き方が突飛と言うか無理過ぎるというか、とにかく説得力がない

例えば
＞Apacheのmod_phpを使ってPHPをApacheモジュールとして実行すると、Apacheプロセスの
＞すべての資格情報がPHPに引き継がれます
って、SuExec等を使わない限り、Perl、Ruby、Python等のCGIでも同じっていうことに言及しない
のはどうかとも思う。他にもいろいろ、わざとかも知れないけど香ばしい

234:nobodyさん
08/03/15 00:14:31
・・・なんかかぶったｗ

235:nobodyさん
08/03/15 01:27:32
>>230
いつまでも馬鹿相手にする輩なんか本人以外にありえんだろ

236:nobodyさん
08/03/15 08:30:08
ウェブサーバとアプリケーションサーバを別プロセスにした方がセキュアというのは正しいだろう。fastcgiの外部サーバとかJavaみたいに。

237:nobodyさん
08/03/15 16:57:53
最近どこもかしこもやたらSuExecだしなー

238:nobodyさん
08/03/15 17:23:26
suexec導入しようと思ったが
apacheのsuexecの説明見たら
suEXEC の設定には管理者の詳細にわたる慎重な注意が必要
とか書かれてｺﾜｽ

239:nobodyさん
08/03/15 18:23:12
suexecなんか使うくらいならfastcgi使うわ。

240:nobodyさん
08/03/15 18:30:06
suexecって要するにCGIをsetuidされたラッパーを通して実行するもの？
てことはモジュール版のPHPは普通にapacheの権限で実行される？

241:nobodyさん
08/03/15 20:29:23
みたいだね
ってことは、suexecが必要になるのって
不特定多数のユーザにリソースを貸すサーバ屋さんくらい？

242:nobodyさん
08/03/16 00:45:11
だってなぁ、suExecを使わないということは
ほぼApacheモジュールで動いているのと同じなわけで、

Apacheモジュールで動くということは、Apacheの権限で動いているわけで、
PHPを使えば、Apache権限になれるから、
Apache権限で読み出せる他ユーザーのファイルを読み出せるからな。

243:nobodyさん
08/03/16 21:39:19 9hRtdL6R
include_onceがアクセラレータで使われない問題って
apc.include_once_overrideで解決できるんじゃね？

244:nobodyさん
08/03/16 23:14:35
facebookってPHPなんだな
Ruby脂肪ｗｗｗ

245:nobodyさん
08/03/23 05:33:05
Perl=信長
PHP=光秀
Python=秀吉
Ruby=隠れキリシタンｗｗｗｗｗｗｗ

246:nobodyさん
08/03/23 12:01:53
Ruby=慶次

247:nobodyさん
08/03/23 12:28:04
いずれにしろ光秀のPHPって・・・

248:nobodyさん
08/03/23 15:47:03
mbstring系の設定をPHPのコード中でしてたら、どうも文字化けする。
.htaccessに書いたらしなくなったけど。
mbstring系の設定はphp.iniか.htaccessでするって常識？

249:nobodyさん
08/03/23 16:40:24
みなさんすいません。>>248と同じ会社の者です。
まだ見習い中なのでとりあえずphpに慣れてもらおうと課題を出したのですが、
何日たっても報告にこないのでついさっき報告をあげさせると共に指針を与えた所でした。

mbstringが、mbstringがと、説明が要領を得なくて時間がかかったのですが、
どうやらmbstring.languageをスクリプト中で指定しようとしていたらしく、
マニュアルで確認するように伝え、日々日報に問題点を記述するように厳しく指導いたしました。

今後このような事が無いように指導を行い、
また、ご迷惑をおかけしましたことをお詫び申し上げます。

250:nobodyさん
08/03/23 16:51:02
なんていうか不安でいっぱいな会社だな。まあガンガレ。

251:nobodyさん
08/03/23 19:26:02
常識なの？
誰も言わなかったじゃん
ちゃんと説明しろよ249のハゲ

252:nobodyさん
08/03/23 20:55:07
懐かしいコピペだな

253:nobodyさん
08/03/23 21:23:45
PHPのmb_send_mail()とかクソ過ぎだろ。どうやったらこんな分かりづらいAPI思いつくんだか。

254:nobodyさん
08/03/23 21:39:27
>>253
上の方で出てた
mb_send_mail使う奴はど素人、プロはmailを使うでFA

255:nobodyさん
08/03/23 21:48:36
プロなら直にSMTP

256:nobodyさん
08/03/23 22:31:41
>>255
まあ汎用的ではあるな。一度しっかりとモジュールを作ってしまえばいいわけだし
というわけで、マルチバイトや添付ファイル、HTMLメールにがっつり対応したメールモジュールのある
フレームワークの紹介よろしく！

257:nobodyさん
08/03/23 22:35:47
>>256
あとPOP before SMTP と SMTP Auth にも当然対応しているという奴かな
どこにでも転がってそうだけど、一つばっちりした物があればそれでいいんだし

258:nobodyさん
08/03/23 22:35:49
>>256
Zend

259:nobodyさん
08/03/23 22:47:42
>>258 thx
結局ライブラリの質というか筋がいいとかでいうと、Zendが一番なのかな

260:nobodyさん
08/03/23 22:52:37
そうだね

261:nobodyさん
08/03/23 23:09:14
餅は餅屋なんだからMTAに任せたらいいじゃん
わざわざSMTP叩く奴なんなの？変態なの？

262:nobodyさん
08/03/23 23:32:43
>>261
MTAはMUAの間違い？（sendmailコマンドの様な）
PHPの関数インターフェイス(mail(), mb_send_mail())もMUAと言えなくもないのかな

でも、外部SMTPサーバを使いたい時も同様に扱えるから初めからMTAのサーバを
ソケットから叩くっていうのはそんなにおかしくないと思うけどな
そりゃいちいちpopenとかベタベタでやるのは変態っぽいけど、ライブラリになっていれば
そんなに手間でもないと思うし、PHPの関数叩くのとやってることは大して変わらないと思う

263:nobodyさん
08/03/23 23:39:24
>>262
ソケット通信なら、popenじゃねえな
fsockopenとかそういうのだな。PEARでもいいけど

264:nobodyさん
08/03/24 00:44:07
あー
外部にメールサーバがある場合か
なるほどね

265:nobodyさん
08/03/24 00:53:41
ZFだと確かPOPも扱えたよね。

266:nobodyさん
08/03/24 01:03:45
そうだ。餅は餅屋に任せよう。
んで、sendmailで添付ファイルを送るにはどうすればいいんだ？

267:nobodyさん
08/03/25 15:59:11
餅は餅屋って、sendmailはMTAだから、そのおまけのコマンド起動送信も含めて
添付ファイルを処理させるのはおかどちがいだろう。
まぁ適当にmultipartなメールをでっちあげてください。

>>262
MUAって、MDAが落としたメールとかも読めなきゃいけないんじゃない?
たぶん、あれをMUAとは言わんような...どっちでもいいけど。
どっちも/sbin/sendmailだからややこしいな。

268:nobodyさん
08/03/29 02:49:42
PHP のフレームワーク: 第 5 回外部タスクを統合する
URLﾘﾝｸ(www.ibm.com)

3大フレームワークでのバッチ処理についての記事。
このシリーズは正にこのスレ向けだね。

269:nobodyさん
08/03/30 17:45:17
フレームワークでは例外がデファクト的に使われてるけど
例外だとApacheのエラーログに残らないのが難だな
フレームワークのログには残るけど。
Apacheのエラーログ見ながらテストってよくやるし、
そこで例外が確認できないのはイケてない。

270:nobodyさん
08/03/30 18:05:39
>>269
FWの一番上層のtry～catchで
error_log($exception->getMessage());
しておけばいい
mod_phpならapacheのerror_logに吐かれる
自分で例外をハンドリングもせずに例外が難だな、とか言われても

271:nobodyさん
08/03/30 19:45:47
>>270
>FWの一番上層のtry～catchで
その部分はFWが提供していて書き換えられない・拡張できない場合がほとんどだろ
自作FWじゃないんだから

272:nobodyさん
08/03/30 19:55:44
例外使わないCIが最強

273:nobodyさん
08/03/30 22:07:54
>>271
FW全域に渡ってのエラーハンドリングできないFWもアレだと思うし
仮にできなくてもブートストラップになるdispatch部分をtry-catchしたらいいし
それもいやならexception_handlerだってあるしやり方はいくらでもあるよ

274:nobodyさん
08/03/30 22:31:58
素直にframeworkのlog見ときゃいいだろ、と思ってしまう。

275:nobodyさん
08/03/30 23:06:10
ログが残る場所が変わるだけだろｗ

276:nobodyさん
08/03/30 23:37:57
だいたいアプリレベルのログをなんでapacheのエラーログでみたいのかが分からん

277:nobodyさん
08/03/30 23:45:40
アプリのログならその気になれば
HTTPヘッダやスタックトレースを出したりできるしな。

なんで不便なapacheログに頼るのだろう？

278:nobodyさん
08/03/31 01:07:38
html側の気づきにくいミスも分かるからapacheログ便利じゃん
fwのログではリソースへのリンクミスは分からない
どこかひとつにまとめておくならapacheログになる

279:nobodyさん
08/03/31 02:15:07
>>278
まとめて保存されてても
見る時は見づらいからフィルタリングして分けてるんじゃないの？

280:nobodyさん
08/03/31 02:58:55
俺なんてapacheログに日記書いてるよ

281:nobodyさん
08/03/31 03:01:14
その発想はなかったわ

282:nobodyさん
08/03/31 13:35:52 q29QDC7U
フレームワークのORMって
テンポラリテーブルやサブクエリ使うような処理はどうなってるの？
出来るのはせいぜいリレーションまで？

283:nobodyさん
08/03/31 14:57:48
サブクエリ対応のORMもあるんじゃないかな。はっきりあるとは言えないけど。
テンポラリテーブルはORMの範疇じゃないと思う。

284:nobodyさん
08/03/31 18:38:39
>>282
そういう場合はSQLを直接発行する。

285:nobodyさん
08/04/01 00:51:46
複雑なSQLになると、SQLは3分で書けたのに、それをORMの文法に直すのに1時間かけても出来無くって、挙げ句ORMのソースコード見たら対応不可能だったという。

286:nobodyさん
08/04/01 01:29:08
っていうか、ORMは80%の簡単なSQLを
簡単に使うのが目的なわけで。

表形式のデータを扱いやすい構造体に変更するの
面倒なんだよ。

287:nobodyさん
08/04/01 02:16:43
>>286
それはORMを理解してない。

> 表形式のデータを扱いやすい構造体に変更
「テーブルのリレーションをオブジェクトのグラフに」ってことだと思うが、
本来ORMはそれを半自動的(設定ファイルが必要)に実現するためのもの。

> 簡単なSQLを簡単に使うのが目的
これを実装したライブラリとかプロダクトがORMを理解してないのに
ORMとか言っちゃったもんだから、そう勘違いしてる人が多いんだけど。

288:nobodyさん
08/04/01 16:18:05
DBを単純なストレージとしてしか使えてない
joinとかサブクエリとか使いこなせてないわ
そんな俺は何から勉強したらいい？

289:nobodyさん
08/04/01 16:23:40
とりあえずは、普段自分が使うDBのSQLをしっかり覚えればいいんじゃない？
それ以上は、DB屋さんが面倒見てくれるでしょ。

290:nobodyさん
08/04/02 09:36:40
PHPじゃないけど、Bash on Railsなんてものが公開されてるね。
まぁ、ジョークなんだけど。

URLﾘﾝｸ(emasaka.blog65.fc2.com)

シェルスクリプトって、普段/bin/sh互換で書かされるから、
Bashの機能をフルに使って、のびのびと何か書きたい気持ちはわかる。
なんか、昔BashでIMAPを喋るスクリプトを書いたのを思い出した。

291:nobodyさん
08/04/02 21:41:33
bash爺さん乙

292:nobodyさん
08/04/02 21:57:39
頼むから少しでもbash絡みの構文が入ったら#!/bin/bashのサフィックス.bashにしてくれな。

293:nobodyさん
08/04/02 23:23:53
>>292
ファイル名のこと？
っていうか拡張子すら無いのも多いし、シェバングがきっちりしてれば気にしない

スレ的に展開すると、世の中には.htmlでPHP書く会社も結構あるしなあ
そこまでじゃなくてもテンプレートファイルが（実質PHPやテンプレート独自言語でも）.htmlなところも多いし
まああれだ。拡張子なんて飾りですよと。Windows使いにはそれがわからんのですよ

294:nobodyさん
08/04/03 00:32:15
今時糞文法のシェルスクリプト使うってどこのマゾだよ
Rubyでやればいいじゃん

295:nobodyさん
08/04/03 00:37:29
ほぼ存在が期待できるperlじゃなくてrubyってところにリッチさ？を感じる

296:nobodyさん
08/04/03 01:07:46
PerlがないならRubyを使えばいいじゃない

297:nobodyさん
08/04/03 07:21:38
>>296
そんな環境あり得ないだろ

298:nobodyさん
08/04/03 16:03:55 YXuoF4WI
perlとpythonはたいていひっついてくるよね

299:nobodyさん
08/04/03 17:23:53
>>296の滑りっぷりに萌えた

300:nobodyさん
08/04/03 23:27:45
Perlの場合、CPANモジュールのインストールを必要とすることが多いから。
BシェルはもちろんBASHの移植性にはかなわない。

301:nobodyさん
08/04/03 23:42:49
>>300
それがPerlではなくRubyの理由？
じゃないよな
この噛み合わなさはいい加減すごいな

っていうかPHPフレームワークの話題は無いのかｗｗｗ

302:nobodyさん
08/04/05 00:07:56
>>300
CPANモジュール使わなきゃいいじゃんっていうのは無し？
だってCPANモジュール使わなくても、bashに出来ることはPerlで書く方が楽じゃね？
俺はLinuxとかよくわからんが、bashで書けてPerlで書けないこととかってあるの？

303:nobodyさん
08/04/05 08:17:54 ELSeDes5
現場だと、ネットワークがガチガチSecureに構築されていて、CPANに届かないことがある。

304:nobodyさん
08/04/05 10:40:20
Perl(without CPAN) < bash なマゾが集まるスレはここですか

305:nobodyさん
08/04/05 22:54:08
移植性を考えるとシェルの方がいい場合も多いってことだ。

306:nobodyさん
08/04/05 23:05:37
>>305
なにと比べて、を書かないとあんまり意味がないな。逆もあるから

例えばシェルの場合はUnixコマンド（互換性があるとは限らない）を必要とすることでも、
Perlなら力業でベタに書けてしまうかも知れない

もっというとPerlで書いたものはWindowsにも持ってこられる場合も多い
shをBATに書き直す事を考えると、移植性って何？ってな事にもなるなｗ

307:nobodyさん
08/04/06 04:34:39
Rubyなければ入れればいいじゃん
シェルの仕事はコマンド発行とパイプ、リダイレクトまで
制御構造の文法がいびつすぎ

308:nobodyさん
08/04/06 19:14:33
LinuxでもFreeBSDでもシステム標準で使われるのは、若干PerlやPythonスクリプトもあるが、ほとんどはシェルスクリプトだろ。

309:nobodyさん
08/04/06 21:05:04
そうだなぁ。趣味だったら、PHPやRubyを使えばすっごい楽なんだが、
業務だとシェルスクリプトを「使わないといけない」んだよなぁ・・・。
そういう場では、「Ruby使いましょう」なんて言える空気ないよ。
Rubyは枯れてないしね。

ところで、Symfonyはそろそろ何かテンプレート機構は装備されたの？
未だに<?php echo $hoge ?>なの？

310:nobodyさん
08/04/06 21:36:35
<?php echo $hoge ?>で何の問題もないわけだけど

311:nobodyさん
08/04/07 17:09:13
そうそう。PHP自体がテンプレートエンジンなのに要らんことすんな馬鹿だろと思う。

312:nobodyさん
08/04/07 23:28:06
short_open_tag をONにしたときの問題って、ぶっちゃけXML宣言との衝突だけ？

それなら自分でサーバの設定をいじれるときは、テンプレートファイルに限定して
<? ?> <?= ?>形式で記述するのも手だなと感じる。

だれかえろいひと教えて

313:nobodyさん
08/04/07 23:31:50
>>310
やはり自民党清和会の下に結集し、日教組を壊滅させることでしょうね。
日教組の教師に｢労働者の権利｣などという左翼思想を吹き込まれた連中が義務も果たさずに
サビ残は嫌だ、非正規雇用は止めろ、などと権利ばかり主張しています。
あとは残業代を要求して裁判を起こしてるような腐った輩を社会全体で徹底的に叩くことでしょう。

314:nobodyさん
08/04/08 00:07:06
みんなうすうす<?=$var?>が効率的なことに気づきだしてる。俺は5-6年前から気づいて田が名。

315:nobodyさん
08/04/08 00:20:04
何をいまさら・・

316:nobodyさん
08/04/08 00:26:07
>>310, >>311
個人的には、<% %>が廃止は馬鹿だろ、と思った。
使ってはなかったが、Rails使い始めて、やはり必要だと思った。
<?php echo $hoge ?> と <%= $hoge %>
はどちらがすっきり見えますか？どちらがタイプ数（補完なしで）少ないですか？
って事を言いたくて、例えばSmarty正式サポートしろという事ではない。

>>312
自サバならそれもありだと思う。
けど、エロい人がこう言ってるから、凡人の俺は使うのを控えてしまう。
URLﾘﾝｸ(wiki.poyo.jp)
>■ショートタグを使っている
>まだそういう本出てきますか．ハァ．

317:nobodyさん
08/04/08 00:49:12
もうそろそろショートタグの正しい使い方を
認めてもいいと思う。

318:nobodyさん
08/04/08 05:07:11
phpはタイプしやすさなんて一㍉も考えてないからなぁ…
htmlspecialchars, array(); preg_replace...

319:nobodyさん
08/04/08 06:48:18
phpはタイポしやすさを考えてるんだよ

320:nobodyさん
08/04/08 15:59:49
PHPはタイプしやすさよりも読みやすさ優先

321:nobodyさん
08/04/08 17:41:25
読みやすい...のか?

まぁ、フラットな名前空間で、メソッドの動的書き換えなしというのは
読みやすさに貢献しているのかもしれない。

322:nobodyさん
08/04/08 19:53:54
Pythonしか使えないGoogle App Engine開始でPHPとRuby仲良く脂肪ｗｗｗ

323:nobodyさん
08/04/09 13:45:29
frameworkはサイト丸ごと作るとかの場合いいんだけど
単体Webアプリの開発すると全く役に立たないのがなあ。

昔はPerlでよくCGIの配布がされていて、PHPも後から増えてきたが
当時は完璧にMVCなんて欠片もないデザイン＆コード全部ひっくるめソース。
だがそれだけに、配布して掲示板だけ使いたいとかいう場合も
そのPHPファイルさえ設置して設定ちょこちょこ弄れば出来た。
しかし今もしframeworkありきでBBSとか作っても、それを配布するとなるとframeworkをまずインストールしなければならない。
大体掲示板とか配布されてるCGI使うのなんて素人だし、そんなframeworkの導入なんてできないし
第一例えばZFで作っていた場合、ディスパッチャが統括してるから普通の巣HTMLコンテンツまで影響が出る。
ただBBSを設置したいだけなのに、今まで普通にそのままアクセスできていたHTMLをZFのルールに従って設置しないといけない。

とか色々面倒すぎる。
frameworkの特にこの部分が気に入らないんだけど、諸兄らは特に気にしない？
index.phpで統括して振り分けるってのね。
普通に配下に全部おいてディレクトリ構成そのままと同じアドレスでアクセスできりゃいいじゃねえか、って思うんだけど。
コントローラー名/アクション名/
とかプログラマは理解してもデザイナが理解しないだろうと。

完全にプログラムばかりなサイトだといいけど、静的コンテンツが殆どで一部に動的コンテンツがある程度じゃ無駄すぎる。
かといってじゃあそういう時は今まで通りの直PHPファイルのみにしろってなると、なんの為のframeworkだかって思ってしまう。

なげーなｗ

324:nobodyさん
08/04/09 16:03:25
そういうケースにフルスタックのFWは向かないってだけだし、
あとZFに限らずフロントコントローラ形式のFWでも
mod_rewriteのルール次第で特定のディレクトリ以下や
ファイルのみに限定して動作させる事はそれほど面倒な事でもない
ディレクトリ構成そのままで一部分だけFW管轄下にする事もできるだろう
mod_rewriteやrouterの使い方が分からない人の言い訳にしか聴こえない

325:nobodyさん
08/04/09 18:42:17
まぁたまにファンクション寄せ集めの使いたくなるけど
結局全部framework上につくれば無問題

326:nobodyさん
08/04/09 21:44:17
>>323
フレームワークつったってただのPHPファイルに過ぎんよ。

新しくフォルダ作って、そこにすべてのファイルぶっこめばいいだけ。

327:nobodyさん
08/04/10 01:33:27
>>326
FWによるでしょ

328:nobodyさん
08/04/10 01:47:20
rewriteとかinclude_pathとか全部ぶんなげか

329:nobodyさん
08/04/10 07:35:57
>>324
だからPHP技術者が理解できても、一般人が理解できないだろって話をしてるんだが。
昔のPHPやPerlならちょっとだけ勉強すれば素人でもいけるレベルだったが
mod_rewriteを弄る素人いないだろ、ってか無料レン鯖だと弄れないところ多いだろ。
有効になってるかどうかすら怪しい。

お手軽が利点だったのに、そういう配布しても一部の技術者しか設定して使えないようなPHPプログラム作ってもなと。
今までPHPファイルを好きな場所に放り込んで、confとかをちょこちょこ弄った程度で使えていたものが
まずFWを導入して、mod_rewriteとかapacheの設定を弄って更に仕様に則った方式に従ってファイルを配置する
なんての誰が使うんだと。
ZFでいえば、PHP.iniのincludeパスまで設定しないといけない（PHP大本ファイルに全てincludeを書くというてもあるが、まあないわな）
そういうケースってか、後からこの機能だけ他で使いたいな　って事があるだろ？
趣味でもいいが、FWフル活用であるシステムを作りました、その中の一部機能が評判なのでそこだけ配布する事にしました
が、当然元のFWに依存しているのでそれ以外のFWじゃ動かないし、FW前提の作りなのでファイル置いてconfファイル設定程度じゃ動きません。
で結局配布しても使えるのはほぼPHP技術者のみ。
ちょっと自分のページにCGI設置したい、とかそういう昔からいる人間には無理。

仕事のになら別にいいんだよ。
だが仕事でFW使ってそんな配布するのは昔みたいな作りにすればいいとかナンセンスだしな。
それじゃお互いが有効利用しあえないし。
仕事で作ってた一部を配布したいって時無理だし、趣味で配布用に作ったのをFW使ってる方に使いたいって時も無理（または変換に手間）だし。

>>326
フォルダ作ってぶっこんだだけでちゃんと動くFWがいくつあるよ？

330:nobodyさん
08/04/10 08:56:21
まー確かに要求される知識レベルが昔と比べると格段にあがってるよな
昔は「オブジェクト指向が分かっている人間はプログラマの中でもほとんどいない」
なんて本に書かれていたもんだけど
プログラマ界の被差別層PHPERの間でも
オブジェクト指向なんてもはや前提条件だし

331:nobodyさん
08/04/10 11:14:42
>>329
> フォルダ作ってぶっこんだだけでちゃんと動くFWがいくつあるよ？

有名どころは全部対応しているが？

mod_rewriteだって、index.phpを隠すためだけに使用されているわけで、
デフォルト設定のまま使える。
mod_rewriteでコントローラ/アクションに振り分けているんじゃないんだよ？

332:nobodyさん
08/04/12 13:05:07
URLﾘﾝｸ(www.modrails.com)
mod_rails登場でmod_php雪崩式に脂肪ｗｗｗ

333:nobodyさん
08/04/12 15:40:54
やっと、mod_phpに追いついただけじゃん
しかもプリインストールされるまではきてないし、
何年遅れだよｗｗ

334:nobodyさん
08/04/12 16:17:48
は？
フレームワークレベルでmodになってるんだからとっくにphpをぶち抜いてるよ
mod_symfonyとかmod_zend_frameworkみたいなもの
ﾌﾟｰﾌﾟﾌﾟﾌﾟ

335:nobodyさん
08/04/12 17:23:23
rubyに手を出すとスレタイすら読めない無能になるのか

336:nobodyさん
08/04/17 16:32:23
MySQLがオープンソースじゃなくなってPHPまた一歩脂肪ｗｗｗ

337:nobodyさん
08/04/17 17:02:10
その理由なら、rubyも死亡だろｗ

338:nobodyさん
08/04/18 06:17:36
まじでMySQL終わりっぽいじゃん
新規開発はpostgresにした方がいいんかな

339:nobodyさん
08/04/18 07:41:13
クローズドになったらMySQLなんて誰も使わないよな
ポスグレも充分に速くなってるから代替効くし
Sunの戦略がわからんわ

340:nobodyさん
08/04/18 09:42:52
クローズドになるとかいってんのお前だけだよｗ

341:nobodyさん
08/04/18 14:07:52
ソースはこれ？↓
MySQL、新機能追加は有償版の「MySQL Enterprise」だけを対象に
URLﾘﾝｸ(www.technobahn.com)

342:nobodyさん
08/04/18 14:18:22
別にフリーだから使うなんて事はないんだぞ？
趣味ならそれは重要だが。企業レベルじゃあまり関係ない。
SQLServerやらMySQLの有料版が実際使われているのがいい証拠。
企業の場合どっちかというとサポート体制が重要。
金払ってるといざって時サポート呼べるし、場合によっては責任もとらせられる。
無料版だとサポート呼べないし責任は全部自分ところ。

なんでもオープンソース使え使えっていってるのは2流の技術者と、そういうのに疎い有料無料かでしかみれない上役だけ。
現場でわかってるプロの技術者なら有料か無料かなんて選択肢の中ではかなり優先度は低い。

少なくとも、これオープンソースだから使いましょうよ、なんていってる技術者いたらその時点で役立たずのレッテル貼るわ。
その構築するシステムに向いてるかどうかで判断するのならまだしも。

343:nobodyさん
08/04/18 14:52:31
>>342
プロの技術者乙

344:nobodyさん
08/04/18 15:42:02
新機能が追加されないMySQLを使い続けてPHPERジリ貧ｗｗｗ

345:nobodyさん
08/04/18 18:10:17
その理由なら、rubyも死亡だろｗ

346:nobodyさん
08/04/18 18:23:32
RoRはMySQLをポイ捨てしてsqliteに乗り換え済み
先見の明の違いが出たねｗ

347:nobodyさん
08/04/18 18:54:43
ひどいつりだな

348:nobodyさん
08/04/18 19:35:54
sqliteはパブリックドメイン（何しても自由）だから
フレームワークに内蔵してデフォルトにしているだけで
別に良いものだから選んでいるわけじゃないんだけどな。

あくまで開発・プロトタイプ・個人用のもので
複数の人が同時にアクセスするものとしての
本番利用は現実的じゃない。

それにPHPは、sqliteをとっくの昔に言語の標準
データベースとして組み込んでいる。お前に言わせれば先見の明だなｗ

349:nobodyさん
08/04/18 19:41:04
末端の利用者が評論家気取りでグダグダ言ってるなよ。
みっともないｗ

350:nobodyさん
08/04/18 19:55:20
はぁ？普通利用しているからことちゃんとした意見言えるわけで。
使ってもいないくせに何か言おうとしているなこいつｗ

351:nobodyさん
08/04/18 20:26:25
>>350
つれたつれた

352:nobodyさん
08/04/18 20:38:46
>>342
一般企業で有償MySQLってなかなかないんじゃないかな？
OracleかSQL Serverでしょう、有償なら。
現場で解ってるプロの技術者には選択肢ないんじゃないかと思う。
俺の周りだけの話だけかもしれないけど。

353:nobodyさん
08/04/18 20:56:40
裾野が狭まるから頂も低くなるんだよ
オープンソースからプロプライエタリに移行して成功した製品あんのかと

354:nobodyさん
08/04/19 01:02:42
> オープンソースからプロプライエタリに移行して成功した製品あんのかと

どうやら、あなたはオープンソースからプロプライエタリに移行したら
失敗するといいたいようですが、そもそも
オープンソースからプロプライエタリになった製品があるのですか？

あと、MySQLはsunが買収したとしても、オープンソースのままなのは
知っていますか？

355:nobodyさん
08/04/19 03:29:45
>>354
オープンソースからプロプライエタリに移行した製品がないという
悪魔の証明に自ら挑むとはｗ
製品を殺す愚策なんだから知られないのは当然
まぁ俺も知らないけどね
本当に無償版の開発を停止して有償版しか出さなくなったら
MySQLは死んでいくと思うよ

356:nobodyさん
08/04/19 07:12:17
>>341を読む限り、「新機能」がCommunityServer版に付かなくなる、とも読めるな
もしメンテ（および機能改良）が続くんなら別にいいかなと、無理矢理楽観してみる

357:nobodyさん
08/04/19 08:21:08
ウェブシステムの性格的に、信頼性が低くても安い方がいいってことでApacheとかMySQLとかPHPとかが流行ってるわけだからな。
金かかるんだったら、ポスグレにして、その分自分の収入にする罠。

358:nobodyさん
08/04/19 09:19:18 Pd4VwcNb
くだらん書き込みが続いてるなぁ。
ApacheもMySQLも信頼性が低いってー事はないぞ。PHPについてはシランが。

あと、普通にPHPでwebプログラムを組める奴は必然的にPHPとJavascriptという風に複数言語使えるようになってるからそこから更にrubyとかいうことになってもそんなにコストかかるわけじゃないと思う。
俺もrubyについては手をつけてないが、Cやらpythonやらに手をつけてるし。
PHP脂肪とか言われたら他の言語使えばいいだけだって気づかないんかね。

# あと、ここはフレームワークのスレかと

359:nobodyさん
08/04/19 09:21:27
>>355
あんた、悪魔の証明が何かわかってないんじゃね？

360:nobodyさん
08/04/19 13:03:25
>>354
RHELとか？
成功というのが何を指してるかわからないけど。

361:nobodyさん
08/04/19 18:10:16
URLﾘﾝｸ(d.hatena.ne.jp)
Community Server開発継続でPHP余命一年延びるｗｗｗ

362:nobodyさん
08/04/20 01:52:32
src php 捨てたい
けどまだ時期尚早だよな

363:nobodyさん
08/04/22 22:01:35
URLﾘﾝｸ(blog.ohgaki.net)
Ruby1.9以下のWEBrickにディレクトリ遷移攻撃脆弱性があってPHP脂肪ｗｗｗ

364:nobodyさん
08/04/22 23:27:24
URLﾘﾝｸ(d.hatena.ne.jp)
誰かこれ参加しろよ

365:nobodyさん
08/04/23 03:25:02
Delphi for PHPってどうなんだろう
「データベースに特別なコードを書かずとも容易に接続できるようにした」
とかいう説明読むとフレームワークと認識してもいいように思うけど

366:nobodyさん
08/04/23 10:30:22
>>365
フレームワークの定義って、データベースアクセスが簡単かどうかってよりも
アクションのディスパッチャがあるかどうかだと思う。

367:nobodyさん
08/04/23 21:37:32
そりゃMVC一通りあるんじゃないの？使ったことないから分からないけど

368:nobodyさん
08/04/24 20:18:05
URLﾘﾝｸ(blog.ohgaki.net)
Pythonのセキュリティー警告してたらSPAMにメールアドレス使われたみたいだ
Python厨タチわりー

369:nobodyさん
08/04/24 20:21:21
Python厨だけにGoogle App Engine使って配信したのかもな

370:nobodyさん
08/04/25 06:21:16
そんな攻撃的な信者はphperにもrubyistにもいないよな
phythonerﾔﾊﾞｽ
しかも単なるセキュリティー情報で誹謗中傷ですらねーし

371:nobodyさん
08/04/28 10:48:30
フォームヘルパーって使ってます？
せっかくMVCなのにテンプレートに関数入れるなんて、とっても矛盾してると
思うのですが・・・
そういう需要もあるってだけなんですかね

372:nobodyさん
08/04/28 11:49:40
Viewのロジックじゃん
MVC=Viewの動的要素を一切省こうってわけじゃないよ

373:nobodyさん
08/04/29 00:07:53
確かにプルダウンとかラジオボタンのHTMLをコントローラ（やモデル？）でつくって
準備するのはなんだかなーだ
分担としては間違いなくViewの仕事だろう。ヘルパーって言うのが微妙なんだけどな

374:nobodyさん
08/04/29 01:49:36
だからViewHelperはViewの範疇なんだっての
高校生か？

375:nobodyさん
08/04/29 09:35:20
URLﾘﾝｸ(www.sabel.jp)

またフレームワークが増えましたよ、と。

376:nobodyさん
08/04/30 02:52:49
DIにアスペクト志向にアノテーション……採用前評価がめんどくさそうなw
採用検討／評価するにしてもうちはGW終わってからだなー。
おまえら頑張れ

377:nobodyさん
08/04/30 04:53:29
symfonyってcodeigniterの何倍くらい重い？

378:nobodyさん
08/04/30 15:03:38
rubyてmysql使うのにもmakeとかしなきゃいけないのか・・俺脂肪

379:nobodyさん
08/04/30 16:29:31
ふつー gem install mysql

380:nobodyさん
08/05/01 17:01:00 1aec6u7x
ethnaがシンプルでよかったので
社内システムの標準FWに採用しました。

381:nobodyさん
08/05/01 20:29:40
ethnaってまだ開発続いているの？

382:nobodyさん
08/05/02 00:35:33 ulIGiMsU
地味に続いてるよ。

383:nobodyさん
08/05/02 14:05:51 ulIGiMsU
新しいバージョンでるみたいだね。

384:nobodyさん
08/05/02 14:35:04
symfonyはcodeigniterの3倍遅いみたいね
同じパフォーマンスをあげようと思ったら3倍のリソースが必要か…

385:nobodyさん
08/05/02 14:58:16
単純に機能とスピードのトレードオフだろう。

386:nobodyさん
08/05/02 16:54:39
URLﾘﾝｸ(jp.techcrunch.com)
twitterがRoRを放棄でPHP復活ｗｗｗ

387:nobodyさん
08/05/02 16:57:33
RoRがスケーリングに対応できないというが
それならRoRをパクっただけのPHPのFWが対応できるのか？

388:nobodyさん
08/05/02 17:16:29
全部erlangで書きゃいいのに

389:nobodyさん
08/05/02 17:16:36 mpl3PtrU
phpは素で書けば速いもんな。

390:nobodyさん
08/05/02 18:38:44 ulIGiMsU
エスナも早いよ

391:nobodyさん
08/05/02 20:08:53
ciはソースに今どき閉じタグが書かれているのがイモ

392:nobodyさん
08/05/02 20:50:58
閉じたり閉じなかったりで動きが変わる事自体がイモじゃね
仕方ないんだろうけどさ

393:nobodyさん
08/05/02 21:29:55
>>391は所得も知能も底辺に位置する者の喚き声だなｗ

394:nobodyさん
08/05/02 21:37:21
なんで？

395:nobodyさん
08/05/02 21:38:49
>>393の頭には虫がわいてんだろうなww

396:nobodyさん
08/05/02 22:22:41
ソースに今どき開きタグが書かれているのがイモ

397:nobodyさん
08/05/02 23:34:45
>>396
それは激しく思う。というか閉じタグをとっぱずすなんてどう考えてもバッドノウハウじゃねえかｗ
少しは疑問に感じろよPHPerども

398:nobodyさん
08/05/03 03:55:15
閉じタグを書かない俺ってＧＥＥＫ！

399:nobodyさん
08/05/03 03:59:36
ciはsystemディレクトリの中にapplicationディレクトリが入ってるのがイモ
そこは分けとけよ

400:nobodyさん
08/05/03 04:42:11
>>398はもっと評価されるべき

401:nobodyさん
08/05/03 06:16:41
しばらくsymfony使ってて
久しぶりにci触ったら身軽でいいわ～

402:nobodyさん
08/05/04 23:06:36 QrBYi/l0
結局　中小規模だとどれがおすすめ？？

CakePHP
-> DBと密接すぎる

CodeIgniter
-> セッションがクッキーに保存される

とどっちも肝心なとこがいまいちだった…

403:nobodyさん
08/05/04 23:10:28
>>402
ちゃんと使えば？CIのセッションについては、DBに保存することもできたと思うけど。

っていう自分はドキュメントよんで評価して改良してっていう手間がもうしんどくて、
guesswork classic をカスタマイズしたものを延々つかってるけど

404:nobodyさん
08/05/04 23:13:41
>>403

うん DB使うときはそれでいいんだけど
使わないときがね…

小規模だと CakeかCIがよさげなんだけどね
その改造する手間がね… orz

guessworkもためしてみるかな

405:nobodyさん
08/05/05 00:52:06
CakePHP ってそんなにDBと密接だろうか？

usesプロパティにnull代入すれば
それで終わりじゃね？

406:nobodyさん
08/05/05 01:19:43
>>405

それで一応できるけど
modelは必須なのが前提だし…

DB使うにしても密接すぎて融通きかない感じかな

はまれば楽なんだけどね

407:nobodyさん
08/05/05 03:33:55
普通に作ればモデルを作るのが当たり前なんだが・・・。
まあ経験をつめ。

408:nobodyさん
08/05/05 09:50:45
変態セッションがいやなら$_SESSION使えばいいじゃない

409:nobodyさん
08/05/05 12:22:34
>>407

DBやファイル扱わない場合だってあるじゃん・・

410:nobodyさん
08/05/05 12:31:02
たとえば？

411:nobodyさん
08/05/05 13:45:56
それはどのFWを使うかというより、
FWを使うべきかどうかを検討する規模の開発だと思う。

生PHP+何かしら必要なライブラリで事足りそう。

412:nobodyさん
08/05/05 15:29:14
>>407
自分は、>>406じゃないけど、具体的にはどんな感じでモデル組んでます？

オンメモリな処理はともかく、DB上のデータに対しては、SQLの実行はパフォーマンスに
直結するから、内部の処理は隠すべきではないんじゃないかって思うところもあって、
結構悩ましい。

413:nobodyさん
08/05/05 17:17:56
内部の処理をモデルの中に隠せばいいのでは？

414:nobodyさん
08/05/05 19:08:40
だって、最適なSQLって画面とか機能ごとに違うことが多いじゃん。
画面とか機能からの独立性がほとんど無いものを個別に作り上げて、
それをモデルと呼べるのかといえば、かなり疑問。

っていうか、モデルとしてのメリットがほとんどない。

415:nobodyさん
08/05/05 19:21:04
MVCを勉強しなおしてね。

416:nobodyさん
08/05/06 01:40:18 Db+mgkTm
CIのルータが変態なので自前ルータを書いてるんだが
hoge/moge/
と
hoge/moge
を同一と判定すべき？しないべき？

417:nobodyさん
08/05/06 01:45:13 iGu8GQhf
すべき

418:nobodyさん
08/05/06 01:54:34
だよな
ファイルシステムとの類推で考えると
同名のファイルとディレクトリは同階層に存在できないもんな

419:nobodyさん
08/05/06 03:21:15
どちらでも同じコンテンツにアクセスできることが望ましいと思うが、
どちらかに転送した方が良いと思われ

420:nobodyさん
08/05/06 16:53:07
質問スレで知ったんだがRhacoってどうなの？
和製フレームワークっぽいけど
このスレで出たことないよね？

421:nobodyさん
08/05/06 16:54:23
どうも和製はなぁ。

結局海外製に押し切られる気がする。
だからRubyもいまいち使う気になれない。

422:nobodyさん
08/05/06 16:56:00
Rhacoのオフィシャルサイトがなんか重いなァ
パフォーマンスでないのかな？

423:nobodyさん
08/05/06 16:59:32
結構作り込んである印象
なんでまったく話題に出なかったんだろ？

424:nobodyさん
08/05/06 17:36:05
>>416

それって他のFWもそうじゃない

その辺があまいのばっかだよなあ

425:nobodyさん
08/05/06 17:47:31
CIがあまいだけでは？

426:nobodyさん
08/05/06 17:48:55
>>418
おいおい。index.htmlを忘れているぞ。

hoge/moge/ だとmogeフォルダのindex.html（設定による）を参照すべきだろう？

427:nobodyさん
08/05/06 17:55:43
>>426
>>417-418は、まさにそう言ってるんだと思うが？

428:nobodyさん
08/05/06 18:14:00
いや、少し考えてみた。

URLが hoge/moge なら、一番最初に hoge/moge を探すべきだな。rewriteやaliasを含めて。
いきなり hoge/moge/ に書き換えるのは乱暴か

で、そうやって探して hoge/moge が見つからなかった時のみ、hoge/moge/(DirectoryIndex) と
するのが一応は順序かと思った。
>>426はそういう意味かな

429:nobodyさん
08/05/06 18:15:28
/hoge/mogeでも/hoge/moge/でもどっちでも
mogeがディレクトリ的存在だったら
/hoge/moge/index.html
が表示されるべきで、
その判断はサーバ側でおこなう。
最後の/の有無だけに、エンティティの判断基準を委ねない。
ってことだな

430:nobodyさん
08/05/06 18:16:27
なんかかぶったｗ

431:nobodyさん
08/05/06 18:20:13
>>430
結論は反対だけどねｗ

432:nobodyさん
08/05/06 18:22:19
ん？同じだろ？

433:nobodyさん
08/05/06 18:24:06
426…最後の/で判断するよ派
428・429…最後の/で判断しないよ派

これであってる？

434:nobodyさん
08/05/06 18:30:18
ってか
フレームワークのルータに/hoge/moge/index.htmlが渡ることって考えにくいな
素のリソースはmod_rewriteの設定で直接アクセスされるだろ

435:nobodyさん
08/05/07 00:29:19
/foo/barへのアクセスは
1./foo/barがファイルであるか確認
2./foo/bar/へリダイレクト（301 Moved Permanently）
が正しい動作のはず。

436:nobodyさん
08/05/07 01:08:20
何を基準にした「正しい」動作なの?

437:nobodyさん
08/05/07 01:32:49
俺もｵﾓﾀ。いったい何を基準に正しい・正しくないを議論しているのか…
独自アプリのルーティングの話で index.html がどうとかﾜｹﾜｶﾗﾝ
静的ファイルを表示するための httpd を書いていて
mod_dir に酷似した挙動をさせたいということならわからなくもないが、
>>416が聞きたいのはそういうことなのか?

438:nobodyさん
08/05/07 02:53:40
パスが変わるのでしないべき
妥協点はスラ付きへリダイレクト

が正解

439:nobodyさん
08/05/07 03:22:12
>>438に賛同。
SEO/SBO という面で考えれば、/ ありと / 無しをアプリ側で同一と見なすべきではない。
ただし、ユーザビリティを考慮すれば、/ 無しを / ありに 301 で転送 (またはその逆) をすることをするとなお良い。
参考 → URLﾘﾝｸ(pmakino.jp)

440:nobodyさん
08/05/07 06:16:35
なるほど
たしかにSEO的にリダイレクトする方がいいな
㌧㌧

441:nobodyさん
08/05/07 06:36:20
>>414
乗り遅れたけど、いい事言ってるなあ。
>>407とか>>415は流行に流されて本質を見失ってるな。

俺はテーブルと一対一になるモデル「じゃない」モデルクラスを作って対処してる。

442:nobodyさん
08/05/07 06:50:57
>>441
日本語が読みきれん。どっち？

テーブルと1:1に対応することを前提としないモデルクラスを作ってる
テーブルと1:1に対応する、内部の構造が隠蔽されていないから必ずしもモデルとは呼べない、モデルクラスを作ってる

前者だろうとは思うけど、一応。

443:nobodyさん
08/05/07 09:21:36
はぁ。テーブルと一対一にならなくても
モデルはモデルだろ。

444:nobodyさん
08/05/07 09:47:29
むしろ、テーブルと1:1になることを前提にするのは、内部構造に対する抽象化が制約されるという意味で、
モデリングとして不適切だと思ってる。

だから自分的には　>>443　は自明。
ただ、>>441 の言葉の意味が取りきれなかっただけ。

445:nobodyさん
08/05/07 09:56:24
クラスで使う例外って
クラスと同じファイルに書く？別にする？
例外クラスを1クラス1ファイル方式にすると
ファイルがとっちらかるよなぁ

446:nobodyさん
08/05/07 12:42:06
特定のフレームワーク上でのお作法の話ならずれてるかも知れんが、
自分の場合、自作の例外クラスって、せいぜい2個ぐらい (ユーザ操作系、システム異常系) しか作らない。

どんな例外であれ、rollbackしてエラーメッセージ出して終わりってのがほとんどだから、
クラス分けせずにエラーコードで区別してる。

447:nobodyさん
08/05/07 14:16:49
俺はタイプヒンティング使ってcatchするのに結構使うな

448:nobodyさん
08/05/07 20:53:16
>>446
せっかく例外という便利なものが使えるのに、
古臭く、使いづらく、バグが起こりやすい、
エラーコードを使う理由ってなに？

449:nobodyさん
08/05/07 21:11:53
>>448
例外の中でエラーコードを使うこと言うこと。
クラスの型で判別してないだけで、例外は使ってる。

450:nobodyさん
08/05/07 21:14:56
>>449　タイプミス訂正

例外の中でエラーコードを使っていると言う意味。
クラスの型で判別してないだけで、例外処理は使ってる。

451:nobodyさん
08/05/07 21:59:18
>>445
class なんとか_かんとか_Exception extends なんとか_Exception
{}

だけみたいなファイルが増えてくのはやっぱバカバカしいな

452:nobodyさん
08/05/07 23:57:23
というかPHPのtry catchはゴミすぎて使う気になれませんよｗ

453:nobodyさん
08/05/08 00:14:58
結局catch ～～で分岐するか、instanseof で分岐するか、
$e->getCode(), $e->getMessage() で分岐するか、の違い
しかないとか思っちゃうんだが、わかってないってことだと
自分でも思う

454:nobodyさん
08/05/08 00:29:40
MVC要らんな。
長い目で見たら実は激しく開発効率が落ちるよな。
みんなとっくに気付いてるだろ。
もうMVCなんて発掘された化石にしがみつくのはやめようぜ。

テンプレートに全部書くに限る。
冗談抜きで、コピペでいい。
変更は該当ファイルを変更。
追加は新規作成。
そもそもPHPはこの形で爆発的に伸びてきた。
ものすごい速さで「ページ」を量産できてきたわけだ。
PHPと比較してはるかにHTMLを苦手とする他の言語の実装にすりよる必要なんてない。

コードが醜悪で結構。
メンテし難い？
いやいや、HTML部分はどんな初心者でも理解可能だからさっさと読み飛ばすわけだ。
そして残ったPHP処理部分がMVCを捨ててページ単位で完結して書いてある。
完結しているのだから、追っていくだけで全容が分かるわけだ。
汚い素のPHPファイルが開発効率に優れている理由はここにある。

何かを試験的に作るとき、さっさとPHPというテンプレートで書いちゃうだろ。
たぶん、数時間あれば、第三者に見せられる程度の単機能ページを作れるだろ。
その試作品でいいんだよ。
一週間かけたものと何も変わんねえから。
つまりその試作品で50万くらい請求できるわけだ。
あるいは、10万に値下げできるわけだ。

頭冷やそうぜ。
PHPそのものが実利の塊なんだから、無理して加工すんなって。無駄な汗を流すなよ。
どうしても加工してPHPらしくない別フレームワークを作りたければ、C++で本気で作れ。PHPでやるな馬鹿外人。

455:nobodyさん
08/05/08 00:42:41
>>454
プログラマとしては気に入らないけど、現場レベルだとコピペ嵐の方が修正時の影響範囲が
限定的だから現実的だというのは、認めないわけでもない。

カラシニコフ的アーキテクチャとでも言うべきか。

456:nobodyさん
08/05/08 00:55:28
>>454
修正が体力勝負になるから嫌気がさすっていうのもあるんだよｗ
ポリシーと一貫性があるならいいが、どうせ修正がかさむにつれ
AとA'とA''とABとA''Bみたいなソースが量産されてくるんだろ

一字一句変えずにコピペできる所なんてそう無い。大概コピペ先で
修正されてdiffとったりしたら目を覆うような作業量になる

それでも、「可能」かどうかをいうなら、修正は可能だし、８割くらいの
作業が速く済む、っていうのはうなずけなくもないけど

457:nobodyさん
08/05/08 02:02:54
PHPの場合、try catchの例外処理機構が駄目なんじゃ無くって、組み込み関数がエラーで例外吐かないのが糞。

458:nobodyさん
08/05/08 04:09:14
>>454
なるほど
ベタ書き→PHP
MVC→他の言語
と使い分けてもいいかもね

PHP以外なら何がいいだろ？

459:nobodyさん
08/05/08 05:17:56
俺もPHP使ってるけど確かにそういうことを考えたりする。
>>454はちょっと乱暴な文体だけど言いたいことはわかる。
これは何もスパゲティなコード書けということではなくて
もちろんメンテしやすいように努力はするのだけれど
そのために果たしてMVCやオブジェクト指向が必要かどうかといえば
必ずしも必要ではないかもしれない。
我々は何もPHPしか使えないわけではないのだから
PHPを使う時は割り切ってページ単位でディレクトリ階層もわかりやすく
作っても良いのかもしれない。
正直、最近PHPフレームワークについて興味があったんだが、
再度PHPの良さについて考えてみよう。

460:nobodyさん
08/05/08 06:45:47
テストのしやすさとか
開発効率とか
安定性を求めれば
結局MVCに戻ってくることになる。
おつかれさんｗ

461:nobodyさん
08/05/08 08:00:22
実利を求めたらオブジェクト指向に落ち着くだろ

462:nobodyさん
08/05/08 08:20:17
どうだろうね。プログラマは確保できるけど能力的には怪しいっていう環境なんかだと、
エレガントな設計はむしろ罪悪じゃないかと思うし、残念ながらそういう環境は多い。

逆に言えば >>454 は、人海戦術で対応可能な仕事でないと成立しないんじゃないかとも思うが、
エレガントさをあきらめれば、人海戦術で対応できない仕事なんてそうないし。

463:nobodyさん
08/05/08 08:43:03
PHPの特徴はPHPとHTMLが混在できるということだよな。
この混在をViewが分離してないので悪と捉えるならば、
PHPの特徴も悪ということになる。
それでそのPHPの特徴を無くしたMVCなフレームワークを使うことになるんだが、
それじゃPHPを使ってる意味とは何なんだろうか。
別の言語のMVCフレームワークでも良いという結論になってしまうんじゃないか。

別にMVCなフレームワークが悪いと言ってるんじゃない。
ただ、PHPの特徴を活かした使い方があるんじゃないだろうか。
昔ながらのロジックとビューをファイルの上下で分割するような次のような使い方でも。
-------------
<?php
//設定や共通関数のinclude

//PHPによる処理
$a = 1;
?>
<html>
...
<?php echo $a; ?>
</html>

次ページ