- 1 名前：nobodyさん mailto:sage [2008/02/09(土) 10:43:58 ID:???]
- 前スレ
pc11.2ch.net/test/read.cgi/php/1197383840/
- 440 名前：nobodyさん mailto:sage [2008/05/07(水) 06:16:35 ID:???]
- なるほど
たしかにSEO的にリダイレクトする方がいいな
㌧㌧
- 441 名前：nobodyさん mailto:sage [2008/05/07(水) 06:36:20 ID:???]
- >>414
乗り遅れたけど、いい事言ってるなあ。
>>407とか>>415は流行に流されて本質を見失ってるな。
俺はテーブルと一対一になるモデル「じゃない」モデルクラスを作って対処してる。
- 442 名前：nobodyさん mailto:sage [2008/05/07(水) 06:50:57 ID:???]
- >>441
日本語が読みきれん。どっち？
テーブルと1:1に対応することを前提としないモデルクラスを作ってる
テーブルと1:1に対応する、内部の構造が隠蔽されていないから必ずしもモデルとは呼べない、モデルクラスを作ってる
前者だろうとは思うけど、一応。
- 443 名前：nobodyさん mailto:sage [2008/05/07(水) 09:21:36 ID:???]
- はぁ。テーブルと一対一にならなくても
モデルはモデルだろ。
- 444 名前：nobodyさん mailto:sage [2008/05/07(水) 09:47:29 ID:???]
- むしろ、テーブルと1:1になることを前提にするのは、内部構造に対する抽象化が制約されるという意味で、
モデリングとして不適切だと思ってる。
だから自分的には >>443 は自明。
ただ、>>441 の言葉の意味が取りきれなかっただけ。
- 445 名前：nobodyさん mailto:sage [2008/05/07(水) 09:56:24 ID:???]
- クラスで使う例外って
クラスと同じファイルに書く？別にする？
例外クラスを1クラス1ファイル方式にすると
ファイルがとっちらかるよなぁ
- 446 名前：nobodyさん mailto:sage [2008/05/07(水) 12:42:06 ID:???]
- 特定のフレームワーク上でのお作法の話ならずれてるかも知れんが、
自分の場合、自作の例外クラスって、せいぜい2個ぐらい (ユーザ操作系、システム異常系) しか作らない。
どんな例外であれ、rollbackしてエラーメッセージ出して終わりってのがほとんどだから、
クラス分けせずにエラーコードで区別してる。
- 447 名前：nobodyさん mailto:sage [2008/05/07(水) 14:16:49 ID:???]
- 俺はタイプヒンティング使ってcatchするのに結構使うな
- 448 名前：nobodyさん mailto:sage [2008/05/07(水) 20:53:16 ID:???]
- >>446
せっかく例外という便利なものが使えるのに、
古臭く、使いづらく、バグが起こりやすい、
エラーコードを使う理由ってなに？
- 449 名前：nobodyさん mailto:sage [2008/05/07(水) 21:11:53 ID:???]
- >>448
例外の中でエラーコードを使うこと言うこと。
クラスの型で判別してないだけで、例外は使ってる。
- 450 名前：nobodyさん mailto:sage [2008/05/07(水) 21:14:56 ID:???]
- >>449 タイプミス訂正
例外の中でエラーコードを使っていると言う意味。
クラスの型で判別してないだけで、例外処理は使ってる。
- 451 名前：nobodyさん mailto:sage [2008/05/07(水) 21:59:18 ID:???]
- >>445
class なんとか_かんとか_Exception extends なんとか_Exception
{}
だけみたいなファイルが増えてくのはやっぱバカバカしいな
- 452 名前：nobodyさん mailto:sage [2008/05/07(水) 23:57:23 ID:???]
- というかPHPのtry catchはゴミすぎて使う気になれませんよｗ
- 453 名前：nobodyさん mailto:sage [2008/05/08(木) 00:14:58 ID:???]
- 結局catch ～～ で分岐するか、instanseof で分岐するか、
$e->getCode(), $e->getMessage() で分岐するか、の違い
しかないとか思っちゃうんだが、わかってないってことだと
自分でも思う
- 454 名前：nobodyさん mailto:sage [2008/05/08(木) 00:29:40 ID:???]
- MVC要らんな。
長い目で見たら実は激しく開発効率が落ちるよな。
みんなとっくに気付いてるだろ。
もうMVCなんて発掘された化石にしがみつくのはやめようぜ。
テンプレートに全部書くに限る。
冗談抜きで、コピペでいい。
変更は該当ファイルを変更。
追加は新規作成。
そもそもPHPはこの形で爆発的に伸びてきた。
ものすごい速さで「ページ」を量産できてきたわけだ。
PHPと比較してはるかにHTMLを苦手とする他の言語の実装にすりよる必要なんてない。
コードが醜悪で結構。
メンテし難い？
いやいや、HTML部分はどんな初心者でも理解可能だからさっさと読み飛ばすわけだ。
そして残ったPHP処理部分がMVCを捨ててページ単位で完結して書いてある。
完結しているのだから、追っていくだけで全容が分かるわけだ。
汚い素のPHPファイルが開発効率に優れている理由はここにある。
何かを試験的に作るとき、さっさとPHPというテンプレートで書いちゃうだろ。
たぶん、数時間あれば、第三者に見せられる程度の単機能ページを作れるだろ。
その試作品でいいんだよ。
一週間かけたものと何も変わんねえから。
つまりその試作品で50万くらい請求できるわけだ。
あるいは、10万に値下げできるわけだ。
頭冷やそうぜ。
PHPそのものが実利の塊なんだから、無理して加工すんなって。無駄な汗を流すなよ。
どうしても加工してPHPらしくない別フレームワークを作りたければ、C++で本気で作れ。PHPでやるな馬鹿外人。
- 455 名前：nobodyさん mailto:sage [2008/05/08(木) 00:42:41 ID:???]
- >>454
プログラマとしては気に入らないけど、現場レベルだとコピペ嵐の方が修正時の影響範囲が
限定的だから現実的だというのは、認めないわけでもない。
カラシニコフ的アーキテクチャとでも言うべきか。
- 456 名前：nobodyさん mailto:sage [2008/05/08(木) 00:55:28 ID:???]
- >>454
修正が体力勝負になるから嫌気がさすっていうのもあるんだよｗ
ポリシーと一貫性があるならいいが、どうせ修正がかさむにつれ
AとA'とA''とABとA''Bみたいなソースが量産されてくるんだろ
一字一句変えずにコピペできる所なんてそう無い。大概コピペ先で
修正されてdiffとったりしたら目を覆うような作業量になる
それでも、「可能」かどうかをいうなら、修正は可能だし、８割くらいの
作業が速く済む、っていうのはうなずけなくもないけど
- 457 名前：nobodyさん mailto:sage [2008/05/08(木) 02:02:54 ID:???]
- PHPの場合、try catchの例外処理機構が駄目なんじゃ無くって、組み込み関数がエラーで例外吐かないのが糞。
- 458 名前：nobodyさん mailto:sage [2008/05/08(木) 04:09:14 ID:???]
- >>454
なるほど
ベタ書き→PHP
MVC→他の言語
と使い分けてもいいかもね
PHP以外なら何がいいだろ？
- 459 名前：nobodyさん mailto:sage [2008/05/08(木) 05:17:56 ID:???]
- 俺もPHP使ってるけど確かにそういうことを考えたりする。
>>454はちょっと乱暴な文体だけど言いたいことはわかる。
これは何もスパゲティなコード書けということではなくて
もちろんメンテしやすいように努力はするのだけれど
そのために果たしてMVCやオブジェクト指向が必要かどうかといえば
必ずしも必要ではないかもしれない。
我々は何もPHPしか使えないわけではないのだから
PHPを使う時は割り切ってページ単位でディレクトリ階層もわかりやすく
作っても良いのかもしれない。
正直、最近PHPフレームワークについて興味があったんだが、
再度PHPの良さについて考えてみよう。
- 460 名前：nobodyさん mailto:sage [2008/05/08(木) 06:45:47 ID:???]
- テストのしやすさとか
開発効率とか
安定性を求めれば
結局MVCに戻ってくることになる。
おつかれさんｗ
- 461 名前：nobodyさん mailto:sage [2008/05/08(木) 08:00:22 ID:???]
- 実利を求めたらオブジェクト指向に落ち着くだろ
- 462 名前：nobodyさん mailto:sage [2008/05/08(木) 08:20:17 ID:???]
- どうだろうね。プログラマは確保できるけど能力的には怪しいっていう環境なんかだと、
エレガントな設計はむしろ罪悪じゃないかと思うし、残念ながらそういう環境は多い。
逆に言えば >>454 は、人海戦術で対応可能な仕事でないと成立しないんじゃないかとも思うが、
エレガントさをあきらめれば、人海戦術で対応できない仕事なんてそうないし。
- 463 名前：nobodyさん mailto:sage [2008/05/08(木) 08:43:03 ID:???]
- PHPの特徴はPHPとHTMLが混在できるということだよな。
この混在をViewが分離してないので悪と捉えるならば、
PHPの特徴も悪ということになる。
それでそのPHPの特徴を無くしたMVCなフレームワークを使うことになるんだが、
それじゃPHPを使ってる意味とは何なんだろうか。
別の言語のMVCフレームワークでも良いという結論になってしまうんじゃないか。
別にMVCなフレームワークが悪いと言ってるんじゃない。
ただ、PHPの特徴を活かした使い方があるんじゃないだろうか。
昔ながらのロジックとビューをファイルの上下で分割するような次のような使い方でも。
-------------
<?php
//設定や共通関数のinclude
//PHPによる処理
$a = 1;
?>
<html>
...
<?php echo $a; ?>
</html>
- 464 名前：nobodyさん mailto:sage [2008/05/08(木) 09:39:12 ID:???]
- > 別の言語のMVCフレームワークでも良いという結論になってしまうんじゃないか。
そのとおりだよ。
ただ、フレームワークも込みで、どこのレンタルサーバーで動くようなものはPHPしかない。
Rubyは言語辞退は一定な買ったりバージョンが古いし、
Perlはフレームワークや、必要なライブラリをインストールするのに
Shellやある程度の権限がいる。
PHPとPHP製フレームワーク・ライブラリは、ほとんどが
ファイル配置ですむからね。
あぁ、これがPHPを使っている意味かｗ
- 465 名前：nobodyさん mailto:sage [2008/05/08(木) 09:40:21 ID:???]
- Rubyは言語自体入ってなかったりバージョンが古いし、
- 466 名前：463 mailto:sage [2008/05/08(木) 10:10:38 ID:???]
- >>464
そうなんだよ、現実を考えるとPHPを使いたいというよりは
PHPを使わざるを得ない、という感じなんだよ。
そして使わざるを得ないPHPでPHPの特徴を消すようなフレームワークを使う。
このジレンマというかもやもやしたものが俺の中に常にある。
>Rubyは言語辞退は一定な買ったりバージョンが古いし、
>Perlはフレームワークや、必要なライブラリをインストールするのに
>Shellやある程度の権限がいる
これはレンタルサーバ屋によるというか、PHPも最新バージョンを使いたい
（特にセキュリティホール絡みで）時は、結局自分で最新版をコンパイルすることになって
権限やShellが必要になるので、ほんと、レンタルサーバ屋によるとしか言えないな。
- 467 名前：nobodyさん mailto:sage [2008/05/08(木) 11:24:56 ID:???]
- ベタ書き＝PHP＋XREA
MVC＝Python＋Google App Engine
がいいかな？
- 468 名前：nobodyさん mailto:sage [2008/05/08(木) 11:33:59 ID:???]
- 悪くないんじゃね。適材適所？
GoogleAppEngineは本サービスの内容次第だけど
- 469 名前：nobodyさん mailto:sage [2008/05/08(木) 12:49:25 ID:???]
- FWと独立したORMがもっとでてこねーかな
好きなFWに好きなORMを組み合わせるみたいな使い方が一般的になればいいのに
- 470 名前：nobodyさん mailto:sage [2008/05/08(木) 12:54:43 ID:???]
- 直SQLで十分。
- 471 名前：nobodyさん mailto:sage [2008/05/08(木) 13:01:46 ID:???]
- ﾃｨﾝﾎﾟﾆｰの新しいヘルパって
クラスメソッドになったんだっけ？
<?php echo HogeHelper::url_for('default/poge')?>
みたいな風に書くの？長くね？
- 472 名前：nobodyさん mailto:sage [2008/05/08(木) 13:20:40 ID:???]
- >>466
本末転倒になってね？
PHPの（いけてない）特徴を消すのが何が悪いの？
- 473 名前：nobodyさん mailto:sage [2008/05/08(木) 14:41:46 ID:???]
- いけてないPHP？
綺麗事抜きでドラスティックに行きましょうや
ベタ書き＋直SQL ＝ PHP＋XREA
MVC＋ORM ＝ Python＋Google App Engine
簡単にできることを複雑にやる必要はない
Python、Java等と使い分けて適材適所で
- 474 名前：nobodyさん mailto:sage [2008/05/08(木) 14:52:22 ID:???]
- 開発言語なんて自由に選べるものでもないし、
サーバーサイドで複数の言語が混在したシステムなんて考えたくもない。
ただ、PHPの言語仕様がさほど特徴的とも思わない。
自分は標準ライブラリが整備されてて、メジャーだからPHP使ってる。
- 475 名前：nobodyさん mailto:sage [2008/05/08(木) 15:13:05 ID:???]
- >>473
まず、君は何の為にデザインとロジックの分離という
考え方が存在するのか、なぜORMというものが存在するのか、
その理由を知ったほうがいい。
話はそれからだ。
（そのあとで、なぜPHPにはそれが当てはまらないというんだ？と聞く予定）
ついでに、なぜテンプレートを使えば、
RubyやPythonでも、PHPと同じようにHTMLの中にロジックを
書くことが出来るわけだが、なぜその方法を使わないのか。
君はこっちのほうが簡単だ。といいたいんだろう？
- 476 名前：nobodyさん mailto:sage [2008/05/08(木) 21:45:25 ID:???]
- >>475
で、どれがデザインとロジックの分離できてるわけ?
Rails? JSF? Django? どれもできてないじゃん。
実際できるのがあったとして、それはメジャーなん? 使い物になるだけの速さでるの?
できてもない『デザインとロジックの分離』という幻想を抱いて死んでくれ。
おれは断然>>454支持するぜ。
- 477 名前：nobodyさん mailto:sage [2008/05/08(木) 22:39:24 ID:???]
- まあ極端にならんと。
どっちの利点も判らんでもないけど、中庸ってのも考えなきゃ
妥協点ともいうか
たとえ幻想でも雑魚をまとめる旗印にはなるしw
- 478 名前：nobodyさん mailto:sage [2008/05/09(金) 00:59:50 ID:???]
- 自分が楽な作り方を選べばいいじゃん。
一人でちっさなツール作るなら、べたに書けばいいんじゃね？
中規模以上のものを作るにはMVCが作りやすいがね。
- 479 名前：nobodyさん mailto:sage [2008/05/09(金) 02:21:08 ID:???]
- プログラムとは一言でいえば「データ＋処理」
それ以上でもなければ、それ以外でもない
WEBアプリ＝DBラッパー
DOA→ベタ書き＋直SQLで充分
OOA→MVC＋ORMで楽できる
フレームワークは他人の知恵を借用して楽できるツール＝使わなきゃ損
普段フレームワークを使っていれば、逆にフレームワークを使うまでもない状況かどうか判断できるはずだよね？
お問合せメールフォーム１ページ作るのにsymfony使ってますとかは漫才ｗｗｗ
- 480 名前：nobodyさん mailto:sage [2008/05/09(金) 03:21:13 ID:???]
- インプットチェックで異常があったらフォームを再表示みたく、処理結果によって表示するページが
異なったり、複数の処理結果に対して同じページを表示したいことがあるのは普通だから、
ビューを分離するのは良いんだけど、DBアクセスは、同じ処理をしたいことは多くないし、
無理にまとめるとパフォーマンスが劣化するから、モデルとしてまとめることに利点があるのかは疑問。
コントロールも、自分の場合トランザクション前の処理、トランザクション中の処理、トランザクション後の処理、
次のページ取得を呼び出すクラス作って継承する程度で十分間にあってる。
ビューについては、そもそもがベタ書きみたいなもんだし。
フレームワークは、特定のフレームワークが業界内において支配的な立場になり、
その上で動作する使い勝手が良いパーツが流通しなければ、大してメリットなんかないと思ってる。
ソースコードの可読性は考慮すべきだけど、フレームワークを導入しただけで可読性がよくなる
わけじゃないし、フレームワークを導入しただけで大きなメリットがあるわけでもないなら、
フレームワーク使うべきって論はどうかなぁって思う。
- 481 名前：nobodyさん mailto:sage [2008/05/09(金) 13:09:55 ID:???]
- フレームワーク使うべきかどうかってそういう次元の話じゃなくて、
単にフレームワークを使ったほうが楽だから使うだけだよ。
> DBアクセスは、同じ処理をしたいことは多くないし、
同じ処理あるよ。検索処理や、検索結果を扱いやすいように
構造化されたハッシュ・配列に入れる処理。
JOINしたときとか、二次元の表よりも階層化された
配列に入ってくれたほうが楽だよね。
> その上で動作する使い勝手が良いパーツが流通しなければ、大してメリットなんかないと思ってる。
意味がわからん。PEARライブラリとか普通に使えるだろ。
フレームワーク専用のパーツなら、普通に使い勝手が良いパーツが組み込まれている。
だからこそ便利であり、使うんだが。
> フレームワークを導入しただけで可読性がよくなるわけじゃないし
良くある言い方だね。銀の弾丸じゃないならメリットがないとする極端な考え方。
銀の弾丸なんて存在しない。だけど普通の弾丸なら存在する。
弾丸が効かない敵がいたって、効く敵もいるんだから弾丸はあったほうがいいだろ。
フレームワークを導入すると、可読性が良くなる場合もあるし
少しでもメリットがあるのなら、あったほうがいいだろ。
- 482 名前：nobodyさん mailto:sage [2008/05/09(金) 21:42:19 ID:???]
- >>475
>まず、君は何の為にデザインとロジックの分離という
>考え方が存在するのか、なぜORMというものが存在するのか、
>その理由を知ったほうがいい。
>
>話はそれからだ。
なにこのえらそうなバカ。おまえはデザインとロジックの分離ができてるの?
こんだけえらそうに語ってるんだから、きっと完全な分離ができるんだろう。
で、どれを使ったらできるの? Symfony? Cake?
教えて、コーマンチキな475さん
- 483 名前：nobodyさん mailto:sage [2008/05/09(金) 22:56:26 ID:???]
- 「話はそれからだ」ってのは「理由は聞かないで下さいっ >_<」って意味なんだから、そっとしといてやれよ。
- 484 名前：nobodyさん [2008/05/09(金) 23:11:23 ID:a3XtheQg]
- >>482
>>475じゃないけどsymfony+smarty使ったことあるかい？
しかしMVCは良いとしてもO/Rマッパはなんとかならんもんかね
- 485 名前：nobodyさん mailto:sage [2008/05/10(土) 01:24:53 ID:???]
- >>484
あんな糞なもん使ったって何の自慢にもならねーよｗ
まあ、sfSmartyPlugin（だっけか）の品質の問題はともかく、
デザインにもロジックはあるのだよ。
ORMはおかしいよな。テーブルとモデルが一対一になってる。
おかしいのはPropelだけなのかもしんないけど。
そんなの変だよ、当たり前じゃないか、みたいなレスを貰ったのでほっとした。
- 486 名前：484 mailto:sage [2008/05/10(土) 03:06:24 ID:???]
- >>485
>>デザインにもロジックはあるのだよ。
それ言ったらjspも(ry
>>ORMはおかしいよな。テーブルとモデルが一対一になってる。
いや別に。
漏れがどうにかしてほしいと思っているのはpropelの使い方だけ。
doctrineもpropelもSQL文直打ちしていた人からしたら使いづらいと思うんだよね。
executeQuery()使えばいいんだけど、それだとO/Rマッパーの意味ないしな。
>>そんなの変だよ、当たり前じゃないか、みたいなレスを貰ったのでほっとした。
フレームワーク反対派に賛同したつもりはないんだが・・・・・。
ある程度規模でかくなればクラス分割してlib配下に設置してあげるだけでオートロードしてくれたりするから再利用も行いやすい。
フレームワークは結構便利だと思う。
でもそこまででかくならないんだったら別にいらないよなーって感じじゃね。
symfonyぐらいのフレームワーク使うんだったらメリットでかいと思うけどCakePHPやPiece Frameworkレベルだと別になくても良い様な希ガス。
- 487 名前：nobodyさん mailto:sage [2008/05/10(土) 10:23:21 ID:???]
- 小さいのを作るにはフレームワークを使わなくても出来るけど、
大きいのを作るにはフレームワークを使ったほうが便利。
便利な方法と、不便な方法。どちらを選ぶかは
考えるまでも無い。
- 488 名前：nobodyさん mailto:sage [2008/05/10(土) 10:26:41 ID:???]
- >>485
> デザインにもロジックはあるのだよ。
そうだね。でどうしろと？
どうせデザインにロジックがあるのだから、
各自勝手に作れといわんだろ？
あんた極端なんだよ。完璧じゃなければ必要ないとか考えてるだろ。
もう少しバランス感覚養ったほうがいいんじゃないのか？
1か0じゃなくて、どちらのほうが優れているかで話をしろ。
- 489 名前：nobodyさん mailto:sage [2008/05/10(土) 11:47:06 ID:???]
- JavaのApache Wicketというフレームワークは
テンプレートにHTMLを使う。
JSPみたいな独自タグや{hoge}みたいな独自識別子を使わない。
現状のWicketが完璧とは言わないけど（メジャーとは言い難いし）、
その方向性はいいなと思える。
ViewはHTMLのテンプレートを使って
ロジックはどの言語でもいい、みたいなもの（Viewテンプレートとロジックのブリッジみたいなもの？）ができれば
言語やフレームワークごとにViewの独自タグや独自識別子を使い分けなくてよくなると思うんだけどな。
- 490 名前：nobodyさん mailto:sage [2008/05/10(土) 12:08:18 ID:???]
- 即席で作るだけなら生書きの方が速いことも多いが
保守を考えるとフレームワーク使わないときついだろ
- 491 名前：nobodyさん mailto:sage [2008/05/10(土) 22:09:04 ID:???]
- >>485
> ORMはおかしいよな。テーブルとモデルが一対一になってる。
おかしい理由は？
DAOとしての面ではあるテーブルに対する操作が一つのクラスに集約されるから見通しが良くなるが。
- 492 名前：nobodyさん mailto:sage [2008/05/10(土) 22:28:21 ID:???]
- SQLって単体のテーブルごとにアクセスするものではないからだと思う。
パフォーマンスを考慮したSQLとの相性は悪いんじゃなかろうか。
- 493 名前：nobodyさん mailto:sage [2008/05/10(土) 23:26:26 ID:???]
- >>492
結合する処理をモデルに実装するから、そうでもないよ。
例えばユーザを結合したコメント一覧を取得するアクセスロジックをコメントモデルに持たせるとか。
ORMがアソシエーション機能を提供してたりもするし(あまり好きではないけど)。
Someモデルはsomeテーブル以外を知ってはならないということはないと思う。特にActiveRecordでは。
- 494 名前：nobodyさん mailto:sage [2008/05/11(日) 00:27:11 ID:???]
- runkitでaopみたいなことしたかったけど
セッションハンドラに登録したメソッド書き換えたら
segmantation fault出るようになった
やっぱまだ不安定なんだな・・・面白い拡張なんだが
- 495 名前：nobodyさん mailto:sage [2008/05/11(日) 00:39:19 ID:???]
- 俺485。おまいらレスありがとう。
でも書いてもらった日本語がよくわからない。
俺もいいかげんな発言してたので、真面目に書き直しておく。
>>486
お前は本当にsfSmartyViewPluginを使ったのか？
sfSmartyViewPluginを使わないでsymfonyで開発した事があるか？
sfSmartyViewPluginがビューとロジックの分離における有効策と考えてるなら、
それはあまりにもロジックを排除する事に対して神経質になりすぎだと思う。
symfonyは標準ではPHPの構文をテンプレートファイルに記述する。
確かにこの書き方だとHTML内にロジックが書けてしまうので束縛が無い事が嫌かも知れないが、
ビューにはビューを成立させるためのロジックがあっても良いと俺は考える。
- 496 名前：nobodyさん mailto:sage [2008/05/11(日) 00:43:17 ID:???]
- 俺は485なんだけど441でもある。
>>485の後半に書いた事は>>484に言ったというより、過去のレスへの返答だった。
>>442
前者です。
>>443-444
自明だよな。その書き込みを見てほっとしたぜ。
ってことだった。
- 497 名前：nobodyさん mailto:sage [2008/05/11(日) 00:50:47 ID:???]
- つーか休まないと日本語処理能力が低下しまくっていかんな。
>>488
sfSmartyViewPluginよりもsymfony標準のテンプレート書式の方が優れている。
というか、sfSmartyViewPluginは完璧に使い物にならないと心底思う。
sfSmartyViewPluginは足かせにこそなれ、利便性は何も齎してくれない。
反論はあるだろうけど、ビューに制約を課す事とMVCを考慮する事は全く別だと思う。
>>491
結合とはある単一のテーブルが行う処理ではないから。
- 498 名前：nobodyさん mailto:sage [2008/05/11(日) 01:04:31 ID:???]
- 一対一でマッピングされてるからって
そのテーブルに対して「のみ」のモデルじゃない
- 499 名前：nobodyさん mailto:sage [2008/05/11(日) 03:58:08 ID:???]
- いまだにsmartyとか言ってる意味がわからん
検討にすら値しないだろ
- 500 名前：nobodyさん mailto:sage [2008/05/11(日) 04:09:26 ID:???]
- 結局viewヘルパってどれがいいんだろうな？
・関数
・クラスメソッド
・$this(viewクラスあるいはcontrollerクラスのインスタンス）のメソッド
・$this以外の、view空間にassignされたオブジェクトのメソッド
個人的には最後のものに可能性を感じるが・・・
状態を持ちやすい、動的に変化させやすいという意味で。
複数のクラスのメソッドを集めるmixin的な機能が要りそう。
そこがキレイにできれば・・
- 501 名前：484 mailto:sage [2008/05/11(日) 05:00:31 ID:???]
- >>495
>>お前は本当にsfSmartyViewPluginを使ったのか？
>>sfSmartyViewPluginを使わないでsymfonyで開発した事があるか？
当たり前
>>それはあまりにもロジックを排除する事に対して神経質になりすぎだと思う。
おまい日曜プログラマ？プロジェクト内にテンプレート側にがちごりでロジック書くウンコいたらどうすんの？
デザイン変更したい～なんてお客さんから要望あったらデザイナーにテンプレート渡すだろ？
テンプレート側にロジックかかれたら・・・・・後はわかるよな。
使わなくていいんだったら漏れもつかわねーよ。プラグイン入れるのﾏﾝﾄﾞｸｾ
- 502 名前：nobodyさん mailto:sage [2008/05/11(日) 08:41:33 ID:???]
- >>484
>symfony+smarty使ったことあるかい？
smartyで「デザインとロジックの分離」が実現できるとでも思ってるの? バカ?
>>485
> デザインにもロジックはあるのだよ。
そのとーり。WicketやMayaaやTapestryでは確かに「デザインとロジックの分離」ができるけど、smartyなんかじゃ全然できない。
>>488
> そうだね。でどうしろと？
おまえはなにもするな。smartyごときで「デザインとロジックの分離」とか偉そうに語るな。
> あんた極端なんだよ。完璧じゃなければ必要ないとか考えてるだろ。
完璧にほど遠いものをさも完璧なように語るおまえがバカなだけ。
PHPにはWicketもMayaaもないんだから、デザインの分離なんか考えるだけ無駄。
> もう少しバランス感覚養ったほうがいいんじゃないのか？
> 1か0じゃなくて、どちらのほうが優れているかで話をしろ。
他人の言葉をうのみにしているおまえこそ、もっと現実をみたほうがいい。
実現できてもないことに、1も0もないだろ。バッカじゃない?
- 503 名前：nobodyさん mailto:sage [2008/05/11(日) 08:51:20 ID:???]
- >>498
そういう解釈をいれないといけないあたり、相性が悪いんじゃないかと。
出来ないって話はしてないつもり。
そもそもモデリングってのは本質的ではないものを隠蔽したり相殺したりして
扱いやすくするものだと理解してるんだが、パフォーマンス的なことを考えると
SQLはそれ自体が本質的で、隠蔽されるべき対象ではないと思う。
機能的なことだけ考えれば良いのなら、SQLを隠蔽するのは正しいだろうけど、
それは贅沢だなぁって思う。
- 504 名前：nobodyさん mailto:sage [2008/05/11(日) 09:50:03 ID:???]
- モデリングの時点でオブジェクト間の関連は定義されるんだから相性が悪いということはないと思うけどな。
設計(仕様)上、記事テーブルがユーザテーブルに依存するなら、記事モデルがユーザモデル(テーブル)を知っていていいし、依存してもいい。
ただ、今までORMレイヤをリリースしてきた人達が「SQLを書かなくていいよ！楽チンだよ！」ってところを押しすぎたのは良くない。
複雑なフェッチが必要な場合はSQLを発行して結果を返すメソッドをモデルに持たせればいいのに、
「(極端に言えば)SQLを書いちゃいけない」という固定観念のもと、SQL以上に複雑な手続きによるフェッチだったり、
複数回SQLが発行されることを厭わない実装がある。
バランスとれればいいんじゃないかな。多くの部分ではSQL書かずに楽するし、SQLが必要なら(モデル内に)SQLを書く。
SQL書いたらORMが謳う「簡単なデータベースの切り替え」ができなくなるって？
大丈夫。開発中にデータベースが変更になることはまずないし、「ついで」程度の機能でしかない。
- 505 名前：nobodyさん mailto:sage [2008/05/11(日) 13:40:27 ID:???]
- オープンソースのフレームワーク開発ってどういうビジネスモデルなんだろ？
symfonyとかciは企業が作ってるけど
どこで利益あげてるのかな？
知名度を上げて受注を増やす形？
- 506 名前：nobodyさん mailto:sage [2008/05/11(日) 14:20:23 ID:???]
- ひょっとしてそれはギャグで（ｒｙ
- 507 名前：nobodyさん mailto:sage [2008/05/11(日) 14:24:05 ID:???]
- いやギャグじゃないよ
どこからか金が環流しないと時間と労力投入できないじゃん
- 508 名前：nobodyさん mailto:sage [2008/05/11(日) 14:44:30 ID:???]
- >>502
お前の言うデザインとロジックの分離っていうものはいったいどれぐらいのレベルを言ってるんだ
それにしてもヒステリックなやつだな
もうちょっと落ち着けよ
お前みたいな趣味でやっているやつにはMVCはいらないと思うけど現場では実際に必要とされてるんだよ
- 509 名前：nobodyさん mailto:sage [2008/05/11(日) 14:49:35 ID:???]
- デザインとロジックの無意味な議論うぜぇ
- 510 名前：nobodyさん mailto:sage [2008/05/11(日) 15:03:35 ID:???]
- >>508
>>502じゃないが、デザインとロジックの分離のレベルは
WicketやMayaaレベルを言ってるんだろう。
俺も分離するならそのレベルが妥当だと思う。
逆にそのレベルで分離できないなら、
開発者には必要とされてもデザイナには使いにくいことに変わりないと思う。
- 511 名前：nobodyさん mailto:sage [2008/05/11(日) 15:25:06 ID:???]
- >>510
んなこたーない。ロジックが書かれたphpファイルより全然いいだろ。
.htmlファイルを直接テンプレートとして使えるし部分的にロジックが入るようであればそこはプログラマが修正してあげればいい。
そもそも一番のメリットは上に書いたがテンプレートにロジック書くようなｳﾝｺ野郎を排除するところだし。
- 512 名前：nobodyさん mailto:sage [2008/05/11(日) 15:54:25 ID:???]
- >>511
>んなこたーない。ロジックが書かれたphpファイルより全然いいだろ。
>.htmlファイルを直接テンプレートとして使えるし部分的にロジックが入るようであればそこはプログラマが修正してあげればいい。
すまんが主語は何だ。smartyが、か？
WicketやMayaaはテンプレートがHTMLなので（独自タグや{if}等が無い）、
HTMLしかしらないデザイナも扱いやすいし、
HTML編集ソフトでテンプレートを読み込んで修正しやすいのがメリットなんだが、
そんなメリットは必要ないってことか？
- 513 名前：nobodyさん mailto:sage [2008/05/11(日) 15:55:42 ID:???]
- RDB使ってる時点でSQL便利は自明
SQLイヤならOODB使うしかない
- 514 名前：nobodyさん mailto:sage [2008/05/11(日) 16:05:35 ID:???]
- Javaのテンプレートには、PHPのSmartyよりも優れたものがあるんですね。
参考になります。
ついでにPHPにも移植してください。
Wicket
www.wicket-ja.org/
Mayaa
mayaa.seasar.org/
- 515 名前：nobodyさん mailto:sage [2008/05/11(日) 16:19:02 ID:???]
- >>513
そう、SQLってかなり完成度高いんだよね。
SQLで拾った値でインスタンス作っても作らなくてもいいんだけど、
拾うためにインスタンス作るのに何のメリットがあるのか。
SQLをラップするのって、正規表現が分からない人向けに正規表現エンジンをラップして
簡単なテキスト検索エンジンを作ってるような気持ち悪さを感じる。で、正規表現をつかう
抜け道も用意してありますみたいな。
- 516 名前：nobodyさん [2008/05/11(日) 17:42:48 ID:tIr1XyIc]
- >>512
先生、WicketやMayaaをsymfonyと連携させる方法を教えてください＞＜
smarty使わないので教えてください＞＜
- 517 名前：nobodyさん mailto:sage [2008/05/11(日) 17:43:09 ID:???]
- sage忘れちゃったよ
ごめんね
- 518 名前：nobodyさん mailto:sage [2008/05/11(日) 17:49:27 ID:???]
- SMTPのプロトコルが分からない人向けにその部分をラップして
簡単にメールを送信するmail()関数がある。で、プロトコルしゃべる
抜け道も用意してある。
SQLラップするのも正規表現ラップするのも同じ。ライブラリとはそういうもの。
- 519 名前：nobodyさん mailto:sage [2008/05/11(日) 17:52:41 ID:???]
- SMTPはプロトコルとしての完成度高く無いじゃん。ただの規格。
- 520 名前：nobodyさん mailto:sage [2008/05/11(日) 17:58:59 ID:???]
- >>519
ん？完成度が高いものはラップする必要なく、低いものはラップして当たり前ということ？
- 521 名前：nobodyさん mailto:sage [2008/05/11(日) 18:49:51 ID:???]
- ラップの必要性の比較で言えばいうまでもなくそうだろ
- 522 名前：nobodyさん mailto:sage [2008/05/11(日) 19:01:31 ID:???]
- まぁ抜け道が前提のラッパーを見て、何も感じないなら、それはそれで才能だと思う。
PG/SIerとしては、そっちのほうが幸せかもしれん。
- 523 名前：nobodyさん mailto:sage [2008/05/11(日) 19:19:10 ID:???]
- >>521
で、その完成度の高い低い、ラップすべきしないべきは誰が決めんの？
結局自分の趣味趣向で言ってるだけなんだよなぁ。
- 524 名前：nobodyさん mailto:sage [2008/05/11(日) 21:01:26 ID:???]
- >>501
> プロジェクト内にテンプレート側にがちごりでロジック書くウンコいたらどうすんの？
クビにするべきだろう。
> デザイン変更したい～なんてお客さんから要望あったらデザイナーにテンプレート渡すだろ？
テンプレートを渡すという事は、責任を渡すという事と同義だよ。
> 使わなくていいんだったら漏れもつかわねーよ。プラグイン入れるのﾏﾝﾄﾞｸｾ
こう言ってるって事は、理不尽さを感じながら妥協をしていて、それを愚痴ってるんだと思うんだが、
たぶんプログラムに制限を課すより、体制を考えなおしたほうがいいと思うぞ。
たとえば、ウンコ書くプログラマが居る可能性がある時に、
そのプログラマが極力コードを書けないように制限する事は困難だと思う。
制限を課す事に手間を割くくらいなら、生産性のある作業に注力した方が良いんでないかい。
- 525 名前：nobodyさん mailto:sage [2008/05/11(日) 22:06:59 ID:???]
- >>524
なんかもう精神論じゃん。
フレームワークを改良するって発想がそんなに嫌かね。
- 526 名前：nobodyさん mailto:sage [2008/05/11(日) 22:15:43 ID:???]
- >>524
本当にプログラマ？
すぐクビにするとかテンプレート渡す＝責任を渡すとか
到底社会人の発想とは思えないんだが。
サンデープログラマや、開発者とデザイナが分かれてない業務しかやったことないのを否定はしないが、
分業化されてるプロジェクトの場合も想像できないと、この話を進めるのは無理だと思う。
- 527 名前：nobodyさん mailto:sage [2008/05/11(日) 22:19:14 ID:???]
- RubyでもWicketの仕組みを実装する動きがあるみたいだな…
- 528 名前：nobodyさん mailto:sage [2008/05/12(月) 00:11:47 ID:???]
- SQLが便利ってマンセーしてる人って、文字列およびプログラム内のデータ管理に
自信のある人なんだなーって素直に感心してる俺ｗ
とりあえず、外部からの入力値を元にしたSQLの動的な組み立てを自分でする気には
あんまりならないんだが、モデルってそういう所の面倒をみるってことはそんなに重視
されてないの？
まあ「MVCのモデル」ってレベルではなく、DBIインターフェイスレベルの話ではあるん
だけどｗ
- 529 名前：nobodyさん mailto:sage [2008/05/12(月) 00:52:56 ID:???]
- SQLを一切書かずORMだけでRDB使えてますか？
SQLより速くてインピーダンスミスマッチのないORMがあったら教えて！＞＜
分類 / 基礎となる計算モデル / 例
1. 手続型言語 / チューリングマシン / C, Java
2. 問合せ言語 / 関係モデル / SQL
3. 関数型言語 / ラムダ計算 / Lisp, Haskell
4. 論理型言語 / 一階述語言語 / Prolog
（2～4は、非手続型言語）
↑1～4のどれでも使えるようにしておいた方がいいよ
＝RDBを使ってる人はSQLも必須スキル
つwww.amazon.co.jp/dp/4798115169/
- 530 名前：nobodyさん mailto:sage [2008/05/12(月) 01:12:44 ID:???]
- うーんなんだろ。全然違う部分で話しちゃってるのは自覚してる
「SQL」って言っちゃうと、結局最終的に「文字列」に落とし込まなきゃいけないのが
違和感があるのかも
メソッドの引数とかオブジェクトのプロパティとかなら抵抗ないのに・・・
PerlやRubyで /\A"[^"]+"\z/ みたいなリテラルで書くことの出来る正規表現を、
文字列として "/\\A\"[^\"]\"\\z$/" って書かなきゃいけない歯がゆさみたいなｗ
だから、変数的な部分をプレースホルダにしたprepare(), execute() インターフェイスが
あれば、それで良いのか。それなら、変数的な部分以外はけっこうソリッドに組み立て
られる、と考えて・・・でも、やっぱりパラメータの数が変わったらプレースホルダの数も
変わるし・・・
いかに簡単にSQLを組み立てるかっていうツールとしてのモデルの効能が、あんまり
問題になっていないから書いてみたっていうだけ。低レベルだとは思うけど
- 531 名前：nobodyさん mailto:sage [2008/05/12(月) 01:35:11 ID:???]
- いいだろ文字列で。どうせ大したもん作ってねぇくせにぐだぐだ言うな
- 532 名前：nobodyさん mailto:sage [2008/05/12(月) 02:19:06 ID:???]
- ORマッパーが流行った理由は2つあると思う。
1つはJOINを駆使したりサブクエリーを使うような、（比較的）高度なSQLを書ける人が少なかった。（複雑な処理はホスト言語で処理する。）
もう1つはORマッパー＝オブジェクト指向を連想させ、オブジェクト指向って言葉だけをやたらもてはやすような風潮に乗っかった。
- 533 名前：nobodyさん mailto:sage [2008/05/12(月) 03:49:51 ID:???]
- O/Rマッパーで書けるような簡単な処理は
SQLで書いてもすぐ書ける罠
- 534 名前：nobodyさん mailto:sage [2008/05/12(月) 03:51:14 ID:???]
- 結局、O/Rマッパーは、SQLに慣れてる人なら
あまり意味ないってことでいい？
- 535 名前：nobodyさん mailto:sage [2008/05/12(月) 03:56:57 ID:???]
- なんだかんだ言って、Java的な発想なんだろ？＞ ORマッパ
ActiveRecordとかはシンプルでいいと思うけど、やりすぎ感っての？あるんじゃね？
APIが全てで、文字列としてのSQLを流し込むっていう感覚があんまり無いって感じで。
（C#とかの.net系でもO/Rマッパって使うのならごめん）
でも、PHPになじむかどうかは別問題なんだろうとは思う
- 536 名前：nobodyさん mailto:sage [2008/05/12(月) 04:10:33 ID:???]
- DBとベタベタにしないためにラッパー書くのは無駄じゃないと思うけどね
- 537 名前：nobodyさん mailto:sage [2008/05/12(月) 06:31:54 ID:???]
- >>532
私見だけど、メモリ中のオブジェクトをそのまま永続化させて使用するための
手段として RDBへの格納するのが良いのではないかっていう考え方があって、
でも現実には永続化よりもデータベース的な検索のほうが重要なことがはっきりして、
結局ラッパーとしてだけ生き残ったって感じではないかと思う。
まぁ、そうした抜け殻のようなツールとし出来上がった後、現場では >>532みたいなな
流れで流行ったんじゃないかと。
- 538 名前：nobodyさん mailto:sage [2008/05/12(月) 07:26:54 ID:???]
- >>528
>とりあえず、外部からの入力値を元にしたSQLの動的な組み立てを自分でする気には
>あんまりならないんだが、モデルってそういう所の面倒をみるってことはそんなに重視
>されてないの？
思うに、「フレームワークのパワーを生かした」開発においては、そういう小難しいことは、
基本的にやらない、もしくは極力避けるんじゃないかね。
フレームワークが力を発揮するのは、単機能な画面が多数あるようなシステムだと思う。
そうした前提においては、動的なSQLを嫌ったとしても、それは普通な判断だと思うし。
- 539 名前：nobodyさん mailto:sage [2008/05/12(月) 23:55:26 ID:???]
- PHPTALというのがあってだな。
tracfort.jp/projects/symfony-phptal
- 540 名前：524 mailto:sage [2008/05/13(火) 02:06:31 ID:???]
- >>525
いや、sfSmartyViewPluginは間違いなくsymfonyにとって改悪だと思うわ。
>>526
権限と責任が乖離している時点で、体制を考え直すべきだよ。
仮に、よほど信用出来なくて悪意があってとても偉いデザイナーと仕事をしてるとしても、
MVCやORMという概念や、symfonyやsmartyという実装は、
プログラマーとデザイナーの「責任の所在」を明らかにするための方法論では無いと思う。
>>528
俺はORMには否定的だけど、SQLを抽象化する事には肯定的。
|
 |
