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

[表示 : 全て最新50 1-99 101- 201- 301- 401- 501- 601- 701- 2chのread.cgiへ]
Update time : 12/06 21:08 / Filesize : 167 KB / Number-of Response : 790
[このスレッドの書き込みを削除する]
[＋板最近立ったスレ＆熱いスレ一覧 : ＋板最近立ったスレ／記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

1 名前：nobodyさん mailto:sage [2008/08/24(日) 21:43:37 ID:???]: 前スレ
pc11.2ch.net/test/read.cgi/php/1202521438/
72 名前：nobodyさん mailto:sage [2008/08/30(土) 20:57:57 ID:???]: それが分からない人達がフレームワークを作ることに意味があるとは思えない
既存のものを使った方がいいのでは？
73 名前：nobodyさん [2008/08/30(土) 21:07:18 ID:/jeGwvoC]: 回答ありがとうございます。
私も車輪の発明になる気がしてどうも１００％乗り気になれないのです。
ちなみに72さんは自作フレームワークの作成または、
既存のフレームワークで、ずっと使い続けてるものありますか？
74 名前：nobodyさん mailto:sage [2008/08/30(土) 21:12:11 ID:???]: >>72
オープンソース全面禁止とかいう規則の会社もあるらしいし、
意味が無いかどうかはわからないのでは？
（PHPやApache自体もオープンソースだから、それはないかもだけどｗ）

>>71
フレームワークを利用する目的って、多分複数案件で使い回す事が出来て、また
複数の開発者で、またある程度の期間にわたって共通認識・理解をもつことで、
開発コストおよび保守コストを抑えることだと思うんだ
後は、基本的な部品を気合い入れて作ることで、品質の最低ライン（主にセキュリティ面など）を
保証するという意味合いもあるけど

だから、どこまでというのは程度問題でしかないと、個人的には思う
やりすぎれば使い回しに自由がきかなくなったりするし、緩すぎれば保守コストの
軽減には役に立たなかったりするんじゃない？

極端に言えばディレクトリ構造を決めて使い回すだけでも、ある意味「フレームワーク」
だと思う
75 名前：nobodyさん [2008/08/30(土) 21:29:08 ID:/jeGwvoC]: >>74
>だから、どこまでというのは程度問題でしかないと、個人的には思う
なるほど、なかなか外部の方との技術意見交換をする機会がなくて参考になります。
ありがとうございます。

実は1ヶ月ほど前に公開になったあるBtoBのWebサービスで
MVCではないですが、自作でフレームワークを作ってみました。
少しは楽できるのですが、ホントに方向性的に合ってるのか、
若干迷いつつあるんです。
上からMVCモデルのフレームワークを準備してくれと頼まれた中で、
また０から準備することが本当に必要なのか迷ってまして。。。
この掲示板でやめた方がいいなと思ったとしても
やらないといけないことには変わりないんですけれど。
76 名前：nobodyさん mailto:sage [2008/08/30(土) 21:46:18 ID:???]: MVCにこだわるなら
　・各データの出し入れの基礎的な記述と、各データごとのロジック
　・表示に関する基礎的な記述とロジック
を、実行スクリプトから切り離すのが最低限？
例えば、昔よく見た

<?php
// DB接続処理ほげほげ
　（省略）
　$sql = 'SELECT * FROM customer;';
$ret = mysql_query($sql, $db);
$rows = array();
while($row = mysql_fetch_assoc($ret)){ $rows[] = $row; }
?>
<html>
（略）
<?php
　foreach($rows as $row){
　　（略）
}
?>
（略）
</html>

なんてのを、どう分けるか、何のために分けるか、というお話だと思うんだ。
その具体的な分け方・方向については・・・うーん俺は人に教えるほど
きちんと勉強していません。頑張れ！（ｵｲ）
77 名前：nobodyさん [2008/08/30(土) 22:03:54 ID:/jeGwvoC]: >>76
ありがとうございます。参考にさせていただきます。
78 名前：nobodyさん mailto:sage [2008/08/31(日) 11:40:02 ID:???]: >>75
えーとな。
まずフレームワークを使ってから
考えれ。
79 名前：nobodyさん mailto:sage [2008/08/31(日) 18:59:51 ID:???]: >>75
>>78の言うように
まず既存のフレームワークを利用してみて、長所や短所を理解してから、
自分(とその周り)が使うに当たって必要な構造としてどうなってると使いやすいか考えて
設計しなきゃいけないんでない？

CIスレとかCakeスレで出てる疑問とかそこらのブログで出てるような疑問とかも割りと参考になりそうな気がします。

後、巷ではやってるフレームワークは付属のライブラリが充実してるってのもポイントだったり。
Viewにはテンプレートエンジンを使う必要があるのかとかも考えたり。

>>71がどのように考えてるか分かりませんが、結構重そうな内容ですね。

で、俺もまた、人に教えるほどきちんと勉強していません。頑張れ！(ｵｲ)
80 名前：nobodyさん [2008/08/31(日) 22:02:43 ID:BcOgvLp9]: ありがとうございます。
ViewはSmartyの実績があるので、ほぼ確定かと思います。
あとはMCですね。
で、ご指摘の通り、既存のフレームワークをいくつか
実際に使ってみて、超シンプル版から作っていこうと思います。

それにしても結構種類ありますよね～。
81 名前：nobodyさん mailto:sage [2008/08/31(日) 22:18:42 ID:???]: >>80
とりあえずCakePHPとCodeIgniterは分かりやすいかな。
SinfonyやEthnaも人気あるっぽいけど。

後は、とりあえず有名なフレームワークをそのまま流用して、
自分の作りたい方向性に足りないものを追加/修正してやって、
作っちゃうっていう方向性も検討の余地がありそうです。
82 名前：nobodyさん mailto:sage [2008/08/31(日) 23:09:43 ID:???]: 骨は例えばちいたんでもいいのでは
他のはどうしても、流儀を覚えてそれに則らないと
カスタマイズも難しいような所があるし

ライブラリは、ぶっちゃけPEARやZendを引っ張ってきて、
そのままではごちゃごちゃになるなら、その一部のコードを、
流用して使えば済むことも多い
83 名前：nobodyさん [2008/08/31(日) 23:44:28 ID:BcOgvLp9]: >>81
なるほど、参考になります。ありがとうございます。
CodeIgniterは知りませんでした。勉強になります。

>>82
>流儀を覚えて
そうですよね。そのコストもありますよね。

ライブラリについては私も同感です。
PEARは今でも使ってますし、DBはADODBを使ってます。
84 名前：nobodyさん mailto:sage [2008/09/01(月) 07:50:32 ID:???]: しかし、PEARやADODBを使えるのにフレームワークは自作しなきゃならん意味が分からんな。
85 名前：nobodyさん mailto:sage [2008/09/01(月) 16:27:37 ID:???]: 勝ち馬に乗れなくてサポートが止まったらどうするんだ、とか、
複雑すぎると兵隊に書かせられないから却下
（自社開発なら開発者が目の前にいるから例外）とか、
その手の腐った理由かもな。

自作FWなんて最初からサポート止まってるも同然なんだけど。

あとあれだ、
FW使った分だけ工数が削減されるがそれじゃ困る、
なんていう理由じゃないか？
86 名前：nobodyさん mailto:sage [2008/09/01(月) 20:42:35 ID:???]: フレームワーク使うと大幅に工数下がるね。
でも、フレームワークを勉強するためのコストが要るね。

でもさ、そもそも最低限の勉強をしてから実践投入しろと。
フレームワーク＝最低限の勉強だよ。
87 名前：nobodyさん mailto:sage [2008/09/02(火) 15:46:31 ID:???]: 自分の印象では、CodeIgniterは分かりやすくて良かったです。
SymfonyとかCakePHPは、使い方を学習する段階で、面倒くさいな～と思ってしまいました。
辛抱強く性格でないと、じっくり腰をすえてフレームワークの使い方を学ぶ段階が苦痛に感じられますね？
Zend Frameworkも解説本は分かりやすかったです。
ちいたんはチュートリアルが不十分であると感じました。
EthnaやMapleは試してないので分かりません。

「日本向けの携帯サイトを作る」という視点で見た場合、各フレームワークの使いやすいさ、機能はどうでしょうか？
88 名前：nobodyさん [2008/09/02(火) 19:21:26 ID:kKY94AaP]: 一般的に、フレームワークでは、
データベースの外部キー制約を設置していた場合、
親テーブルの行を削除したら、
対応する子テーブルの行も削除されるようになっているのでしょうか？
89 名前：nobodyさん mailto:sage [2008/09/02(火) 20:08:08 ID:???]: >>88
参照整合性制約（外部キー）までチェックしてデータ操作してくれる
モデルを実装しているフレームワークは寡聞にして聞いたことが無い。
有ったら俺も知りたいな。
90 名前：nobodyさん mailto:sage [2008/09/02(火) 20:41:21 ID:???]: Zend_Dbはそんな感じのやつあったんじゃね？
91 名前：nobodyさん mailto:sage [2008/09/02(火) 20:51:11 ID:???]: ON DELETE CASCADEではだめなん?
DBのパフォーマンスのため、参照整合性制約を付けずにアプリケーション側で
実装する場合もあるとは思うけど、外部キー制約してるんだよね?
92 名前：nobodyさん mailto:sage [2008/09/09(火) 00:13:17 ID:???]: 既出だけどsabelなるフレームワークが出てるけど、最近はルーティングとかYAMLとかの設定ファイルに書かないのが流行りなの？
93 名前：nobodyさん [2008/09/13(土) 19:22:25 ID:lKt9XZcp]: テンプレートメソッドってだいたいprotectedにするじゃん
そしてzend規約では、protectedなメソッドの名前は_hogeにする
でも、子に_付きのメソッドのオーバーライドを求めるのって
何かきもくね？
_を付けるってのは、「内側で使ってる」っていうしるしで、
テンプレートメソッドは、子とはいえ、自分以外に実装をまかせるという、
ある種の外側志向。その齟齬がきもさの原因と思う。
publicにするか、規約を破るか、きもさを受け入れるか・・悩ましいぜ
94 名前：nobodyさん mailto:sage [2008/09/13(土) 21:34:17 ID:???]: そういう文化的な気持ち悪さはわかりにくいな
例えば private と protected をわけるスタイルもある
_ と __ とか（←わかりにくいｗ）

Zendは特にわけてないのかな？
95 名前：nobodyさん mailto:sage [2008/09/13(土) 22:06:52 ID:???]: __は__setとか__constratみたいのがあるじゃん
96 名前：nobodyさん mailto:sage [2008/09/13(土) 22:09:06 ID:???]: ↑予約メソッドをリストアップして回避すればいいじゃん
そんなに無いよ
97 名前：nobodyさん mailto:sage [2008/09/13(土) 22:11:08 ID:???]: そこはPHPが糞としか言いようがないな
せめて予約メソッドは、__set__ とか __clone__ とかにしておいてくれればｗ
98 名前：nobodyさん mailto:sage [2008/09/13(土) 22:12:10 ID:???]: めんどい
99 名前：nobodyさん mailto:sage [2008/09/13(土) 22:14:01 ID:???]: ___set っていうのもありか。

コーディングの自由度の幅や読みやすさを考えるなら、
いっそ予約されたメソッドなんかは

__reserved_method_CONSTRUCT()

くらいやってくれてもなんの問題もないしな
100 名前：nobodyさん mailto:sage [2008/09/13(土) 22:25:24 ID:???]: ->が一番嫌いなんだよな
.がいいよな.のほうがカッコいい
101 名前：nobodyさん mailto:sage [2008/09/13(土) 22:30:28 ID:???]: >>96
__ で始まるのは全部予約メソッドなんだが
102 名前：nobodyさん mailto:sage [2008/09/13(土) 22:35:44 ID:???]: >>100
そうすると、文字列連結が + になり、
連鎖的に toString() 的なメソッドが欲しくなり・・・

Cっぽいな strval() をがんがん使うつもりならそれでもいいが、
Perl派生言語のジレンマを、そう気軽に語ってくれるなｗ

>>101
それはPHPの「仕様」ではないよね。雰囲気ではそうかもだけど。
実際、ユーザ定義のメソッドで __ が使えない訳ではない。
103 名前：nobodyさん mailto:sage [2008/09/13(土) 22:53:57 ID:???]: protectedとprivateは別物なのに、_で一緒くたにしているのは、
ZF規約の欠点ではなかろうか。
ZF自体の作りの洗練されなさを考えると、
深い考えがあってそうしたものでもなさそう。
実際symfonyなんかは、Javaと同じでプレフィックス付けたりしてないし。
Rubyでもそんな習慣聞いたことない。
PHP4の呪縛を引きずってるだけじゃね？
こんな規約、いらないんじゃね？
104 名前：nobodyさん mailto:sage [2008/09/13(土) 22:59:30 ID:???]: >>103
publicと、private,protectedの区別をメソッド名でつけることは、
意味がないとは思わない

> protectedとprivateは別物なのに、

っていうのは同意だけどね
それについて、ここしばらくPHPの仕様がらみのレスが
付いてるように見えるんだがそれについてはどうなんだｗ
105 名前：nobodyさん mailto:sage [2008/09/14(日) 00:28:45 ID:???]: >>100
.のが使いやすいのは同意なんだけど、加算演算子と文字列連結演算子が別なのは
PHPの数少ない美点の一つだと思ってる。
106 名前：nobodyさん mailto:sage [2008/09/14(日) 01:05:36 ID:???]: >>105
それは単純にPerl由来なんだけどな。$ と同様に。
$ の使い方としては劣化してるし、この辺はもうPerl文化を切り捨てるか、
PHPの独自路線が欲しい所ではある
107 名前：nobodyさん mailto:sage [2008/09/14(日) 01:09:29 ID:???]: 配列が@とか%じゃないのは良いよな
あれきもいし
108 名前：nobodyさん mailto:sage [2008/09/14(日) 02:35:06 ID:???]: PHPってびっくりするほど独自路線というものが無い言語のような気が...
Perlの遺産だったり、Cが透けて見えたり、Javaのパクリだったり...
で、だからこそ普及しているんじゃないかな。

あと関係ないけどPHP6で常にUnicodeモードを有効にしたのは英断だと思う。
パフォーマンスやメモリへの影響も今時のサーバで問題があるほどでもないし。
5系から6への移行は大変かもしれないけど、それで仕事が増えるなら構わないw
109 名前：nobodyさん mailto:sage [2008/09/14(日) 03:31:07 ID:???]: ユニコードモードって何が変わるの？
110 名前：nobodyさん mailto:sage [2008/09/14(日) 04:04:33 ID:???]: 未だにPHP４とかの鯖あるし
４，５，６とか大変なんだが～
111 名前：nobodyさん mailto:sage [2008/09/14(日) 04:10:29 ID:???]: 新規案件で4の鯖はないっしょ。てか誘導しようよ
保守案件で4なら、ご苦労様としか言えぬｗ

6は、一応5.3と互換性を持たせるつもりみたいだね
その5.3が大変なんだろうけど、まだ見ないねぇ
112 名前：nobodyさん mailto:sage [2008/09/14(日) 09:51:48 ID:???]: 別にPHP4でも困らないけどな。PHP5の機能で役に立つのは例外くらいなもんだし。
113 名前：nobodyさん mailto:sage [2008/09/14(日) 10:42:39 ID:???]: オブジェクトが代入でコピーされなくなったのは、地味に気持ちいい
114 名前：nobodyさん mailto:sage [2008/09/14(日) 10:44:44 ID:???]: &付ければいいだけじゃん。
115 名前：nobodyさん mailto:sage [2008/09/14(日) 11:30:26 ID:???]: cloneだろ
116 名前：nobodyさん mailto:sage [2008/09/14(日) 14:34:14 ID:???]: 4だから困るとか言うよりは、2系統あるのが困る
117 名前：nobodyさん mailto:sage [2008/09/16(火) 20:53:37 ID:???]: >>115
コピーって言っちゃだめなの？
118 名前：nobodyさん mailto:sage [2008/09/16(火) 23:08:17 ID:???]: >>117
>115は>114に対して
119 名前：nobodyさん mailto:sage [2008/09/17(水) 13:33:07 ID:???]: PHPをやめるとしたら、何を使いますか？
・Ruby
・Python
・Perl

やっぱPythonかな？
120 名前：nobodyさん mailto:sage [2008/09/17(水) 13:35:32 ID:???]: Perlは個人的にないな。
121 名前：nobodyさん mailto:sage [2008/09/17(水) 13:41:27 ID:???]: >>119
仕事的には、PHPより高速で安定的に動作して、
月額1000円程度以上のレンサバには95%以上の確率で入ってるなら
なんでもいい。

そんなのある？
122 名前：nobodyさん mailto:sage [2008/09/17(水) 13:43:47 ID:???]: つPerl & FastCGI
FastCGIの方は、95%にはちと足りんかな？ｗ
123 名前：nobodyさん mailto:sage [2008/09/17(水) 13:50:56 ID:???]: Rubyに移行しようと思ったけど
ZendStudioがあるから結局PHP使ってる・・
124 名前：nobodyさん mailto:sage [2008/09/17(水) 18:12:51 ID:???]: 書いてて面白いのはPerlだね。
125 名前：nobodyさん mailto:sage [2008/09/17(水) 18:45:58 ID:???]: じょうだんよしこさん
126 名前：nobodyさん mailto:sage [2008/09/17(水) 22:00:15 ID:???]: PHPのつまらなさは異常
127 名前：nobodyさん mailto:sage [2008/09/18(木) 02:36:03 ID:???]: qiq入れればまだ楽しめるよ
128 名前：nobodyさん mailto:sage [2008/09/18(木) 16:41:27 ID:???]: ますかきおくん
129 名前：nobodyさん mailto:sage [2008/09/18(木) 16:49:43 ID:???]: qiq面白いとは思うけど
コードの依存部分が全体に広がるエクステンションを入れるのはやっぱり抵抗あるわ
もしそれがダメになった時のことを考えると
130 名前：nobodyさん mailto:sage [2008/09/18(木) 16:52:54 ID:???]: 楽しめても、業務利用は無理っしょ
まだRubyで楽しんでる方が健全じゃねーかｗｗｗ
131 名前：nobodyさん mailto:sage [2008/09/18(木) 19:11:26 ID:???]: 趣味用の言語ならもっとマイナーな奴でもやれよ
132 名前：nobodyさん [2008/09/18(木) 19:12:59 ID:ykJuPDO5]: >>129
別に、フレームワーク使ったってそのフレームワークに依存するじゃん
なんでQIQだと抵抗があるのか
133 名前：nobodyさん mailto:sage [2008/09/18(木) 20:57:09 ID:???]: そりゃあんた、なんか不可解な挙動があったときに、どこまで自分の力で
調べて修正できるのかって点で、違いすぎるだろｗ

ぶっちゃけ、PHPのコアに関わっている人間にとっての別実装や実験として
でもなければ、QIQなんておもちゃ以外の何者でも無かろうが
134 名前：nobodyさん mailto:sage [2008/09/18(木) 21:38:02 ID:???]: 将来PHPがバージョンアップして
qiqの開発が停止して非対応だったら
それまで書いたqiq依存コードがもろとも脂肪じゃん。
フレームワーク使っててもフレームワーク非依存なプレーンなクラスは書いていくし
そういうのは流用が効く。
135 名前：nobodyさん mailto:sage [2008/09/19(金) 00:57:48 ID:???]: PHPにもApacheにも何も保証があるわけじゃないのに。
PHP5依存コードが脂肪しない保証もない。
Zendと契約結んでる？　そりゃ失礼しました。
136 名前：nobodyさん mailto:sage [2008/09/19(金) 03:33:16 ID:???]: >>135
確率の問題
137 名前：nobodyさん mailto:sage [2008/09/19(金) 12:02:16 ID:???]: PHPのフレームワークと、土台のPHP・Apacheとを、どうやったら
同一視できるのか
また、ユーザの少ないというか皆無に近いQIQなるエクステンションと、
ばりばり商用利用され、長期間メンテの続いている普及率抜群の
プロジェクトとを同一視できるのも素晴らしい

>>132とか>>135とかは、きっと「フレームワーク」の中を調べたりましてや
いじったりなんて、思いもしないユーザなのかな？

ひょっとして全部同列に見えるくらいのスーパーハカーですか？
138 名前：nobodyさん mailto:sage [2008/09/19(金) 18:10:39 ID:???]: PHPユーザーは裾野が広いってことでしょう。
サンデープログラマーから職業プログラマーまで幅が広い。
QIQは素晴らしいエクステンションだから、PHPを支援しているIBMやマイクロソフトとかの大手企業に支援してもらったらいいんじゃないですか？＞作者の方
139 名前：nobodyさん mailto:sage [2008/09/20(土) 13:23:29 ID:???]: ラムダとか5.3で導入されるじゃん
qiqって何が素晴らしいの？
140 名前：nobodyさん mailto:sage [2008/09/20(土) 13:42:12 ID:???]: 前スレでさんざん出てた [] じゃね？
執着してる人が結構いるようだし
141 名前：nobodyさん mailto:sage [2008/09/21(日) 05:27:57 ID:???]: []とハッシュ{}はほしいねぇ
あと -> を . にすれば書くのも読むのも楽だ
142 名前：nobodyさん mailto:sage [2008/09/21(日) 05:32:43 ID:???]: C/C++の話かよｗ
143 名前：nobodyさん mailto:sage [2008/09/21(日) 18:00:01 ID:???]: >>137
>PHPのフレームワークと、土台のPHP・Apacheとを、どうやったら
>同一視できるのか

おいおい、PHPの安定性をApacheと同じにしないでくれよ。
どうせPHPだってver4のサポートなんてもう打ち切られるじゃん。
未来永劫サポートされるわけじゃないし、どっちもどっち。

PHPもフレームワークもQIQも、どれもオープンソースじゃん。
だれかのメンテに頼るのもいいけど、必要なら自分でメンテすればいいじゃんか。
QIQなんてただのライブラリにすぎないんだから、そのくらいできるだろ。
でかいフレームワークのコード読むよりは小さいQIQのほうが楽。
144 名前：nobodyさん mailto:sage [2008/09/21(日) 19:43:02 ID:???]: > QIQなんてただのライブラリにすぎないんだから、
ライ・・ブラリ・・・？

> でかいフレームワークのコード読むよりは小さいQIQのほうが楽。
確かにそうかもしれんが、QIQが何をやってどこを修正すれば
どうなるかってのをつかむ為には、少なくともCとBison(Yacc)と
PHPのCソースコードに関する知識が必要。
てか「楽」じゃねーよｗ
145 名前：nobodyさん mailto:sage [2008/09/21(日) 20:08:55 ID:???]: QIQのソースコード読むのが楽なわけないが。少なくともPHPのウェブフレームワークなんかよりは遙かにスキルが要求される。
146 名前：nobodyさん mailto:sage [2008/09/21(日) 21:37:07 ID:???]: あれはPHPの拡張モジュール作るのには必要ない、文書化もされていないようなAPIを叩いてるからね...
単体では短くても、理解しようとするとZend Engineのソースコード全体を見る羽目になるw

それとは関係ないけど、拡張モジュールを作るなら何気にPHP6はAPIが使いやすくなってる。
5.3もUnicode関連を除いてほぼ6相当だけど、便利な関数が5.3だけZEND_APIとしてエクスポートされていなくて切ないことも。
147 名前：nobodyさん mailto:sage [2008/09/22(月) 00:20:44 ID:???]: >>145
>QIQのソースコード読むのが楽なわけないが。少なくともPHPのウェブフレームワークなんかよりは遙かにスキルが要求される。
それはおまえがWebのスキルしかないから。コンパイラコンパイラの初歩知識があれば、見れば分かる。
自分が慣れてる分野のコードは読めて、知識のない分野のコードは読めないのは当然。
148 名前：nobodyさん mailto:sage [2008/09/22(月) 00:46:48 ID:???]: PHPで描かれたウェブのフレームワークとPHPのエクステンション、どっちが難解かは子供でも分かること
149 名前：nobodyさん mailto:sage [2008/09/22(月) 01:04:16 ID:???]: いや、量によって変わるから、どちらが難解かは一概に言えない。

ただいえるのは、PHPという言語仕様を非公式変えてしまうようなものは
公式でPHPそのものが変わったときに対応が困難になるから
使うのはやめておけってこった。
150 名前：nobodyさん mailto:sage [2008/09/22(月) 07:15:01 ID:???]: 公式でPHPが変わったら、どっちもどっちじゃない?
151 名前：nobodyさん mailto:sage [2008/09/22(月) 10:49:18 ID:???]: じゃない。
152 名前：nobodyさん mailto:sage [2008/09/22(月) 16:45:08 ID:???]: アホな質問かも知れないけど、cakephpライクなフレームワークを作ろうかと
思ってるんですが、マジックメソッドの __get使ってモデルやコンポーネントの
呼び出しを下のようにやってみたいんだけど、何か問題あります？

class HogeController extends Controller
{
　　function index()
　　{
　　　$data = $this->Model->classname->find();
　　　$this->Component->classname->hogehoge();
　　}
}
153 名前：nobodyさん mailto:sage [2008/09/23(火) 00:47:41 ID:???]: >>152
$this->Modelとか$this->Componentの__get()で、
与えられたクラス名のオブジェクトを生成・取得するって仕組み？
特に悪いとも思わないけど、必要とか便利とかもあんまり思わないｗ

例えば設計思想とか、利用時の利便性とかもあるんだろうけど、
同じ事をするのに、Model::factory()とかModel::singleton()でも
いい場合もあるかもだし

ピントはずれだったらｽﾏｿ
154 名前：nobodyさん mailto:sage [2008/09/23(火) 00:51:04 ID:???]: >>153 微妙に修正
> 同じ事をするのに、Model::factory()とかModel::singleton()でも
→ 同じ事をするのに、Model::factory(classname) とか new classname() とか classname::singleton() とかでも
155 名前：nobodyさん mailto:sage [2008/09/23(火) 02:07:19 ID:???]: new は method chain できないから却下
156 名前：152 mailto:sage [2008/09/23(火) 15:14:04 ID:???]: cakephpだとコントローラーのプロパティに
使うコンポーネント設定するのいちいち面倒だな～と思ってたんで。
そういうやり方もあるんですね、勉強になります。有り難うございました。
157 名前：nobodyさん mailto:sage [2008/09/23(火) 17:34:13 ID:???]: ∧＿∧
（　´∀｀）＜ぬるぽプロジェクト

みんなで面白いサイト作って有名にしようぜ！
yutori.2ch.net/test/read.cgi/news4vip/1222156869/
★まとめwiki
www39.atwiki.jp/vipproject/

PHPのフレームワークとして symfonyを採用予定です。
158 名前：nobodyさん mailto:sage [2008/09/23(火) 20:55:42 ID:???]: >>157
スレ荒れすぎワロタ
159 名前：nobodyさん mailto:sage [2008/09/23(火) 21:24:50 ID:???]: >>158
自動保守おいしいです（^q^）
160 名前：nobodyさん mailto:sage [2008/09/26(金) 16:21:57 ID:???]: フレームワークとは直接関係ないけど5.3でspl_autoload_register(function($name){...});
すると実際にautoloadされるときにbus erorrで落ちるね。
spl_autoload_register($f=function($name){...}); なら$fが生きている間だけは落ちない。
161 名前：nobodyさん mailto:sage [2008/09/26(金) 16:42:24 ID:???]: 5が出ても枯れるまで結構時間かかったし
6も使えるようになるまでは長いだろうなぁ
162 名前：nobodyさん mailto:sage [2008/09/27(土) 08:37:12 ID:???]: 一人で最初期モックアップ作るなら、
railsとcakephpと、どっちが向いてる？
163 名前：nobodyさん mailto:sage [2008/09/28(日) 11:02:03 ID:???]: その比較って意味あるのかな？
Ruby（少なくともRails）とPHPが同等にできる人にとってしか答えようがないし、
回答もしかりw
164 名前：nobodyさん mailto:sage [2008/09/28(日) 11:49:26 ID:???]: cakeみたいな厨フレームワーク使ってる人恥ずかしくないんですかぁ
165 名前：nobodyさん mailto:sage [2008/09/28(日) 15:59:10 ID:???]: んじゃ何使えばいいの？
166 名前：nobodyさん mailto:sage [2008/09/28(日) 18:15:32 ID:???]: ☆Z☆E☆N☆D☆!!
167 名前：nobodyさん mailto:sage [2008/09/28(日) 22:06:23 ID:???]: Zend…

無いわー
168 名前：nobodyさん mailto:sage [2008/09/28(日) 23:15:36 ID:???]: zend使いまくりだけど
何が不満なのかわからない
169 名前：nobodyさん mailto:sage [2008/09/29(月) 06:03:55 ID:???]: モックならちいたんで良いジャマイカ。
170 名前：nobodyさん mailto:sage [2008/09/30(火) 00:08:37 ID:???]: モックなら素のPHPでいいよ
171 名前：nobodyさん mailto:sage [2008/09/30(火) 00:17:33 ID:???]: モックはHTMLで十分なこともおおくない？ｗ
ヘッダフッタ辺りのレイアウトとかで楽したいなら、
手慣れたテンプレートエンジンがあればいいかもだけど

フレームワークってのとはちょっと違うような
多分必要なのはView側の省力化・柔軟性かなあ
172 名前：nobodyさん mailto:sage [2008/09/30(火) 00:41:51 ID:???]: マックでいいよ

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef