【PHP】フレームワークについて語るスレ10【総合】
■ このスレッドは過去ログ倉庫に格納されています
0001nobodyさん
2008/02/09(土) 10:43:58ID:???http://pc11.2ch.net/test/read.cgi/php/1197383840/
0446nobodyさん
2008/05/07(水) 12:42:06ID:???自分の場合、自作の例外クラスって、せいぜい2個ぐらい (ユーザ操作系、システム異常系) しか作らない。
どんな例外であれ、rollbackしてエラーメッセージ出して終わりってのがほとんどだから、
クラス分けせずにエラーコードで区別してる。
0447nobodyさん
2008/05/07(水) 14:16:49ID:???0448nobodyさん
2008/05/07(水) 20:53:16ID:???せっかく例外という便利なものが使えるのに、
古臭く、使いづらく、バグが起こりやすい、
エラーコードを使う理由ってなに？
0450nobodyさん
2008/05/07(水) 21:14:56ID:???例外の中でエラーコードを使っていると言う意味。
クラスの型で判別してないだけで、例外処理は使ってる。
0451nobodyさん
2008/05/07(水) 21:59:18ID:???class なんとか_かんとか_Exception extends なんとか_Exception
{}
だけみたいなファイルが増えてくのはやっぱバカバカしいな
0452nobodyさん
2008/05/07(水) 23:57:23ID:???0453nobodyさん
2008/05/08(木) 00:14:58ID:???$e->getCode(), $e->getMessage() で分岐するか、の違い
しかないとか思っちゃうんだが、わかってないってことだと
自分でも思う
0454nobodyさん
2008/05/08(木) 00:29:40ID:???長い目で見たら実は激しく開発効率が落ちるよな。
みんなとっくに気付いてるだろ。
もうMVCなんて発掘された化石にしがみつくのはやめようぜ。
テンプレートに全部書くに限る。
冗談抜きで、コピペでいい。
変更は該当ファイルを変更。
追加は新規作成。
そもそもPHPはこの形で爆発的に伸びてきた。
ものすごい速さで「ページ」を量産できてきたわけだ。
PHPと比較してはるかにHTMLを苦手とする他の言語の実装にすりよる必要なんてない。
コードが醜悪で結構。
メンテし難い？
いやいや、HTML部分はどんな初心者でも理解可能だからさっさと読み飛ばすわけだ。
そして残ったPHP処理部分がMVCを捨ててページ単位で完結して書いてある。
完結しているのだから、追っていくだけで全容が分かるわけだ。
汚い素のPHPファイルが開発効率に優れている理由はここにある。
何かを試験的に作るとき、さっさとPHPというテンプレートで書いちゃうだろ。
たぶん、数時間あれば、第三者に見せられる程度の単機能ページを作れるだろ。
その試作品でいいんだよ。
一週間かけたものと何も変わんねえから。
つまりその試作品で50万くらい請求できるわけだ。
あるいは、10万に値下げできるわけだ。
頭冷やそうぜ。
PHPそのものが実利の塊なんだから、無理して加工すんなって。無駄な汗を流すなよ。
どうしても加工してPHPらしくない別フレームワークを作りたければ、C++で本気で作れ。PHPでやるな馬鹿外人。
0455nobodyさん
2008/05/08(木) 00:42:41ID:???プログラマとしては気に入らないけど、現場レベルだとコピペ嵐の方が修正時の影響範囲が
限定的だから現実的だというのは、認めないわけでもない。
カラシニコフ的アーキテクチャとでも言うべきか。
0456nobodyさん
2008/05/08(木) 00:55:28ID:???修正が体力勝負になるから嫌気がさすっていうのもあるんだよｗ
ポリシーと一貫性があるならいいが、どうせ修正がかさむにつれ
AとA'とA''とABとA''Bみたいなソースが量産されてくるんだろ
一字一句変えずにコピペできる所なんてそう無い。大概コピペ先で
修正されてdiffとったりしたら目を覆うような作業量になる
それでも、「可能」かどうかをいうなら、修正は可能だし、８割くらいの
作業が速く済む、っていうのはうなずけなくもないけど
0457nobodyさん
2008/05/08(木) 02:02:54ID:???0459nobodyさん
2008/05/08(木) 05:17:56ID:???>>454はちょっと乱暴な文体だけど言いたいことはわかる。
これは何もスパゲティなコード書けということではなくて
もちろんメンテしやすいように努力はするのだけれど
そのために果たしてMVCやオブジェクト指向が必要かどうかといえば
必ずしも必要ではないかもしれない。
我々は何もPHPしか使えないわけではないのだから
PHPを使う時は割り切ってページ単位でディレクトリ階層もわかりやすく
作っても良いのかもしれない。
正直、最近PHPフレームワークについて興味があったんだが、
再度PHPの良さについて考えてみよう。
0460nobodyさん
2008/05/08(木) 06:45:47ID:???開発効率とか
安定性を求めれば
結局MVCに戻ってくることになる。
おつかれさんｗ
0461nobodyさん
2008/05/08(木) 08:00:22ID:???0462nobodyさん
2008/05/08(木) 08:20:17ID:???エレガントな設計はむしろ罪悪じゃないかと思うし、残念ながらそういう環境は多い。
逆に言えば >>454 は、人海戦術で対応可能な仕事でないと成立しないんじゃないかとも思うが、
エレガントさをあきらめれば、人海戦術で対応できない仕事なんてそうないし。
0463nobodyさん
2008/05/08(木) 08:43:03ID:???この混在をViewが分離してないので悪と捉えるならば、
PHPの特徴も悪ということになる。
それでそのPHPの特徴を無くしたMVCなフレームワークを使うことになるんだが、
それじゃPHPを使ってる意味とは何なんだろうか。
別の言語のMVCフレームワークでも良いという結論になってしまうんじゃないか。
別にMVCなフレームワークが悪いと言ってるんじゃない。
ただ、PHPの特徴を活かした使い方があるんじゃないだろうか。
昔ながらのロジックとビューをファイルの上下で分割するような次のような使い方でも。
-------------
<?php
//設定や共通関数のinclude
//PHPによる処理
$a = 1;
?>
<html>
...
<?php echo $a; ?>
</html>
0464nobodyさん
2008/05/08(木) 09:39:12ID:???そのとおりだよ。
ただ、フレームワークも込みで、どこのレンタルサーバーで動くようなものはPHPしかない。
Rubyは言語辞退は一定な買ったりバージョンが古いし、
Perlはフレームワークや、必要なライブラリをインストールするのに
Shellやある程度の権限がいる。
PHPとPHP製フレームワーク・ライブラリは、ほとんどが
ファイル配置ですむからね。
あぁ、これがPHPを使っている意味かｗ
0465nobodyさん
2008/05/08(木) 09:40:21ID:???0466463
2008/05/08(木) 10:10:38ID:???そうなんだよ、現実を考えるとPHPを使いたいというよりは
PHPを使わざるを得ない、という感じなんだよ。
そして使わざるを得ないPHPでPHPの特徴を消すようなフレームワークを使う。
このジレンマというかもやもやしたものが俺の中に常にある。
>Rubyは言語辞退は一定な買ったりバージョンが古いし、
>Perlはフレームワークや、必要なライブラリをインストールするのに
>Shellやある程度の権限がいる
これはレンタルサーバ屋によるというか、PHPも最新バージョンを使いたい
（特にセキュリティホール絡みで）時は、結局自分で最新版をコンパイルすることになって
権限やShellが必要になるので、ほんと、レンタルサーバ屋によるとしか言えないな。
0467nobodyさん
2008/05/08(木) 11:24:56ID:???MVC＝Python＋Google App Engine
がいいかな？
0468nobodyさん
2008/05/08(木) 11:33:59ID:???GoogleAppEngineは本サービスの内容次第だけど
0469nobodyさん
2008/05/08(木) 12:49:25ID:???好きなFWに好きなORMを組み合わせるみたいな使い方が一般的になればいいのに
0470nobodyさん
2008/05/08(木) 12:54:43ID:???0471nobodyさん
2008/05/08(木) 13:01:46ID:???クラスメソッドになったんだっけ？
<?php echo HogeHelper::url_for('default/poge')?>
みたいな風に書くの？長くね？
0473nobodyさん
2008/05/08(木) 14:41:46ID:???綺麗事抜きでドラスティックに行きましょうや
ベタ書き＋直SQL ＝ PHP＋XREA
MVC＋ORM ＝ Python＋Google App Engine
簡単にできることを複雑にやる必要はない
Python、Java等と使い分けて適材適所で
0474nobodyさん
2008/05/08(木) 14:52:22ID:???サーバーサイドで複数の言語が混在したシステムなんて考えたくもない。
ただ、PHPの言語仕様がさほど特徴的とも思わない。
自分は標準ライブラリが整備されてて、メジャーだからPHP使ってる。
0475nobodyさん
2008/05/08(木) 15:13:05ID:???まず、君は何の為にデザインとロジックの分離という
考え方が存在するのか、なぜORMというものが存在するのか、
その理由を知ったほうがいい。
話はそれからだ。
（そのあとで、なぜPHPにはそれが当てはまらないというんだ？と聞く予定）
ついでに、なぜテンプレートを使えば、
RubyやPythonでも、PHPと同じようにHTMLの中にロジックを
書くことが出来るわけだが、なぜその方法を使わないのか。
君はこっちのほうが簡単だ。といいたいんだろう？
0476nobodyさん
2008/05/08(木) 21:45:25ID:???で、どれがデザインとロジックの分離できてるわけ?
Rails? JSF? Django? どれもできてないじゃん。
実際できるのがあったとして、それはメジャーなん? 使い物になるだけの速さでるの?
できてもない『デザインとロジックの分離』という幻想を抱いて死んでくれ。
おれは断然>>454支持するぜ。
0477nobodyさん
2008/05/08(木) 22:39:24ID:???どっちの利点も判らんでもないけど、中庸ってのも考えなきゃ
妥協点ともいうか
たとえ幻想でも雑魚をまとめる旗印にはなるしw
0478nobodyさん
2008/05/09(金) 00:59:50ID:???一人でちっさなツール作るなら、べたに書けばいいんじゃね？
中規模以上のものを作るにはMVCが作りやすいがね。
0479nobodyさん
2008/05/09(金) 02:21:08ID:???それ以上でもなければ、それ以外でもない
WEBアプリ＝DBラッパー
DOA→ベタ書き＋直SQLで充分
OOA→MVC＋ORMで楽できる
フレームワークは他人の知恵を借用して楽できるツール＝使わなきゃ損
普段フレームワークを使っていれば、逆にフレームワークを使うまでもない状況かどうか判断できるはずだよね？
お問合せメールフォーム１ページ作るのにsymfony使ってますとかは漫才ｗｗｗ
0480nobodyさん
2008/05/09(金) 03:21:13ID:???異なったり、複数の処理結果に対して同じページを表示したいことがあるのは普通だから、
ビューを分離するのは良いんだけど、DBアクセスは、同じ処理をしたいことは多くないし、
無理にまとめるとパフォーマンスが劣化するから、モデルとしてまとめることに利点があるのかは疑問。
コントロールも、自分の場合トランザクション前の処理、トランザクション中の処理、トランザクション後の処理、
次のページ取得を呼び出すクラス作って継承する程度で十分間にあってる。
ビューについては、そもそもがベタ書きみたいなもんだし。
フレームワークは、特定のフレームワークが業界内において支配的な立場になり、
その上で動作する使い勝手が良いパーツが流通しなければ、大してメリットなんかないと思ってる。
ソースコードの可読性は考慮すべきだけど、フレームワークを導入しただけで可読性がよくなる
わけじゃないし、フレームワークを導入しただけで大きなメリットがあるわけでもないなら、
フレームワーク使うべきって論はどうかなぁって思う。
0481nobodyさん
2008/05/09(金) 13:09:55ID:???単にフレームワークを使ったほうが楽だから使うだけだよ。
> DBアクセスは、同じ処理をしたいことは多くないし、
同じ処理あるよ。検索処理や、検索結果を扱いやすいように
構造化されたハッシュ・配列に入れる処理。
JOINしたときとか、二次元の表よりも階層化された
配列に入ってくれたほうが楽だよね。
> その上で動作する使い勝手が良いパーツが流通しなければ、大してメリットなんかないと思ってる。
意味がわからん。PEARライブラリとか普通に使えるだろ。
フレームワーク専用のパーツなら、普通に使い勝手が良いパーツが組み込まれている。
だからこそ便利であり、使うんだが。
> フレームワークを導入しただけで可読性がよくなるわけじゃないし
良くある言い方だね。銀の弾丸じゃないならメリットがないとする極端な考え方。
銀の弾丸なんて存在しない。だけど普通の弾丸なら存在する。
弾丸が効かない敵がいたって、効く敵もいるんだから弾丸はあったほうがいいだろ。
フレームワークを導入すると、可読性が良くなる場合もあるし
少しでもメリットがあるのなら、あったほうがいいだろ。
0482nobodyさん
2008/05/09(金) 21:42:19ID:???>まず、君は何の為にデザインとロジックの分離という
>考え方が存在するのか、なぜORMというものが存在するのか、
>その理由を知ったほうがいい。
>
>話はそれからだ。
なにこのえらそうなバカ。おまえはデザインとロジックの分離ができてるの?
こんだけえらそうに語ってるんだから、きっと完全な分離ができるんだろう。
で、どれを使ったらできるの? Symfony? Cake?
教えて、コーマンチキな475さん
0483nobodyさん
2008/05/09(金) 22:56:26ID:???0484nobodyさん
2008/05/09(金) 23:11:23ID:a3XtheQg>>475じゃないけどsymfony+smarty使ったことあるかい？
しかしMVCは良いとしてもO/Rマッパはなんとかならんもんかね
0485nobodyさん
2008/05/10(土) 01:24:53ID:???あんな糞なもん使ったって何の自慢にもならねーよｗ
まあ、sfSmartyPlugin（だっけか）の品質の問題はともかく、
デザインにもロジックはあるのだよ。
ORMはおかしいよな。テーブルとモデルが一対一になってる。
おかしいのはPropelだけなのかもしんないけど。
そんなの変だよ、当たり前じゃないか、みたいなレスを貰ったのでほっとした。
0486484
2008/05/10(土) 03:06:24ID:???>>デザインにもロジックはあるのだよ。
それ言ったらjspも(ry
>>ORMはおかしいよな。テーブルとモデルが一対一になってる。
いや別に。
漏れがどうにかしてほしいと思っているのはpropelの使い方だけ。
doctrineもpropelもSQL文直打ちしていた人からしたら使いづらいと思うんだよね。
executeQuery()使えばいいんだけど、それだとO/Rマッパーの意味ないしな。
>>そんなの変だよ、当たり前じゃないか、みたいなレスを貰ったのでほっとした。
フレームワーク反対派に賛同したつもりはないんだが・・・・・。
ある程度規模でかくなればクラス分割してlib配下に設置してあげるだけでオートロードしてくれたりするから再利用も行いやすい。
フレームワークは結構便利だと思う。
でもそこまででかくならないんだったら別にいらないよなーって感じじゃね。
symfonyぐらいのフレームワーク使うんだったらメリットでかいと思うけどCakePHPやPiece Frameworkレベルだと別になくても良い様な希ガス。
0487nobodyさん
2008/05/10(土) 10:23:21ID:???大きいのを作るにはフレームワークを使ったほうが便利。
便利な方法と、不便な方法。どちらを選ぶかは
考えるまでも無い。
0488nobodyさん
2008/05/10(土) 10:26:41ID:???> デザインにもロジックはあるのだよ。
そうだね。でどうしろと？
どうせデザインにロジックがあるのだから、
各自勝手に作れといわんだろ？
あんた極端なんだよ。完璧じゃなければ必要ないとか考えてるだろ。
もう少しバランス感覚養ったほうがいいんじゃないのか？
1か0じゃなくて、どちらのほうが優れているかで話をしろ。
0489nobodyさん
2008/05/10(土) 11:47:06ID:???テンプレートにHTMLを使う。
JSPみたいな独自タグや{hoge}みたいな独自識別子を使わない。
現状のWicketが完璧とは言わないけど（メジャーとは言い難いし）、
その方向性はいいなと思える。
ViewはHTMLのテンプレートを使って
ロジックはどの言語でもいい、みたいなもの（Viewテンプレートとロジックのブリッジみたいなもの？）ができれば
言語やフレームワークごとにViewの独自タグや独自識別子を使い分けなくてよくなると思うんだけどな。
0490nobodyさん
2008/05/10(土) 12:08:18ID:???保守を考えるとフレームワーク使わないときついだろ
0491nobodyさん
2008/05/10(土) 22:09:04ID:???> ORMはおかしいよな。テーブルとモデルが一対一になってる。
おかしい理由は？
DAOとしての面ではあるテーブルに対する操作が一つのクラスに集約されるから見通しが良くなるが。
0492nobodyさん
2008/05/10(土) 22:28:21ID:???パフォーマンスを考慮したSQLとの相性は悪いんじゃなかろうか。
0493nobodyさん
2008/05/10(土) 23:26:26ID:???結合する処理をモデルに実装するから、そうでもないよ。
例えばユーザを結合したコメント一覧を取得するアクセスロジックをコメントモデルに持たせるとか。
ORMがアソシエーション機能を提供してたりもするし(あまり好きではないけど)。
Someモデルはsomeテーブル以外を知ってはならないということはないと思う。特にActiveRecordでは。
0494nobodyさん
2008/05/11(日) 00:27:11ID:???セッションハンドラに登録したメソッド書き換えたら
segmantation fault出るようになった
やっぱまだ不安定なんだな・・・面白い拡張なんだが
0495nobodyさん
2008/05/11(日) 00:39:19ID:???でも書いてもらった日本語がよくわからない。
俺もいいかげんな発言してたので、真面目に書き直しておく。
>>486
お前は本当にsfSmartyViewPluginを使ったのか？
sfSmartyViewPluginを使わないでsymfonyで開発した事があるか？
sfSmartyViewPluginがビューとロジックの分離における有効策と考えてるなら、
それはあまりにもロジックを排除する事に対して神経質になりすぎだと思う。
symfonyは標準ではPHPの構文をテンプレートファイルに記述する。
確かにこの書き方だとHTML内にロジックが書けてしまうので束縛が無い事が嫌かも知れないが、
ビューにはビューを成立させるためのロジックがあっても良いと俺は考える。
0496nobodyさん
2008/05/11(日) 00:43:17ID:???>>485の後半に書いた事は>>484に言ったというより、過去のレスへの返答だった。
>>442
前者です。
>>443-444
自明だよな。その書き込みを見てほっとしたぜ。
ってことだった。
0497nobodyさん
2008/05/11(日) 00:50:47ID:???>>488
sfSmartyViewPluginよりもsymfony標準のテンプレート書式の方が優れている。
というか、sfSmartyViewPluginは完璧に使い物にならないと心底思う。
sfSmartyViewPluginは足かせにこそなれ、利便性は何も齎してくれない。
反論はあるだろうけど、ビューに制約を課す事とMVCを考慮する事は全く別だと思う。
>>491
結合とはある単一のテーブルが行う処理ではないから。
0498nobodyさん
2008/05/11(日) 01:04:31ID:???そのテーブルに対して「のみ」のモデルじゃない
0499nobodyさん
2008/05/11(日) 03:58:08ID:???検討にすら値しないだろ
0500nobodyさん
2008/05/11(日) 04:09:26ID:???・関数
・クラスメソッド
・$this(viewクラスあるいはcontrollerクラスのインスタンス）のメソッド
・$this以外の、view空間にassignされたオブジェクトのメソッド
個人的には最後のものに可能性を感じるが・・・
状態を持ちやすい、動的に変化させやすいという意味で。
複数のクラスのメソッドを集めるmixin的な機能が要りそう。
そこがキレイにできれば・・
0501484
2008/05/11(日) 05:00:31ID:???>>お前は本当にsfSmartyViewPluginを使ったのか？
>>sfSmartyViewPluginを使わないでsymfonyで開発した事があるか？
当たり前
>>それはあまりにもロジックを排除する事に対して神経質になりすぎだと思う。
おまい日曜プログラマ？プロジェクト内にテンプレート側にがちごりでロジック書くウンコいたらどうすんの？
デザイン変更したい〜なんてお客さんから要望あったらデザイナーにテンプレート渡すだろ？
テンプレート側にロジックかかれたら・・・・・後はわかるよな。
使わなくていいんだったら漏れもつかわねーよ。プラグイン入れるのﾏﾝﾄﾞｸｾ
0502nobodyさん
2008/05/11(日) 08:41:33ID:???>symfony+smarty使ったことあるかい？
smartyで「デザインとロジックの分離」が実現できるとでも思ってるの? バカ?
>>485
> デザインにもロジックはあるのだよ。
そのとーり。WicketやMayaaやTapestryでは確かに「デザインとロジックの分離」ができるけど、smartyなんかじゃ全然できない。
>>488
> そうだね。でどうしろと？
おまえはなにもするな。smartyごときで「デザインとロジックの分離」とか偉そうに語るな。
> あんた極端なんだよ。完璧じゃなければ必要ないとか考えてるだろ。
完璧にほど遠いものをさも完璧なように語るおまえがバカなだけ。
PHPにはWicketもMayaaもないんだから、デザインの分離なんか考えるだけ無駄。
> もう少しバランス感覚養ったほうがいいんじゃないのか？
> 1か0じゃなくて、どちらのほうが優れているかで話をしろ。
他人の言葉をうのみにしているおまえこそ、もっと現実をみたほうがいい。
実現できてもないことに、1も0もないだろ。バッカじゃない?
0503nobodyさん
2008/05/11(日) 08:51:20ID:???そういう解釈をいれないといけないあたり、相性が悪いんじゃないかと。
出来ないって話はしてないつもり。
そもそもモデリングってのは本質的ではないものを隠蔽したり相殺したりして
扱いやすくするものだと理解してるんだが、パフォーマンス的なことを考えると
SQLはそれ自体が本質的で、隠蔽されるべき対象ではないと思う。
機能的なことだけ考えれば良いのなら、SQLを隠蔽するのは正しいだろうけど、
それは贅沢だなぁって思う。
0504nobodyさん
2008/05/11(日) 09:50:03ID:???設計(仕様)上、記事テーブルがユーザテーブルに依存するなら、記事モデルがユーザモデル(テーブル)を知っていていいし、依存してもいい。
ただ、今までORMレイヤをリリースしてきた人達が「SQLを書かなくていいよ！楽チンだよ！」ってところを押しすぎたのは良くない。
複雑なフェッチが必要な場合はSQLを発行して結果を返すメソッドをモデルに持たせればいいのに、
「(極端に言えば)SQLを書いちゃいけない」という固定観念のもと、SQL以上に複雑な手続きによるフェッチだったり、
複数回SQLが発行されることを厭わない実装がある。
バランスとれればいいんじゃないかな。多くの部分ではSQL書かずに楽するし、SQLが必要なら(モデル内に)SQLを書く。
SQL書いたらORMが謳う「簡単なデータベースの切り替え」ができなくなるって？
大丈夫。開発中にデータベースが変更になることはまずないし、「ついで」程度の機能でしかない。
0505nobodyさん
2008/05/11(日) 13:40:27ID:???symfonyとかciは企業が作ってるけど
どこで利益あげてるのかな？
知名度を上げて受注を増やす形？
0506nobodyさん
2008/05/11(日) 14:20:23ID:???0507nobodyさん
2008/05/11(日) 14:24:05ID:???どこからか金が環流しないと時間と労力投入できないじゃん
0508nobodyさん
2008/05/11(日) 14:44:30ID:???お前の言うデザインとロジックの分離っていうものはいったいどれぐらいのレベルを言ってるんだ
それにしてもヒステリックなやつだな
もうちょっと落ち着けよ
お前みたいな趣味でやっているやつにはMVCはいらないと思うけど現場では実際に必要とされてるんだよ
0509nobodyさん
2008/05/11(日) 14:49:35ID:???0510nobodyさん
2008/05/11(日) 15:03:35ID:???>>502じゃないが、デザインとロジックの分離のレベルは
WicketやMayaaレベルを言ってるんだろう。
俺も分離するならそのレベルが妥当だと思う。
逆にそのレベルで分離できないなら、
開発者には必要とされてもデザイナには使いにくいことに変わりないと思う。
0511nobodyさん
2008/05/11(日) 15:25:06ID:???んなこたーない。ロジックが書かれたphpファイルより全然いいだろ。
.htmlファイルを直接テンプレートとして使えるし部分的にロジックが入るようであればそこはプログラマが修正してあげればいい。
そもそも一番のメリットは上に書いたがテンプレートにロジック書くようなｳﾝｺ野郎を排除するところだし。
0512nobodyさん
2008/05/11(日) 15:54:25ID:???>んなこたーない。ロジックが書かれたphpファイルより全然いいだろ。
>.htmlファイルを直接テンプレートとして使えるし部分的にロジックが入るようであればそこはプログラマが修正してあげればいい。
すまんが主語は何だ。smartyが、か？
WicketやMayaaはテンプレートがHTMLなので（独自タグや{if}等が無い）、
HTMLしかしらないデザイナも扱いやすいし、
HTML編集ソフトでテンプレートを読み込んで修正しやすいのがメリットなんだが、
そんなメリットは必要ないってことか？
0513nobodyさん
2008/05/11(日) 15:55:42ID:???SQLイヤならOODB使うしかない
0514nobodyさん
2008/05/11(日) 16:05:35ID:???参考になります。
ついでにPHPにも移植してください。
Wicket
http://www.wicket-ja.org/
Mayaa
http://mayaa.seasar.org/
0515nobodyさん
2008/05/11(日) 16:19:02ID:???そう、SQLってかなり完成度高いんだよね。
SQLで拾った値でインスタンス作っても作らなくてもいいんだけど、
拾うためにインスタンス作るのに何のメリットがあるのか。
SQLをラップするのって、正規表現が分からない人向けに正規表現エンジンをラップして
簡単なテキスト検索エンジンを作ってるような気持ち悪さを感じる。で、正規表現をつかう
抜け道も用意してありますみたいな。
0516nobodyさん
2008/05/11(日) 17:42:48ID:tIr1XyIc先生、WicketやMayaaをsymfonyと連携させる方法を教えてください＞＜
smarty使わないので教えてください＞＜
0517nobodyさん
2008/05/11(日) 17:43:09ID:???ごめんね
0518nobodyさん
2008/05/11(日) 17:49:27ID:???簡単にメールを送信するmail()関数がある。で、プロトコルしゃべる
抜け道も用意してある。
SQLラップするのも正規表現ラップするのも同じ。ライブラリとはそういうもの。
0519nobodyさん
2008/05/11(日) 17:52:41ID:???0521nobodyさん
2008/05/11(日) 18:49:51ID:???0522nobodyさん
2008/05/11(日) 19:01:31ID:???PG/SIerとしては、そっちのほうが幸せかもしれん。
0523nobodyさん
2008/05/11(日) 19:19:10ID:???で、その完成度の高い低い、ラップすべきしないべきは誰が決めんの？
結局自分の趣味趣向で言ってるだけなんだよなぁ。
0524nobodyさん
2008/05/11(日) 21:01:26ID:???> プロジェクト内にテンプレート側にがちごりでロジック書くウンコいたらどうすんの？
クビにするべきだろう。
> デザイン変更したい〜なんてお客さんから要望あったらデザイナーにテンプレート渡すだろ？
テンプレートを渡すという事は、責任を渡すという事と同義だよ。
> 使わなくていいんだったら漏れもつかわねーよ。プラグイン入れるのﾏﾝﾄﾞｸｾ
こう言ってるって事は、理不尽さを感じながら妥協をしていて、それを愚痴ってるんだと思うんだが、
たぶんプログラムに制限を課すより、体制を考えなおしたほうがいいと思うぞ。
たとえば、ウンコ書くプログラマが居る可能性がある時に、
そのプログラマが極力コードを書けないように制限する事は困難だと思う。
制限を課す事に手間を割くくらいなら、生産性のある作業に注力した方が良いんでないかい。
0526nobodyさん
2008/05/11(日) 22:15:43ID:???本当にプログラマ？
すぐクビにするとかテンプレート渡す＝責任を渡すとか
到底社会人の発想とは思えないんだが。
サンデープログラマや、開発者とデザイナが分かれてない業務しかやったことないのを否定はしないが、
分業化されてるプロジェクトの場合も想像できないと、この話を進めるのは無理だと思う。
0527nobodyさん
2008/05/11(日) 22:19:14ID:???0528nobodyさん
2008/05/12(月) 00:11:47ID:???自信のある人なんだなーって素直に感心してる俺ｗ
とりあえず、外部からの入力値を元にしたSQLの動的な組み立てを自分でする気には
あんまりならないんだが、モデルってそういう所の面倒をみるってことはそんなに重視
されてないの？
まあ「MVCのモデル」ってレベルではなく、DBIインターフェイスレベルの話ではあるん
だけどｗ
0529nobodyさん
2008/05/12(月) 00:52:56ID:???SQLより速くてインピーダンスミスマッチのないORMがあったら教えて！＞＜
分類 / 基礎となる計算モデル / 例
1. 手続型言語 / チューリングマシン / C, Java
2. 問合せ言語 / 関係モデル / SQL
3. 関数型言語 / ラムダ計算 / Lisp, Haskell
4. 論理型言語 / 一階述語言語 / Prolog
（2〜4は、非手続型言語）
↑1〜4のどれでも使えるようにしておいた方がいいよ
＝RDBを使ってる人はSQLも必須スキル
つhttp://www.amazon.co.jp/dp/4798115169/
0530nobodyさん
2008/05/12(月) 01:12:44ID:???「SQL」って言っちゃうと、結局最終的に「文字列」に落とし込まなきゃいけないのが
違和感があるのかも
メソッドの引数とかオブジェクトのプロパティとかなら抵抗ないのに・・・
PerlやRubyで /\A"[^"]+"\z/ みたいなリテラルで書くことの出来る正規表現を、
文字列として "/\\A\"[^\"]\"\\z$/" って書かなきゃいけない歯がゆさみたいなｗ
だから、変数的な部分をプレースホルダにしたprepare(), execute() インターフェイスが
あれば、それで良いのか。それなら、変数的な部分以外はけっこうソリッドに組み立て
られる、と考えて・・・でも、やっぱりパラメータの数が変わったらプレースホルダの数も
変わるし・・・
いかに簡単にSQLを組み立てるかっていうツールとしてのモデルの効能が、あんまり
問題になっていないから書いてみたっていうだけ。低レベルだとは思うけど
0531nobodyさん
2008/05/12(月) 01:35:11ID:???0532nobodyさん
2008/05/12(月) 02:19:06ID:???1つはJOINを駆使したりサブクエリーを使うような、（比較的）高度なSQLを書ける人が少なかった。（複雑な処理はホスト言語で処理する。）
もう1つはORマッパー＝オブジェクト指向を連想させ、オブジェクト指向って言葉だけをやたらもてはやすような風潮に乗っかった。
0533nobodyさん
2008/05/12(月) 03:49:51ID:???SQLで書いてもすぐ書ける罠
0534nobodyさん
2008/05/12(月) 03:51:14ID:???あまり意味ないってことでいい？
0535nobodyさん
2008/05/12(月) 03:56:57ID:???ActiveRecordとかはシンプルでいいと思うけど、やりすぎ感っての？あるんじゃね？
APIが全てで、文字列としてのSQLを流し込むっていう感覚があんまり無いって感じで。
（C#とかの.net系でもO/Rマッパって使うのならごめん）
でも、PHPになじむかどうかは別問題なんだろうとは思う
0536nobodyさん
2008/05/12(月) 04:10:33ID:???0537nobodyさん
2008/05/12(月) 06:31:54ID:???私見だけど、メモリ中のオブジェクトをそのまま永続化させて使用するための
手段として RDBへの格納するのが良いのではないかっていう考え方があって、
でも現実には永続化よりもデータベース的な検索のほうが重要なことがはっきりして、
結局ラッパーとしてだけ生き残ったって感じではないかと思う。
まぁ、そうした抜け殻のようなツールとし出来上がった後、現場では >>532みたいなな
流れで流行ったんじゃないかと。
0538nobodyさん
2008/05/12(月) 07:26:54ID:???>とりあえず、外部からの入力値を元にしたSQLの動的な組み立てを自分でする気には
>あんまりならないんだが、モデルってそういう所の面倒をみるってことはそんなに重視
>されてないの？
思うに、「フレームワークのパワーを生かした」開発においては、そういう小難しいことは、
基本的にやらない、もしくは極力避けるんじゃないかね。
フレームワークが力を発揮するのは、単機能な画面が多数あるようなシステムだと思う。
そうした前提においては、動的なSQLを嫌ったとしても、それは普通な判断だと思うし。
0539nobodyさん
2008/05/12(月) 23:55:26ID:???http://tracfort.jp/projects/symfony-phptal
0540524
2008/05/13(火) 02:06:31ID:???いや、sfSmartyViewPluginは間違いなくsymfonyにとって改悪だと思うわ。
>>526
権限と責任が乖離している時点で、体制を考え直すべきだよ。
仮に、よほど信用出来なくて悪意があってとても偉いデザイナーと仕事をしてるとしても、
MVCやORMという概念や、symfonyやsmartyという実装は、
プログラマーとデザイナーの「責任の所在」を明らかにするための方法論では無いと思う。
>>528
俺はORMには否定的だけど、SQLを抽象化する事には肯定的。
0541nobodyさん
2008/05/13(火) 02:11:29ID:???因習的に使い続けてるところもあるだろ
そういうところのために出来ただけじゃねーの>smartyplugin
いちいち目くじら立てるようなものでもない思うが
0542524
2008/05/13(火) 02:23:12ID:???うん。>>484が偉そうにsymfony+smartyが完璧だと言ってたので、
そりゃねーよ、って反論してるだけだ。
よく考えればスレ違いな主張に相手してる気がするので、smartyに構うのは以後控えるわ。
0543nobodyさん
2008/05/13(火) 08:44:20ID:???>> プロジェクト内にテンプレート側にがちごりでロジック書くウンコいたらどうすんの？
>
>クビにするべきだろう。
大賛成。お金をもらう仕事に、なんでウンコな人間を混ぜなきゃいけないの?
>たぶんプログラムに制限を課すより、体制を考えなおしたほうがいいと思うぞ。
そうそう。それができない環境はプロとして仕事すべきじゃない。
>>526
> 本当にプログラマ？
> すぐクビにするとかテンプレート渡す＝責任を渡すとか
> 到底社会人の発想とは思えないんだが。
なんで? 使えない人間は教育し、それでも使えなければクビでいいじゃん。あんたどこの公務員よ?
> サンデープログラマや、開発者とデザイナが分かれてない業務しかやったことないのを否定はしないが、
> 分業化されてるプロジェクトの場合も想像できないと、この話を進めるのは無理だと思う。
分業することと、ウンコを混ぜる話は別だろ。それをいっしょくたにしているおまえがウンコ。
0544nobodyさん
2008/05/13(火) 10:54:49ID:???1つはJOINを駆使したりサブクエリーを使うようなSQLから生成されるデータを扱うにはハッシュの配列では使いにくかった。
SQLには方言があり簡単な文でさえダブルクォーテーションとクォーテーションの意味が違うなど複数のDBMSに対応しづらかった。
もう1つはORマッパー＝オブジェクト指向であり、ただのデータの出し入れに過ぎないSQLに様々な付加価値をつけることが出来た
（たとえばバリエーションなど）
■ このスレッドは過去ログ倉庫に格納されています