[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 1001- 2chのread.cgiへ]
Update time : 06/03 19:27 / Filesize : 221 KB / Number-of Response : 1002
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


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

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



1 名前:nobodyさん [2005/08/10(水) 02:21:08 ID:CBjrwwHd]
※フレームワーク
Phrame本家
phrame.sourceforge.net/
Mojavi Project
www.mojavi.org/
mojavijapan
mojavi.p0t.jp/
Agavi本家
agavi.org/
Agavi.JP
agavi.jp/
[ 日本発 ] Maple Project
kunit.jp/maple/
[ 日本発 ] Ethna -PHPウェブアプリケーションフレームワーク-
ethna.jp/ethna-tutorial-startup-practice1.html

※関連スレ
【PHP】フレームワークMapleに舌鼓
pc8.2ch.net/test/read.cgi/php/1122105465/
【PHPフレームワーク】Ethna【スケルトン自動作成】
pc8.2ch.net/test/read.cgi/php/1123070439/
PHPでオブジェクト指向プログラミング
pc8.2ch.net/test/read.cgi/php/1113724557/

その他>>2-5参照汁

225 名前:>>224 mailto:sage [2005/09/15(木) 02:33:20 ID:???]
そこそこ使えるらしい

226 名前:nobodyさん [2005/09/16(金) 04:57:46 ID:3ASb8eFe]
バリデートってフィルタの中でかけるのが普通かな?

227 名前:nobodyさん mailto:sage [2005/09/16(金) 05:14:40 ID:???]
>226
簡単、共通そうなものはそうなるんですかね?


228 名前:nobodyさん mailto:sage [2005/09/18(日) 10:58:42 ID:???]
>>227
複雑なのはアクションの中ってこと?

229 名前:nobodyさん mailto:sage [2005/09/18(日) 12:20:27 ID:???]
転送量で鯖屋から文句が来たから
出力をバッファして改行を削除する関数を
既存サイト(非フレームワーク)に適用した
ファイル修正しまくりで
こういう時にフィルタが役に立つんだなーと実感した

230 名前:nobodyさん mailto:sage [2005/09/18(日) 13:24:44 ID:???]
ヘッダ見て対応してれば圧縮すればもっといいんじゃないかな。
そんなのWebサーバでやれとも思うけど。

231 名前:nobodyさん mailto:sage [2005/09/18(日) 13:29:26 ID:???]
>>230
Apacheだったら
つ mod_gzip
まあデフォルトor設定のみでやってくれって気もするけど

232 名前:229 mailto:sage [2005/09/18(日) 16:46:51 ID:???]
一気に変えるのも不安だったから
zip圧縮はphp側のハンドラでやったよ
zipが受け取れないモバイルに対してもパケ代少し減らせるから
まぁいいかなと。
昔あったみたパケ割みたいなフィルタ作ってもいいかもしんない。

233 名前:nobodyさん mailto:sage [2005/09/18(日) 22:22:34 ID:???]
改行削除くらいじゃいくらも圧縮できないんじゃないの。



234 名前:nobodyさん mailto:sage [2005/09/18(日) 23:50:42 ID:???]
まあ、確かにそうなんだけど
でも×アクセス数になると馬鹿にならないかなと。
一回書けばコストもかからないしね。
しかし昔書いたプログラムを今いじると汚いこと汚いこと…
アンチパターンやりまくりで保守性最悪
フレームワークはある程度枠にはめるから
矯正器具としての役割もあると思う

235 名前:227 mailto:sage [2005/09/19(月) 23:44:54 ID:???]
>228
アクションの中にビジネスロジックを書くのはイケテないからコンポーネント作って呼ぶんですかね?

236 名前:nobodyさん mailto:sage [2005/09/20(火) 00:50:27 ID:???]
>>235
ビジネスロジックはモデルでやってください。

237 名前:nobodyさん mailto:sage [2005/09/20(火) 18:56:18 ID:???]
>>214
幽霊ユーザちゃんと含めて考えてますか?

238 名前:nobodyさん mailto:sage [2005/09/21(水) 04:10:55 ID:???]
最近Mojavi/Agavi静かだな…

239 名前:nobodyさん mailto:sage [2005/09/22(木) 21:14:04 ID:???]
日経システム構築に
PHPフレームワークの記事があった
1Pだけだけど

240 名前:nobodyさん [2005/09/23(金) 07:18:01 ID:7QvlMC8T]
PHP5の新機能に対応したフレームワークというのはどのくらいあるんでしょうか?

・例外による(フレームワーク側の)エラーの管理
・interfaceや抽象クラスを使った継承による機能の実装
・オブジェクトの逆参照

あたりを利用すると、かなりすっきりしたフレームワークが書けるんじゃないかなー、と、俺フレームワークを書いてみたりしてるのですが……。

……ますますJavaとの違いが無くなってしまう様な気もしないでもありません(^^;

241 名前:nobodyさん mailto:age [2005/09/23(金) 10:10:02 ID:???]
mojaviつかったら、header("Location: http… ってつかっちゃいかんの?
$controller->forward(… に統一すべき?

242 名前:nobodyさん mailto:sage [2005/09/23(金) 10:34:02 ID:???]
>>241
$controller->redirect($url)を使うんじゃない?

243 名前:nobodyさん mailto:sage [2005/09/24(土) 00:01:50 ID:???]
うむ。



244 名前:nobodyさん mailto:sage [2005/09/24(土) 01:54:49 ID:???]
>>242
しっかし$controller->redirect($url)って使いづらくないか?
$controller->redirect($module, $action)にしてくれたほうがありがたい希ガス。
まー大した違いじゃないんだけどさ。
ラッパ書いたら気持ち的にずいぶん楽になったもんで。

ビミョーにチラシ

245 名前:nobodyさん mailto:sage [2005/09/24(土) 02:19:29 ID:???]
>>244
俺もモジャ使ってる時それ思ったな
module,actionをurlにするメソッドあったよね。
あれ呼んでから呼べということなんだろうけど。

246 名前:nobodyさん mailto:sage [2005/09/24(土) 03:41:42 ID:???]
>>245
だったらフレームワークが自分で自動的に呼べって話だよなー

247 名前:nobodyさん mailto:sage [2005/09/24(土) 10:58:21 ID:???]
で、>>244 に戻る、と。

Agavi で標準装備して貰いますか。

248 名前:nobodyさん mailto:sage [2005/09/25(日) 23:54:29 ID:???]
>>245
getControllerPathでしょ?

249 名前:nobodyさん mailto:sage [2005/09/26(月) 01:24:18 ID:???]
>>248
M2にはあったのにM3にはなくなってしまった。
アガビにもない。

250 名前:nobodyさん mailto:sage [2005/09/26(月) 16:39:07 ID:???]
Mojaviでサブテンプレート実現する時って
ActionChainにregisterしてexecuteしてfetchした結果を
Viewに渡してる?
それとも他のやり方があるのかな?

251 名前:nobodyさん mailto:sage [2005/09/26(月) 18:00:20 ID:???]
>>250
mojaviのwikiにサンプル付きであったような気がするけど今はアクセスできないっぽ。
ttp://www.geocities.jp/toyprog/wikimojavi/index.html
にそれの訳っぽいのがある。

252 名前:250 mailto:sage [2005/09/26(月) 19:59:45 ID:???]
>>251
ありがとう
Mojavi系サイトはかなり回ったつもりだったけど
このサイトは初めて知ったよ

253 名前:nobodyさん mailto:sage [2005/09/27(火) 04:52:10 ID:???]
>>244
クエリがmoduleとactionだけなんてことまずほとんど無いだろ。



254 名前:244 mailto:sage [2005/09/27(火) 07:02:06 ID:???]
まあ実際書いたラッパの引数はmodule、action、params、プラスアルファみたいな感じだけど、
漏れの場合サイト内でリダイレクトすべき部分は大概moduleとactionで事足りたな。
リダイレクト自体そんな頻繁でもないし。

ヒント:ケースバイケース

255 名前:nobodyさん mailto:sage [2005/09/27(火) 10:04:39 ID:???]
Agaviも全然動きないってどうなんコレ
仕事で使わないでヨカッタよ( ´ー`)フゥー...

256 名前:nobodyさん mailto:sage [2005/09/27(火) 12:00:15 ID:???]
(Moj|Ag)aviを仕事で使ってる香具師なんかいないいない。
みんな本当は趣味でやってんだよ。
あー暗い暗い。

257 名前:nobodyさん mailto:sage [2005/09/27(火) 13:39:45 ID:???]
Mojaviにはメンテナを迷走させる呪いがかかっているんだよ
ホープ・ダイヤモンドのように・・・

258 名前:nobodyさん mailto:sage [2005/09/27(火) 13:45:00 ID:???]
上位でRequest->Parameterを
取得していて、
ActionChain中の子Actionでも同じパラメータを使う時って、どうしてる?

1 Request->attributeにでも入れ直す
2 もう一度request->getParameter()する



259 名前:nobodyさん mailto:sage [2005/09/27(火) 14:21:10 ID:???]
>>251
そこ見てやっとデコレーションパターンを理解したよ
slotでテンプレートに渡す表示用パラメータを切り分けてるのが便利そう

260 名前:nobodyさん mailto:sage [2005/09/27(火) 19:38:07 ID:???]
MapleやEthnaにCommandパターンが使われてるって
本に書いてあったんだけど本当?

261 名前:nobodyさん mailto:sage [2005/09/27(火) 20:59:19 ID:???0]
Actionがあるのがコマンドパターンだよ
ほとんどのフレームワークはそれでは?

262 名前:nobodyさん mailto:sage [2005/09/28(水) 01:31:23 ID:???]
>>255
あれ以上変にいじくられる必要も無い。


263 名前:nobodyさん mailto:sage [2005/09/28(水) 01:34:22 ID:???]
>>254
つーかforwardじゃいかんのか



264 名前:nobodyさん mailto:sage [2005/09/28(水) 02:20:56 ID:???]
>>254
ヒント:リダイレクト自体そんな頻繁でもないし。

265 名前:nobodyさん mailto:sage [2005/09/28(水) 06:35:26 ID:???]
>>262
まだ埋まってないとこポコポコあるじゃん

266 名前:nobodyさん mailto:sage [2005/09/28(水) 07:00:02 ID:???]
なんかサブテンプレートってさー
クライアントサイドプログラムだったら、
サブウインドウとかの規格を定めた
アピアランスクラスを作って、
そこにモデルデータを渡して実現するじゃん?
アピアランスクラスはリプレース可能にして。

一方Mojaviとかのウェブアプリフレームワークって
各テンプレートファイルをひな形にした
サブテンプレートを先に作っておいて、
親テンプレートに後からハメハメするやり方じゃん?
このやり方だと、親テンプレートとサブテンプレートに
一貫したアピアランスを実現しにくくない?
なんていうか、
サブテンプレートシステムを
ひとつのクラスにまとめておかないと
アピアランスのリプレースがしにくい、と思う。
どうなんかな、このへん。

267 名前:nobodyさん mailto:sage [2005/09/28(水) 13:50:54 ID:???]
なんかカタカナばかりだな。
今風なのか?

268 名前:nobodyさん mailto:sage [2005/09/28(水) 14:11:20 ID:???]
いや日本語でどう言えとw

269 名前:nobodyさん mailto:sage [2005/09/28(水) 14:11:53 ID:???]
ああ、たしかにナウでヤングなモボっぽいな

270 名前:nobodyさん mailto:sage [2005/09/28(水) 16:24:02 ID:???]
アピアランス = 外観
テンプレート = 雛形
リプレース = 入れ替え
ハメハメ = 嵌め込む
サブ = 男色


271 名前:nobodyさん mailto:sage [2005/09/28(水) 21:39:30 ID:???]
>>270
・・・男色の雛形は
単一化されないと
見た目ではハメ辛いと思う。
どうなんかな、このへん。
【意訳】
ぱっと見、ゲイはゲイらしくしてくれないと
そのときになってびっくりする。
どう思いますかみなさん。
【私の意見】
そー思います。


272 名前:nobodyさん mailto:sage [2005/09/29(木) 02:01:15 ID:???]
カタカナ語は「一般名詞ではなく、テクニカルタームですよ」という
サインだから
単なる訳以上の機能性もある。

273 名前:266 mailto:sage [2005/09/29(木) 11:21:35 ID:???]
サブテンプレート間で一貫したアピアランスを実現する方法を考えたよ(´・ω・`)
共通プレゼンテーションロジック保持クラス
GrobalViewHelperを作っておいて
どのテンプレートを作るときにもそいつを派遣しておく…(・∀・)コレダ!!



274 名前:nobodyさん mailto:sage [2005/09/29(木) 11:28:07 ID:???]
Globalだった(´・ω・`)

275 名前:nobodyさん mailto:  [2005/09/30(金) 16:21:47 ID:???]
いいかお前ら、ド素人の俺が今からすっごいこと言うぞ・・・・
気の弱い奴はパンツ脱いどけ。。。。

「っていうかフレームワークって何だよ!?」

276 名前:nobodyさん mailto:sage [2005/09/30(金) 16:42:01 ID:???]
>>275
『枠組み』の事です。従来のライブラリと比較すると

ライブラリではそれを使ってどのように作るかを必死に考えなければならなかったのが
フレームワークでは、このように作りますってのがフレームワーク側で決まっているので
共通できないロジックやパラメータだけ与えればアプリケーションが出来てしまう。

277 名前:nobodyさん mailto:sage [2005/09/30(金) 16:45:14 ID:???]
どの程度勝手に決められているのか?ってのが
フレームワーク選択基準のひとつになり
例えばStrutsなんかは自由度が高い事で有名。

278 名前:nobodyさん mailto:  [2005/09/30(金) 19:43:03 ID:???]
>>276
親切にありがとう。
でもド素人にはまだちょっと理解しづらい。。。

つまりアレか、PHPでも、VBみたいにマウスでフォームやボタン配置できるとか??

279 名前:名無し [2005/09/30(金) 19:47:16 ID:gpQXP9hq]
どうもこんばんわ

280 名前:nobodyさん [2005/09/30(金) 19:47:48 ID:gpQXP9hq]
はじめてです


281 名前:nobodyさん [2005/09/30(金) 19:49:19 ID:gpQXP9hq]
いきなりですけどおちます

282 名前:nobodyさん mailto:sage [2005/09/30(金) 22:22:00 ID:???]
和製フレームワークって
Viewクラス用意してないものがほとんどだよね。
実際Viewでやることってテンプレートにassignするだけ
みたいなもんだし。
面倒なだけのViewイラネ(゚д゚)、ペッ

283 名前:nobodyさん mailto:sage [2005/09/30(金) 22:26:22 ID:???]
じゃあ、いいじゃん



284 名前:nobodyさん mailto:sage [2005/09/30(金) 22:43:42 ID:???]
あとMojaviはRequestのattributesと
UserのParameterが役割的にカブってるのが美しくない。
シンプルイズベストなんじゃい(*゚д゚)、ペッ

285 名前:nobodyさん mailto:sage [2005/10/01(土) 03:49:30 ID:???]
>>284
どうかぶってんの?

286 名前:nobodyさん mailto:sage [2005/10/01(土) 03:58:54 ID:???]
セッションの実装がねぇ。
逆にどうすりゃいいんだ?今ならいい方法があれば提案出来るんじゃないか。

つーかおまいらがどうやってるのか不思議で仕方ない。
どう文句つけようと、PHP5 だと現状、俺 Maple, Mojavi の二択だと思うんだが。
それ以外のフレームワークを実戦投入したという話は聞いたことないし。

287 名前:nobodyさん mailto:sage [2005/10/01(土) 04:03:57 ID:???]
>>285
両方とも汎用コンテナ
かぶってるからuser->parameterはあまり使わないけど

288 名前:nobodyさん mailto:  [2005/10/01(土) 11:04:43 ID:???]
やはりフレームワークの「意味」と「利点」、「用途」がサッパリわからない・・・
実はこれらを説明するのって難しい?

289 名前:nobodyさん mailto:sage [2005/10/01(土) 12:04:04 ID:???]
>>288
解っちゃえば何てことない話なんだけど説明しようとすると難しい

例えばDBとか使ったサイト作るっしょ
んで別のサイトを作る時に,前作ったサイトのパーツを流用したりするっしょ
で,それを繰り返してくと,今度は逆に,パーツの方を流用しやすく作るようになるっしょ

そういうパーツが色々な機能を網羅していくと
最終的には「サイトごとに同じような処理はみんな共通」とか
「ここをちょっと変えるだけで各サイトに適用可能」とかになっていく
その集合体の完成形がいわゆる「フレームワーク」

……ってな説明でどうかなぁ?

# もちろん今あるフレームワークが上記のようなボトムアップで作られたものなわけではないが……


290 名前:nobodyさん mailto:sage [2005/10/01(土) 13:33:56 ID:???]
>288
小規模の案件やってる限りはわからないし、使う必要も無いよ。
フレームワークの利点がわかる状態、というのがフレームワークが必要な状態。

291 名前:nobodyさん mailto:  [2005/10/01(土) 14:20:43 ID:???]
>>289
なるほどぉ・・・、ってことは、いま自分がやってる作業(この部分は他でも
使いまわしやすいように作ろう)ってのも、ある意味で自作フレームワーク??

それを追及していくと、ほとんどどんなサイトやシステムでも部品は共通なものばかりだよね。
よっぽど斬新なものでない限り、既存の部品を既存の組み立て方すればいいだけだよねぇ。
フレームワークがそういうものだとしたら、Webアプリ作成が劇的に簡単になりそう。
・・・でもMojaviとかの説明を読んだりすると、もうそれ自体が難しく感じる。。。

>>290
ってことは、俺はまだ必要な状態ではないのかな・・・。

292 名前:nobodyさん mailto:sage [2005/10/01(土) 14:42:28 ID:???]
>>291
ある意味「俺フレームワーク」とかいわれるものがソレなんだと思うよ
そして他人が書いた「俺フレームワーク」は慣れるまでは大抵使いにくい
ただ自分より頭の良い人が書いたものならたぶん慣れれば自分のより効率良くなるのだろう
でもそれは今まで自分が思いつきもしなかったような発想で作られていたりするから
学習曲線の最初はだいぶきっつかったりする

>>290の言ってるのは
慣れちゃった後なら小規模案件でも使わない理由はないと思うけど
小規模案件のためにわざわざ慣れる必要があるかってーと
それではC/P比が悪い,ってことじゃないかな
大規模だと少しでも効率良くなるとかける人数で効くので大きいのと
よく整備されたフレームワークはそれに則ったコードを書けばいいのでコードが変に発散しにくいのが利点

293 名前:nobodyさん mailto:sage [2005/10/01(土) 14:45:18 ID:???]
デザイナ含めて3人ぐらいの小規模しかつくらないけど
俺は「俺フレームワーク」捨てちゃいたい時ある。糞コードだもんなあ



294 名前:290 mailto:sage [2005/10/01(土) 14:45:40 ID:???]
>291
覚えると気持ちの上での楽さはあるけどね。
MVCの切り分けや入力値チェックなどを、どこに書くべきかを含めて明示的に示してくれるわけだし。
でもフレームワーク使ってなかった頃はそんなの自分で勝手に分けて書いてたわけだし
数週間くらいでできるような案件を一人でやるなら
無いなら無いで普通に作れるし、大して手間も変わらないように思う。

そんなこと関係なしに、興味があるなら使ってみるのが良いよ。

295 名前:290 mailto:sage [2005/10/01(土) 14:47:50 ID:???]
>292
素晴らしいフォローが入ってる。
まったくその通りです。サンクス。

296 名前:nobodyさん mailto:sage [2005/10/01(土) 16:35:15 ID:???]
フレームワークは楽をするためのものと言われて、
実際そうなんだけど、
その楽さって「記述量が少ない楽さ」じゃないよね
記述量は、逆に迂遠に思える時も多々あって、
俺なんかは「ハァ?どこが楽なんだよ。面倒くさいだろ」と
反発を感じながら自分なりのお手軽メソッドを追加してたりしていって
気づいたら何だか見通しが悪くなってた。
提供者は
「コーディング量は、そんなに減らないし、逆に増えるかもしれません。ただし、長い目で考えると楽です」と言ってほしいところ。
最初から「とにかく楽したい」の精神で行くと、
その良さを理解するのに結構時間がかかる。

297 名前:nobodyさん mailto:sage [2005/10/01(土) 17:08:24 ID:???]
単純なものを作るとしても、フレームワーク使って作ると、
余計なこと考えないで済むから楽ちんだと思ってしまう漏れは負け組?

298 名前:nobodyさん mailto:  [2005/10/01(土) 21:01:51 ID:???]
とりあえずここまで説明してもらってもまだフレームワークの良さが
イマイチ分からない俺は、ちまちま自力でやっていこうと思いまつ。

そうしてるうちにフレームワークが必要になる日が来るかもしれない。
むしろ最初の基礎は全部自分でやれるようにしといたほうが後々いいかも。

299 名前:nobodyさん mailto:sage [2005/10/01(土) 21:10:53 ID:???]
ちまちまアセンブラで大規模アプリを書けるようにがんばります。ということ?
馬鹿馬鹿しい。


300 名前:nobodyさん mailto:sage [2005/10/01(土) 21:21:42 ID:???]
>>299
なんでいきなりアセンブラが出てくるんだ?
比喩にしてもおかしいし???

301 名前:nobodyさん mailto:sage [2005/10/01(土) 21:32:08 ID:???]
小さなプログラムを個人で書きなぐってるって人なんじゃないの?

仕事で似たような案件を多くあつかっていると、大枠で共通することが
多いことに気づいてくる。それをくくりだして同じ事を何度もしなくても
いいようにしようと思うわけだ。
言語レベルではライブラリとして共有できるようになってる。
さらに扱う対象によっては毎回似たようなプログラムの流れになることがある。
その似たような部分の構成を使いまわしできるようにしておくと、効率があがる。

299さんの言っていることも極端ではあるけど考え方としては同じこと。
アセンブラがあれば何でも記述できるけど、WEBアプリなんか書く時にはPHPが
適しているのでPHPで書く。毎回アセンブラからまずPHP(あるいは俺言語)を作って
仕事に取り組むってのは能率悪そうでしょ?

ただフレームワークを必要としない人や場合もあるのだから 290さんの言うように
必要としていない状況なのかもしれない。

302 名前:nobodyさん mailto:sage [2005/10/01(土) 21:38:29 ID:???]
ちょっと流れ無視なのかもしれませんが、
クラス・ライブラリとフレームワークの違いって何ですか?

ライブラリ群=フレームワーク?と思っているんですが。

303 名前:nobodyさん mailto:sage [2005/10/01(土) 21:56:33 ID:???]
・画面遷移の仕組み
・入力データのヴァリデーション
・HTML表示のためのテンプレートエンジン
・セッション管理
・アクセス制御
あたりの機能を体系的にまとめたものが、いわゆるフレームワークと言っていいと思う。
特に上3つはフレームワークと呼ばれるものには必ず存在するかな。
ただ、それぞれの機能単独のライブラリもあるから、そういうライブラリを自分で組み合わせても構わないし、
そっちの方がいい場合もあるだろう。



304 名前:nobodyさん mailto:sage [2005/10/01(土) 22:48:16 ID:???]
保守性のメリットもあるお

305 名前:nobodyさん mailto:  [2005/10/01(土) 22:55:55 ID:???]
フレームワークの意味や利点が理解できない漏れは、
当然クラスの良さも分からないし使ったこともない。
「良さが分からない」というか、「使用法を習得するほうがめんどい」。

だからPEARも一度も使ったことなく(ちょっと調べて断念)、
よく使う機能については「俺ライブラリ」(せいぜい自作関数)的なものを作って
ファイルにまとめて、それをincludeしたり部分的にコピペして貼ったりして再利用してる。
それで十分便利だし苦にも思わない。

306 名前:nobodyさん mailto:sage [2005/10/01(土) 23:10:17 ID:???]
>>305
苦にも思わないならそれでいいんじゃないかな?
上で大規模小規模って話が出てきてるけど
大規模→大人数となってくるとそれを苦に思う人も出てくるだろう
その時になったらまた考えればいいと思う

繰り返しになるけど,最初の学習曲線をよじ登る手間が,
初めから登らなかった場合の手間の総量を上回らないなら,登らない方がトータルで良いしね

ただ経験から言わせてもらうと,
仕事でPHPをやってる限り,結果的にはたぶん総量を上回ることになると思う……

307 名前:nobodyさん mailto:sage [2005/10/02(日) 00:39:45 ID:???]
まあ、PHPは標準関数の機能が多いから、PEAR使わなくても構わない場合は多いけどな。
Perlの場合、CGI、DBI、HTML::Template、CGI::Sessionあたりを使わざるを得ないけど。
ただし、PHPは名前空間が区切れないから、クラスを使わないとグローバル変数名の衝突をさけられない。
なんで、処理がある程度複雑になってきたら、クラスを使うしかなくなる。

308 名前:nobodyさん mailto:sage [2005/10/02(日) 01:42:18 ID:???]
自分1人で開発してるうちは
フレームワークの恩恵はそれほどないかもしれない
小規模のものを作るのには必要ない
単純なメールフォーム作るのにフレームワークなんていらない

複数人でそれなりに規模のあるものの
開発をしようとするとそれぞれのスキルと作り方で
同じ処理の流れのものを作っていても
コードや構成はばらついていく

だから遷移方法や処理のプロセスはこういうやり方で
ここにそのコードを置いてくださいという
取り決めがフレームワークで
チーム全員がその取り決めにならって開発していく事で
誰が書いても全体の構成がある程度統一されていく部分が
フレームワークを使う事の一番のメリットなんじゃないのかな

309 名前:nobodyさん mailto:sage [2005/10/02(日) 02:06:00 ID:???]
PHPには、PerlのCGI::ApplicationやJavaのStrutsほどメジャーなものはないし、開発者全員がそのフレームワーク自体を覚えないといけないってコストがかかる。
他にもデメリットとして、smartyのようなテンプレートエンジンを使うと実行速度がぐっと下がるし、
標準であるべきDBクラスのPEAR_DBは、標準関数と比べて圧倒的に速度が遅い。代替のDBクラスもあるけど、これも乱立していて学習コストがかかる。
さらに言うと、PHP開発者のスキルは概して低い。
PHP開発者の確保は、Perl開発者、Java開発者の確保よ低コストだけど、PHPでOOPやフレームワークを扱える開発者をそろえるのは難しい。
こういったデメリットを乗り越えて、なおフレームワークにメリットがあるかどうかを考えないといけない。

310 名前:nobodyさん mailto:sage [2005/10/02(日) 02:36:39 ID:???]
PHPのスレで言うのもアレなんだがRubyのRails試してみるといい。
あとAppleのWebObjectsとか。Gauche(Scheme)なKahuaも
ええよ。

311 名前:nobodyさん mailto:sage [2005/10/02(日) 09:25:07 ID:???]
ライブラリは自分の書いたコードがライブラリのコードを呼び出す
フレームワークは自分の書いたコードがフレームワークのコードから呼ばれる

基礎の基礎。

312 名前:302 mailto:sage [2005/10/02(日) 09:44:41 ID:???]
>>303
分かりやすい説明ありがとうございます。
Webアプリ用のフレームワークについてはなんとなく分かったような気がします。
でも「Mac OS XのCocoaフレームワーク」なんていうのを
聞いたことありますが、あれはHTMLとは関係ないですよね。
そういう場合はどう考えればいいのか。

>>311
呼び出す方向による分類は新鮮です。いや、これに関しては無知でした。
デスクトップ・アプリで言うところのイベント駆動型かどうかという分類でしょうか。
ありがとうございます。

313 名前:nobodyさん mailto:sage [2005/10/02(日) 10:35:14 ID:???]
チーム開発のメリットだとしても、それフレームワーク使うより、
PECLで独自の拡張関数を増やすほうがよろしいんじゃないでしょうかね




314 名前:nobodyさん mailto:sage [2005/10/02(日) 13:12:15 ID:???]
扱っている案件において検討した結果
そういう結論に至ったのならそういうケースもある。

当然フレームワークを利用する方が良いケースもあるでしょう。


315 名前:nobodyさん mailto:sage [2005/10/02(日) 13:18:58 ID:???]
PECLで独自関数っていうとCで拡張モジュールを書くということ?
それがチーム開発においてプラスになるのはかなり特殊なケースに思えるけど。

ていうかそんなの実際にあるんかいな。

316 名前:nobodyさん mailto:sage [2005/10/02(日) 16:48:05 ID:???]
あなたまかせの特定のフレームワークを使い倒すよりは、
独自拡張をあわせたほうがいい気はするけどな


317 名前:nobodyさん mailto:sage [2005/10/02(日) 16:59:18 ID:???]
>>311
シンプルだけど本質的な定義だな。

318 名前:nobodyさん mailto:sage [2005/10/02(日) 19:28:25 ID:???]
$context =& $this->getContext();
$controller =& $context->getController();
$request =& $context->getRequest();
------------
$controller =& $this->getContext()->getController();
$request =& $this->getContext()->getRequest();

あなたはDOTCH派?

319 名前:nobodyさん mailto:sage [2005/10/02(日) 19:39:32 ID:???]
そもそも PHP4 じゃ前者でしか書けない罠

320 名前:nobodyさん mailto:sage [2005/10/02(日) 22:32:53 ID:???]
どっちも意味不明派。

321 名前:nobodyさん mailto:sage [2005/10/02(日) 22:42:00 ID:???]
後者は&いらないんじゃないか?

そんな自分は「= &$foo」派

322 名前:nobodyさん mailto:sage [2005/10/03(月) 04:04:57 ID:???]
>>318
PHP5では&はいらないわけだが。
むしろそのへんのことも含めMojavi系は面倒くさいので、そっとごみ箱にいれた派。

323 名前:nobodyさん mailto:sage [2005/10/03(月) 09:12:25 ID:???]
>>322
めんどくさいかなぁ??
フレームワーク使わずにどうWebアプリ構築してるのか知りたい。
べた書き?後から見辛くない?



324 名前:nobodyさん mailto:sage [2005/10/03(月) 09:14:42 ID:???]
別にPHP4だから、かならず参照渡ししないといけないわけじゃない。
対象のオブジェクトや配列の複雑さの程度だとか、後から値を変えたいかとかによる。

325 名前:nobodyさん mailto:sage [2005/10/03(月) 10:55:25 ID:???]
>>324
まあ確かにそうだけどさ、プロパティを変えないつもりでオブジェクト値渡ししといたら、後々になってからやっぱりプロパティを変える操作をした場合に辻褄あわなくなるじゃん。
PHP4だったら常に参照渡しにしたほうが楽な希ガス。






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

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<221KB

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