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

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

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>

464:nobodyさん
08/05/08 09:39:12
> 別の言語のMVCフレームワークでも良いという結論になってしまうんじゃないか。
そのとおりだよ。

ただ、フレームワークも込みで、どこのレンタルサーバーで動くようなものはPHPしかない。

Rubyは言語辞退は一定な買ったりバージョンが古いし、
Perlはフレームワークや、必要なライブラリをインストールするのに
Shellやある程度の権限がいる。

PHPとPHP製フレームワーク・ライブラリは、ほとんどが
ファイル配置ですむからね。

あぁ、これがPHPを使っている意味かｗ

465:nobodyさん
08/05/08 09:40:21
Rubyは言語自体入ってなかったりバージョンが古いし、

466:463
08/05/08 10:10:38
>>464
そうなんだよ、現実を考えるとPHPを使いたいというよりは
PHPを使わざるを得ない、という感じなんだよ。
そして使わざるを得ないPHPでPHPの特徴を消すようなフレームワークを使う。
このジレンマというかもやもやしたものが俺の中に常にある。

>Rubyは言語辞退は一定な買ったりバージョンが古いし、
>Perlはフレームワークや、必要なライブラリをインストールするのに
>Shellやある程度の権限がいる
これはレンタルサーバ屋によるというか、PHPも最新バージョンを使いたい
（特にセキュリティホール絡みで）時は、結局自分で最新版をコンパイルすることになって
権限やShellが必要になるので、ほんと、レンタルサーバ屋によるとしか言えないな。

467:nobodyさん
08/05/08 11:24:56
ベタ書き＝PHP＋XREA
MVC＝Python＋Google App Engine
がいいかな？

468:nobodyさん
08/05/08 11:33:59
悪くないんじゃね。適材適所？
GoogleAppEngineは本サービスの内容次第だけど

469:nobodyさん
08/05/08 12:49:25
FWと独立したORMがもっとでてこねーかな
好きなFWに好きなORMを組み合わせるみたいな使い方が一般的になればいいのに

470:nobodyさん
08/05/08 12:54:43
直SQLで十分。

471:nobodyさん
08/05/08 13:01:46
ﾃｨﾝﾎﾟﾆｰの新しいヘルパって
クラスメソッドになったんだっけ？
<?php echo HogeHelper::url_for('default/poge')?>
みたいな風に書くの？長くね？

472:nobodyさん
08/05/08 13:20:40
>>466
本末転倒になってね？

PHPの（いけてない）特徴を消すのが何が悪いの？

473:nobodyさん
08/05/08 14:41:46
いけてないPHP？
綺麗事抜きでドラスティックに行きましょうや

ベタ書き＋直SQL ＝ PHP＋XREA
MVC＋ORM ＝ Python＋Google App Engine

簡単にできることを複雑にやる必要はない
Python、Java等と使い分けて適材適所で

474:nobodyさん
08/05/08 14:52:22
開発言語なんて自由に選べるものでもないし、
サーバーサイドで複数の言語が混在したシステムなんて考えたくもない。
ただ、PHPの言語仕様がさほど特徴的とも思わない。

自分は標準ライブラリが整備されてて、メジャーだからPHP使ってる。

475:nobodyさん
08/05/08 15:13:05
>>473
まず、君は何の為にデザインとロジックの分離という
考え方が存在するのか、なぜORMというものが存在するのか、
その理由を知ったほうがいい。

話はそれからだ。

（そのあとで、なぜPHPにはそれが当てはまらないというんだ？と聞く予定）

ついでに、なぜテンプレートを使えば、
RubyやPythonでも、PHPと同じようにHTMLの中にロジックを
書くことが出来るわけだが、なぜその方法を使わないのか。
君はこっちのほうが簡単だ。といいたいんだろう？

476:nobodyさん
08/05/08 21:45:25
>>475
で、どれがデザインとロジックの分離できてるわけ?
Rails? JSF? Django? どれもできてないじゃん。
実際できるのがあったとして、それはメジャーなん? 使い物になるだけの速さでるの?
できてもない『デザインとロジックの分離』という幻想を抱いて死んでくれ。

おれは断然>>454支持するぜ。

477:nobodyさん
08/05/08 22:39:24
まあ極端にならんと。
どっちの利点も判らんでもないけど、中庸ってのも考えなきゃ
妥協点ともいうか

たとえ幻想でも雑魚をまとめる旗印にはなるしw

478:nobodyさん
08/05/09 00:59:50
自分が楽な作り方を選べばいいじゃん。
一人でちっさなツール作るなら、べたに書けばいいんじゃね？

中規模以上のものを作るにはMVCが作りやすいがね。

479:nobodyさん
08/05/09 02:21:08
プログラムとは一言でいえば「データ＋処理」
それ以上でもなければ、それ以外でもない

WEBアプリ＝DBラッパー

DOA→ベタ書き＋直SQLで充分
OOA→MVC＋ORMで楽できる

フレームワークは他人の知恵を借用して楽できるツール＝使わなきゃ損
普段フレームワークを使っていれば、逆にフレームワークを使うまでもない状況かどうか判断できるはずだよね？

お問合せメールフォーム１ページ作るのにsymfony使ってますとかは漫才ｗｗｗ

480:nobodyさん
08/05/09 03:21:13
インプットチェックで異常があったらフォームを再表示みたく、処理結果によって表示するページが
異なったり、複数の処理結果に対して同じページを表示したいことがあるのは普通だから、
ビューを分離するのは良いんだけど、DBアクセスは、同じ処理をしたいことは多くないし、
無理にまとめるとパフォーマンスが劣化するから、モデルとしてまとめることに利点があるのかは疑問。

コントロールも、自分の場合トランザクション前の処理、トランザクション中の処理、トランザクション後の処理、
次のページ取得を呼び出すクラス作って継承する程度で十分間にあってる。

ビューについては、そもそもがベタ書きみたいなもんだし。

フレームワークは、特定のフレームワークが業界内において支配的な立場になり、
その上で動作する使い勝手が良いパーツが流通しなければ、大してメリットなんかないと思ってる。

ソースコードの可読性は考慮すべきだけど、フレームワークを導入しただけで可読性がよくなる
わけじゃないし、フレームワークを導入しただけで大きなメリットがあるわけでもないなら、
フレームワーク使うべきって論はどうかなぁって思う。

481:nobodyさん
08/05/09 13:09:55
フレームワーク使うべきかどうかってそういう次元の話じゃなくて、
単にフレームワークを使ったほうが楽だから使うだけだよ。

> DBアクセスは、同じ処理をしたいことは多くないし、
同じ処理あるよ。検索処理や、検索結果を扱いやすいように
構造化されたハッシュ・配列に入れる処理。
JOINしたときとか、二次元の表よりも階層化された
配列に入ってくれたほうが楽だよね。

> その上で動作する使い勝手が良いパーツが流通しなければ、大してメリットなんかないと思ってる。
意味がわからん。PEARライブラリとか普通に使えるだろ。
フレームワーク専用のパーツなら、普通に使い勝手が良いパーツが組み込まれている。

だからこそ便利であり、使うんだが。

> フレームワークを導入しただけで可読性がよくなるわけじゃないし
良くある言い方だね。銀の弾丸じゃないならメリットがないとする極端な考え方。

銀の弾丸なんて存在しない。だけど普通の弾丸なら存在する。
弾丸が効かない敵がいたって、効く敵もいるんだから弾丸はあったほうがいいだろ。

フレームワークを導入すると、可読性が良くなる場合もあるし
少しでもメリットがあるのなら、あったほうがいいだろ。

482:nobodyさん
08/05/09 21:42:19
>>475
>まず、君は何の為にデザインとロジックの分離という
>考え方が存在するのか、なぜORMというものが存在するのか、
>その理由を知ったほうがいい。
>
>話はそれからだ。

なにこのえらそうなバカ。おまえはデザインとロジックの分離ができてるの?
こんだけえらそうに語ってるんだから、きっと完全な分離ができるんだろう。
で、どれを使ったらできるの? Symfony? Cake?
教えて、コーマンチキな475さん

483:nobodyさん
08/05/09 22:56:26
「話はそれからだ」ってのは「理由は聞かないで下さいっ >_<」って意味なんだから、そっとしといてやれよ。

484:nobodyさん
08/05/09 23:11:23 a3XtheQg
>>482
>>475じゃないけどsymfony+smarty使ったことあるかい？

しかしMVCは良いとしてもO/Rマッパはなんとかならんもんかね

485:nobodyさん
08/05/10 01:24:53
>>484
あんな糞なもん使ったって何の自慢にもならねーよｗ

まあ、sfSmartyPlugin（だっけか）の品質の問題はともかく、
デザインにもロジックはあるのだよ。

ORMはおかしいよな。テーブルとモデルが一対一になってる。
おかしいのはPropelだけなのかもしんないけど。
そんなの変だよ、当たり前じゃないか、みたいなレスを貰ったのでほっとした。

486:484
08/05/10 03:06:24
>>485

>>デザインにもロジックはあるのだよ。
それ言ったらjspも(ry

>>ORMはおかしいよな。テーブルとモデルが一対一になってる。
いや別に。
漏れがどうにかしてほしいと思っているのはpropelの使い方だけ。
doctrineもpropelもSQL文直打ちしていた人からしたら使いづらいと思うんだよね。
executeQuery()使えばいいんだけど、それだとO/Rマッパーの意味ないしな。

>>そんなの変だよ、当たり前じゃないか、みたいなレスを貰ったのでほっとした。
フレームワーク反対派に賛同したつもりはないんだが・・・・・。
ある程度規模でかくなればクラス分割してlib配下に設置してあげるだけでオートロードしてくれたりするから再利用も行いやすい。
フレームワークは結構便利だと思う。
でもそこまででかくならないんだったら別にいらないよなーって感じじゃね。
symfonyぐらいのフレームワーク使うんだったらメリットでかいと思うけどCakePHPやPiece Frameworkレベルだと別になくても良い様な希ガス。

487:nobodyさん
08/05/10 10:23:21
小さいのを作るにはフレームワークを使わなくても出来るけど、
大きいのを作るにはフレームワークを使ったほうが便利。

便利な方法と、不便な方法。どちらを選ぶかは
考えるまでも無い。

488:nobodyさん
08/05/10 10:26:41
>>485
> デザインにもロジックはあるのだよ。

そうだね。でどうしろと？

どうせデザインにロジックがあるのだから、
各自勝手に作れといわんだろ？

あんた極端なんだよ。完璧じゃなければ必要ないとか考えてるだろ。

もう少しバランス感覚養ったほうがいいんじゃないのか？
1か0じゃなくて、どちらのほうが優れているかで話をしろ。

489:nobodyさん
08/05/10 11:47:06
JavaのApache Wicketというフレームワークは
テンプレートにHTMLを使う。
JSPみたいな独自タグや{hoge}みたいな独自識別子を使わない。
現状のWicketが完璧とは言わないけど（メジャーとは言い難いし）、
その方向性はいいなと思える。

ViewはHTMLのテンプレートを使って
ロジックはどの言語でもいい、みたいなもの（Viewテンプレートとロジックのブリッジみたいなもの？）ができれば
言語やフレームワークごとにViewの独自タグや独自識別子を使い分けなくてよくなると思うんだけどな。

490:nobodyさん
08/05/10 12:08:18
即席で作るだけなら生書きの方が速いことも多いが
保守を考えるとフレームワーク使わないときついだろ

491:nobodyさん
08/05/10 22:09:04
>>485

> ORMはおかしいよな。テーブルとモデルが一対一になってる。
おかしい理由は？

DAOとしての面ではあるテーブルに対する操作が一つのクラスに集約されるから見通しが良くなるが。

492:nobodyさん
08/05/10 22:28:21
SQLって単体のテーブルごとにアクセスするものではないからだと思う。
パフォーマンスを考慮したSQLとの相性は悪いんじゃなかろうか。

493:nobodyさん
08/05/10 23:26:26
>>492
結合する処理をモデルに実装するから、そうでもないよ。
例えばユーザを結合したコメント一覧を取得するアクセスロジックをコメントモデルに持たせるとか。
ORMがアソシエーション機能を提供してたりもするし(あまり好きではないけど)。

Someモデルはsomeテーブル以外を知ってはならないということはないと思う。特にActiveRecordでは。

494:nobodyさん
08/05/11 00:27:11
runkitでaopみたいなことしたかったけど
セッションハンドラに登録したメソッド書き換えたら
segmantation fault出るようになった
やっぱまだ不安定なんだな・・・面白い拡張なんだが

495:nobodyさん
08/05/11 00:39:19
俺485。おまいらレスありがとう。
でも書いてもらった日本語がよくわからない。
俺もいいかげんな発言してたので、真面目に書き直しておく。

>>486
お前は本当にsfSmartyViewPluginを使ったのか？
sfSmartyViewPluginを使わないでsymfonyで開発した事があるか？

sfSmartyViewPluginがビューとロジックの分離における有効策と考えてるなら、
それはあまりにもロジックを排除する事に対して神経質になりすぎだと思う。

symfonyは標準ではPHPの構文をテンプレートファイルに記述する。
確かにこの書き方だとHTML内にロジックが書けてしまうので束縛が無い事が嫌かも知れないが、
ビューにはビューを成立させるためのロジックがあっても良いと俺は考える。

496:nobodyさん
08/05/11 00:43:17
俺は485なんだけど441でもある。
>>485の後半に書いた事は>>484に言ったというより、過去のレスへの返答だった。

>>442
前者です。

>>443-444
自明だよな。その書き込みを見てほっとしたぜ。

ってことだった。

497:nobodyさん
08/05/11 00:50:47
つーか休まないと日本語処理能力が低下しまくっていかんな。

>>488
sfSmartyViewPluginよりもsymfony標準のテンプレート書式の方が優れている。
というか、sfSmartyViewPluginは完璧に使い物にならないと心底思う。
sfSmartyViewPluginは足かせにこそなれ、利便性は何も齎してくれない。

反論はあるだろうけど、ビューに制約を課す事とMVCを考慮する事は全く別だと思う。

>>491
結合とはある単一のテーブルが行う処理ではないから。

498:nobodyさん
08/05/11 01:04:31
一対一でマッピングされてるからって
そのテーブルに対して「のみ」のモデルじゃない

499:nobodyさん
08/05/11 03:58:08
いまだにsmartyとか言ってる意味がわからん
検討にすら値しないだろ

500:nobodyさん
08/05/11 04:09:26
結局viewヘルパってどれがいいんだろうな？
・関数
・クラスメソッド
・$this(viewクラスあるいはcontrollerクラスのインスタンス）のメソッド
・$this以外の、view空間にassignされたオブジェクトのメソッド
個人的には最後のものに可能性を感じるが・・・
状態を持ちやすい、動的に変化させやすいという意味で。
複数のクラスのメソッドを集めるmixin的な機能が要りそう。
そこがキレイにできれば・・

501:484
08/05/11 05:00:31
>>495

>>お前は本当にsfSmartyViewPluginを使ったのか？
>>sfSmartyViewPluginを使わないでsymfonyで開発した事があるか？
当たり前

>>それはあまりにもロジックを排除する事に対して神経質になりすぎだと思う。
おまい日曜プログラマ？プロジェクト内にテンプレート側にがちごりでロジック書くウンコいたらどうすんの？
デザイン変更したい～なんてお客さんから要望あったらデザイナーにテンプレート渡すだろ？
テンプレート側にロジックかかれたら・・・・・後はわかるよな。
使わなくていいんだったら漏れもつかわねーよ。プラグイン入れるのﾏﾝﾄﾞｸｾ

502:nobodyさん
08/05/11 08:41:33
>>484
>symfony+smarty使ったことあるかい？
smartyで「デザインとロジックの分離」が実現できるとでも思ってるの? バカ?

>>485
> デザインにもロジックはあるのだよ。
そのとーり。WicketやMayaaやTapestryでは確かに「デザインとロジックの分離」ができるけど、smartyなんかじゃ全然できない。

>>488
> そうだね。でどうしろと？
おまえはなにもするな。smartyごときで「デザインとロジックの分離」とか偉そうに語るな。

> あんた極端なんだよ。完璧じゃなければ必要ないとか考えてるだろ。
完璧にほど遠いものをさも完璧なように語るおまえがバカなだけ。
PHPにはWicketもMayaaもないんだから、デザインの分離なんか考えるだけ無駄。

> もう少しバランス感覚養ったほうがいいんじゃないのか？
> 1か0じゃなくて、どちらのほうが優れているかで話をしろ。
他人の言葉をうのみにしているおまえこそ、もっと現実をみたほうがいい。
実現できてもないことに、1も0もないだろ。バッカじゃない?

503:nobodyさん
08/05/11 08:51:20
>>498
そういう解釈をいれないといけないあたり、相性が悪いんじゃないかと。
出来ないって話はしてないつもり。

そもそもモデリングってのは本質的ではないものを隠蔽したり相殺したりして
扱いやすくするものだと理解してるんだが、パフォーマンス的なことを考えると
SQLはそれ自体が本質的で、隠蔽されるべき対象ではないと思う。

機能的なことだけ考えれば良いのなら、SQLを隠蔽するのは正しいだろうけど、
それは贅沢だなぁって思う。

504:nobodyさん
08/05/11 09:50:03
モデリングの時点でオブジェクト間の関連は定義されるんだから相性が悪いということはないと思うけどな。
設計(仕様)上、記事テーブルがユーザテーブルに依存するなら、記事モデルがユーザモデル(テーブル)を知っていていいし、依存してもいい。

ただ、今までORMレイヤをリリースしてきた人達が「SQLを書かなくていいよ！楽チンだよ！」ってところを押しすぎたのは良くない。
複雑なフェッチが必要な場合はSQLを発行して結果を返すメソッドをモデルに持たせればいいのに、
「(極端に言えば)SQLを書いちゃいけない」という固定観念のもと、SQL以上に複雑な手続きによるフェッチだったり、
複数回SQLが発行されることを厭わない実装がある。

バランスとれればいいんじゃないかな。多くの部分ではSQL書かずに楽するし、SQLが必要なら(モデル内に)SQLを書く。

SQL書いたらORMが謳う「簡単なデータベースの切り替え」ができなくなるって？
大丈夫。開発中にデータベースが変更になることはまずないし、「ついで」程度の機能でしかない。

505:nobodyさん
08/05/11 13:40:27
オープンソースのフレームワーク開発ってどういうビジネスモデルなんだろ？
symfonyとかciは企業が作ってるけど
どこで利益あげてるのかな？
知名度を上げて受注を増やす形？

506:nobodyさん
08/05/11 14:20:23
ひょっとしてそれはギャグで（ｒｙ

507:nobodyさん
08/05/11 14:24:05
いやギャグじゃないよ
どこからか金が環流しないと時間と労力投入できないじゃん

508:nobodyさん
08/05/11 14:44:30
>>502
お前の言うデザインとロジックの分離っていうものはいったいどれぐらいのレベルを言ってるんだ

それにしてもヒステリックなやつだな
もうちょっと落ち着けよ
お前みたいな趣味でやっているやつにはMVCはいらないと思うけど現場では実際に必要とされてるんだよ

509:nobodyさん
08/05/11 14:49:35
デザインとロジックの無意味な議論うぜぇ

510:nobodyさん
08/05/11 15:03:35
>>508
>>502じゃないが、デザインとロジックの分離のレベルは
WicketやMayaaレベルを言ってるんだろう。
俺も分離するならそのレベルが妥当だと思う。

逆にそのレベルで分離できないなら、
開発者には必要とされてもデザイナには使いにくいことに変わりないと思う。

511:nobodyさん
08/05/11 15:25:06
>>510
んなこたーない。ロジックが書かれたphpファイルより全然いいだろ。
.htmlファイルを直接テンプレートとして使えるし部分的にロジックが入るようであればそこはプログラマが修正してあげればいい。
そもそも一番のメリットは上に書いたがテンプレートにロジック書くようなｳﾝｺ野郎を排除するところだし。

512:nobodyさん
08/05/11 15:54:25
>>511
>んなこたーない。ロジックが書かれたphpファイルより全然いいだろ。
>.htmlファイルを直接テンプレートとして使えるし部分的にロジックが入るようであればそこはプログラマが修正してあげればいい。
すまんが主語は何だ。smartyが、か？
WicketやMayaaはテンプレートがHTMLなので（独自タグや{if}等が無い）、
HTMLしかしらないデザイナも扱いやすいし、
HTML編集ソフトでテンプレートを読み込んで修正しやすいのがメリットなんだが、
そんなメリットは必要ないってことか？

513:nobodyさん
08/05/11 15:55:42
RDB使ってる時点でSQL便利は自明
SQLイヤならOODB使うしかない

514:nobodyさん
08/05/11 16:05:35
Javaのテンプレートには、PHPのSmartyよりも優れたものがあるんですね。
参考になります。
ついでにPHPにも移植してください。

Wicket
URLﾘﾝｸ(www.wicket-ja.org)

Mayaa
URLﾘﾝｸ(mayaa.seasar.org)

515:nobodyさん
08/05/11 16:19:02
>>513
そう、SQLってかなり完成度高いんだよね。

SQLで拾った値でインスタンス作っても作らなくてもいいんだけど、
拾うためにインスタンス作るのに何のメリットがあるのか。

SQLをラップするのって、正規表現が分からない人向けに正規表現エンジンをラップして
簡単なテキスト検索エンジンを作ってるような気持ち悪さを感じる。で、正規表現をつかう
抜け道も用意してありますみたいな。

516:nobodyさん
08/05/11 17:42:48 tIr1XyIc
>>512
先生、WicketやMayaaをsymfonyと連携させる方法を教えてください＞＜
smarty使わないので教えてください＞＜

517:nobodyさん
08/05/11 17:43:09
sage忘れちゃったよ
ごめんね

518:nobodyさん
08/05/11 17:49:27
SMTPのプロトコルが分からない人向けにその部分をラップして
簡単にメールを送信するmail()関数がある。で、プロトコルしゃべる
抜け道も用意してある。

SQLラップするのも正規表現ラップするのも同じ。ライブラリとはそういうもの。

519:nobodyさん
08/05/11 17:52:41
SMTPはプロトコルとしての完成度高く無いじゃん。ただの規格。

520:nobodyさん
08/05/11 17:58:59
>>519
ん？完成度が高いものはラップする必要なく、低いものはラップして当たり前ということ？

521:nobodyさん
08/05/11 18:49:51
ラップの必要性の比較で言えばいうまでもなくそうだろ

522:nobodyさん
08/05/11 19:01:31
まぁ抜け道が前提のラッパーを見て、何も感じないなら、それはそれで才能だと思う。
PG/SIerとしては、そっちのほうが幸せかもしれん。

523:nobodyさん
08/05/11 19:19:10
>>521
で、その完成度の高い低い、ラップすべきしないべきは誰が決めんの？
結局自分の趣味趣向で言ってるだけなんだよなぁ。

524:nobodyさん
08/05/11 21:01:26
>>501
> プロジェクト内にテンプレート側にがちごりでロジック書くウンコいたらどうすんの？

クビにするべきだろう。

> デザイン変更したい～なんてお客さんから要望あったらデザイナーにテンプレート渡すだろ？

テンプレートを渡すという事は、責任を渡すという事と同義だよ。

> 使わなくていいんだったら漏れもつかわねーよ。プラグイン入れるのﾏﾝﾄﾞｸｾ

こう言ってるって事は、理不尽さを感じながら妥協をしていて、それを愚痴ってるんだと思うんだが、
たぶんプログラムに制限を課すより、体制を考えなおしたほうがいいと思うぞ。

たとえば、ウンコ書くプログラマが居る可能性がある時に、
そのプログラマが極力コードを書けないように制限する事は困難だと思う。
制限を課す事に手間を割くくらいなら、生産性のある作業に注力した方が良いんでないかい。

次ページ