トップページ⇒php
1001コメント284KB

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

■ このスレッドは過去ログ倉庫に格納されています
0001nobodyさん2005/08/10(水) 02:21:08ID:CBjrwwHd
※フレームワーク
Phrame本家
http://phrame.sourceforge.net/
Mojavi Project
http://www.mojavi.org/
mojavijapan
http://mojavi.p0t.jp/
Agavi本家
http://agavi.org/
Agavi.JP
http://agavi.jp/
[ 日本発 ] Maple Project
http://kunit.jp/maple/
[ 日本発 ] Ethna -PHPウェブアプリケーションフレームワーク-
http://ethna.jp/ethna-tutorial-startup-practice1.html

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

その他>>2-5参照汁
0685nobodyさん2005/12/05(月) 16:17:35ID:dKNEsuCU
>>684
個人的には maple。
もっとも、そのままじゃ実用に耐えないからかなり改造して使ってるが。
0686nobodyさん2005/12/05(月) 16:20:36ID:???
俺は大したもん作らないからguessworkの自主改造版ぐらいで丁度いい。
0687nobodyさん2005/12/05(月) 16:20:50ID:???
>>685
ありがとう。Mapleは実用に耐えられないわけですね。　やはりMojavi2かな。
0688nobodyさん2005/12/05(月) 16:21:48ID:???
>>686
ありがとう。guesswork　ってののあるわけですか・・・。　guessworkはいいですか？
0689nobodyさん2005/12/05(月) 16:22:28ID:???
M2も結構手入れしないといけないから
グチャグチャになりがち
0690nobodyさん2005/12/05(月) 16:27:15ID:???
>>688
guessworkはvalidatorが貧弱だったりするからその辺を補完して、認証とかサイト毎に
必要な機能を付ければ俺的には充分。
作成するファイルが少ないってのも俺好み。
0691nobodyさん2005/12/05(月) 16:37:22ID:???
PHP5用のguessworkは結構期待してるんだが
なかなか出ないね
0692nobodyさん2005/12/05(月) 16:43:21ID:???
mojavi2ってPHP4用ですよね？
一応ご確認あれ>>684

日本語の資料が一番まとまってそうなのは速構Web Frameworkかな？
ttp://www.pm9.com/newpm9/itbiz/php/framework/
但し有料。

次点はEthnaじゃなかろうか？
http://ethna.jp/

0693nobodyさん2005/12/05(月) 16:45:27ID:???
つーかガキじゃないんだから日本語の資料とかいらんでしょ？
英語でも読めて当然だろ、普通のＳＥなら大学ぐらい出てるんだからさ。
0694nobodyさん2005/12/05(月) 16:55:24ID:???
>>690
guesswork素敵でつた。　補完したのコッソリ下さい。　
0695nobodyさん2005/12/05(月) 16:59:09ID:???
「このフレームワークを選ぶ理由は何ですか？」
つー質問に答えなきゃいけない立場の人は大変だろうねぇ。
0696nobodyさん2005/12/05(月) 17:12:31ID:???
>>693
なにいきり立ってんの？
日本語の資料の充実度っていう軸でみてなんか不都合でも？
0697nobodyさん2005/12/05(月) 17:14:56ID:???
>>696
たとえばメンテナの数や、たとえばコーディングのしやすさ
先に見るべき場所がほかにあるでしょ。
日本語マニュアルなんて、あればいいな程度のものを最初に持ってくる神経を疑う。
0698nobodyさん2005/12/05(月) 17:22:54ID:???
>>697
まあそうだけど、フレームワークの概念自体を勉強したいっていうニーズだって
あっていいでしょ？
自分がプロのSEだからって視野が狭すぎ。
>>684が学生か社会人かもわからんだろうに。
06996982005/12/05(月) 17:25:34ID:???
あ、でも貴方の意見には全面的に賛成なんで、プロの目からみたお勧め教えて。
0700nobodyさん2005/12/05(月) 17:33:00ID:???
理解するためのコストが高いと
取り組むリスクが大きくなるから
日本語資料があるに越したことはないね。
0701nobodyさん2005/12/05(月) 17:34:02ID:???
>>699
俺が使ってるのはmojavi系。正確には2.00にパッチ当てたりして少しだけ拡張した奴。
メンテナの数が違う…が2,3,4,agaviとメンテナが分離気味なので動向を見守っているところ。
ことフレームワークなどに関しては、勝ち馬に乗るべきだと思ってる。
俺もメンテナが多いのが生まれたらそれに乗り換える。

ただ残念なのは、そうやってフレームワークが普及しても思ったよりネットでのコード共有が進まなかったこと。
みんな自分の書いたものは見せずに、他人のものばかり見たがる。俺もだがｗ
0702nobodyさん2005/12/05(月) 17:34:38ID:???
英語の出来ない部下を持つ身としては、日本語資料は必須。
0703nobodyさん2005/12/05(月) 17:38:15ID:???
言い方キツかったのは謝るよ。
すまないね。

>>702
それ結構悲惨だな…でもサンプルコードあったら理解してくれない？
PEARとでも英語しかマニュアル無いもの結構あるけど、どうするんだよ。
0704nobodyさん2005/12/05(月) 17:43:02ID:???
>>703
サンプルを用意してあげて、ケツを蹴る。
0705nobodyさん2005/12/05(月) 17:45:54ID:???
日本人雇わなきゃいいだけ
07066982005/12/05(月) 17:55:32ID:???
>>701
どうもありがとう。参考になります。

mojaviはagaviと統合してから手を出そうかと思ってました。
こちらも英語ができない部下（しかも直属じゃない）がいて、
しかも自分を含めて本職はSEじゃ無かったりします。
なんで、「わからないならソース嫁」と言いたいところですが飲み込むこともありｗ

でもメンテなの多さは魅力だな。早いうちにmojaviの資料にも当たっておこう。
0707nobodyさん2005/12/05(月) 18:05:20ID:dKNEsuCU
mojavi はゴチャゴチャしててちょっとなぁ…。
0708nobodyさん2005/12/05(月) 18:24:01ID:???
>693
うはっｗ
こういう奴ってまだいるんだｗ
0709nobodyさん2005/12/05(月) 18:28:40ID:???
愛して欲しいのさ、本当はね
0710nobodyさん2005/12/05(月) 18:33:47ID:???
お師様、温もりを…
0711nobodyさん2005/12/05(月) 20:31:13ID:???
俺もmojavi4を待ってる状態だな。
邪魔になるかなとは思いつつTylerにメールして進捗を聞いたりした
11月の中ごろにはあと2ヶ月くらいで出来るとのことだったがその後音沙汰がないのが心配だｗ
0712nobodyさん2005/12/05(月) 20:33:12ID:???
>>707
ごちゃごちゃしてるか？
mojavi2系に限ってならだけどかなりシンプルにまとまってると思うが・・・
0713nobodyさん2005/12/05(月) 20:33:25ID:???
PHP4はもう置き去りですね・・・
0714nobodyさん2005/12/05(月) 23:03:05ID:???
PHP4でもPHP5でも使えるやつってある?
0715nobodyさん2005/12/05(月) 23:06:57ID:???
4.40以降に対応してる奴は多分両方いけるでしょ。
意味無いから試してないけどね。
0716nobodyさん2005/12/06(火) 02:35:30ID:8b+BGlil
待ってたらいつまで経っても開発できないじゃん
現状ではメジャー技術を参考にしつつ自前開発するしかなさげ
だいたい大きな考え方はどのフレームワークにも共通するしね
0717nobodyさん2005/12/06(火) 09:29:17ID:???
mojavi3いいよ。
オブジェクトの使い方とか理解しやすい。
0718nobodyさん2005/12/06(火) 12:37:55ID:???
PHPについて初心者にも良く分かるように説明したサイトありませんか？
書籍の紹介でも構わないのですが。
0719nobodyさん2005/12/06(火) 12:43:24ID:???
スレ違い
0720nobodyさん2005/12/06(火) 12:45:34ID:???
>>718
ttp://www.php.net/manual/ja/

コレ
0721nobodyさん2005/12/06(火) 13:20:37ID:???
どうしてこういう事を書けるのかホントに疑問だな>>718
スレタイ読まないのはまあ百歩譲るとして他のレスちょこっと読めばわかるもんだろ普通
0722nobodyさん2005/12/06(火) 15:21:22ID:???
誤爆しただけです。すみませんでした。
0723nobodyさん2005/12/06(火) 15:27:03ID:???
あっそう
0724nobodyさん2005/12/06(火) 15:34:12ID:???
釣ってみただけです。すみませんでした。
0725nobodyさん2005/12/06(火) 15:35:58ID:???
はいはい
0726nobodyさん2005/12/06(火) 15:40:42ID:???
>>722
ttp://www.jca.apc.org/afghan-women/Special/WEDDING_BOMB.html
0727nobodyさん2005/12/06(火) 15:44:53ID:???
全て私一人の自作自演です。済みませんでした。
0728nobodyさん2005/12/06(火) 18:30:42ID:???
>>716
そうやって沢山のフレームワークが出てきているこの現状

開発手伝ってやれや
0729nobodyさん2005/12/06(火) 20:01:58ID:???
>>653
DAOとO/Rマッピングの区別ついてる？
0730nobodyさん2005/12/06(火) 20:10:08ID:???
Agaviあたりが一番無難だと思う。
薄っぺらだから、把握するソースも少なくて済むし。
正式リリースはされてないけど、svnは着々と新しいクラスも
作られてる。
至れりつくせりなフレームワークは、いまのところ完成度が
低いものばかりなので。
pradoは完成度的には高いけど、XMLファイルの設定とか
結構面倒。

個人的にはsymfonyに期待してるんだけどね。
0731nobodyさん2005/12/06(火) 22:51:06ID:???
結局Mojaviですよね
0732nobodyさん2005/12/06(火) 23:32:14ID:???
あのー、function & getAuthorizationHandler ()

この、&　の意味は何ですか？
0733nobodyさん2005/12/06(火) 23:36:36ID:???
それってフレームワーク関係ないでしょ
0734nobodyさん2005/12/06(火) 23:38:54ID:???
あのー、じゃあ何ですか？
0735nobodyさん2005/12/06(火) 23:39:38ID:???
ＰＨＰのくだらない質問スレ
0736nobodyさん2005/12/07(水) 00:25:58ID:???
>>732
山椒だよ。
0737nobodyさん2005/12/07(水) 00:26:56ID:???
ピリリと辛い
0738nobodyさん2005/12/07(水) 04:47:59ID:???
フレームワークのControllerを開始するメソッドの名前が
dispatchで、辞書で調べると
「打ち負かす」とか「急送する」とかの意味らしい。
いまいち合ってない気がするけど
何か言われがあるのかな。
executeで良くね？と思うんだが。
0739nobodyさん2005/12/07(水) 04:59:46ID:???
実際の処理(ビジネスロジック)をする(execute)のはControllerじゃなくてModelだし、
Controllerは単にリクエストを適切なActionへ発送(dispatch)するからじゃね？
0740nobodyさん2005/12/07(水) 05:49:46ID:???
あーなるほど。
0741nobodyさん2005/12/07(水) 06:05:54ID:???
dispatchはどっちかというと「割り当てる」って意味だよ。
そこらのフレームワークはStrutsの影響だと思うけど、元々はOSのスケジューラがスレッドをCPUに割り当てるって意味。
MVCフレームワークではリクエストに応じてactionだのviewだのを割り当てるってこと（>>739はその意味で当たってると思う）。
loadなんかも「積む」って意味をこえて、メモリからレジスタにデータを読み込むって意味だったものが、ファイルなどの内容をメモリに読み込むって意味に転じて、果てにはWebサーバからブラウザにデータを読み込むってことにまで使われるようになった例だし。
0742nobodyさん2005/12/07(水) 10:15:56ID:???
>>736
ありがとう。ピリリと解決。
0743nobodyさん2005/12/07(水) 17:30:53ID:???
>>730
agavi.jpの更新が完全に止まっちゃってるのが残念だね。
0744nobodyさん2005/12/07(水) 20:43:55ID:???
最近はここだよ。
翻訳してくれてる。
agaviユーザ多いかな。

http://www.geocities.jp/toyprog/
0745nobodyさん2005/12/07(水) 21:00:25ID:???
>>744
おお、こんなとこあったんだ。
サンクス。
0746nobodyさん2005/12/07(水) 22:03:43ID:???
つか、Ajaviは公式が0.9から全然動きが無いな。
0747nobodyさん2005/12/07(水) 22:05:08ID:???
svnは？
0748nobodyさん2005/12/07(水) 23:01:18ID:???
>>747
snvでは結構更新あるよ。
0749nobodyさん2005/12/07(水) 23:23:39ID:???
zend frameworkｷﾀ━━━━(ﾟ∀ﾟ)━━━━━!!!
htp://www.phparch.com/webcasts/recordings/dec0205_zend.php
0750nobodyさん2005/12/07(水) 23:50:26ID:???
>>749
英語のプレゼンだからサッパリわからんが
PHPをﾋﾟｨﾁﾋﾟｰと発音することは分かった
0751nobodyさん2005/12/07(水) 23:53:53ID:???
ははは
もれもそれ思ったよ！これからﾋﾟｨﾁﾋﾟｰって言おう！
0752nobodyさん2005/12/08(木) 06:40:50ID:???
>749
これっていつごろできるの？
0753nobodyさん2005/12/08(木) 08:49:04ID:???
けっこうagaviに似てる気がする
0754nobodyさん2005/12/08(木) 18:17:58ID:v7tgLnK2
>>741
じゃあdispatchからのforwardってなんなの？
0755nobodyさん2005/12/08(木) 18:25:17ID:???
>>754
「転送する」とか「回送する」とかの意味があるから、「処理をまわす」と
いう意味合いじゃないの？

つか、ここは英語のスレじゃないんだが。
0756nobodyさん2005/12/08(木) 22:50:03ID:???
Zendフレームワークっていつリリースか明記してある？
0757nobodyさん2005/12/08(木) 23:13:00ID:???
±1.5ヶ月でね
0758nobodyさん2005/12/09(金) 12:10:21ID:???
>>749
プレゼンが下手糞で途中で飽きた。

文章でまとまってるのないの？
0759nobodyさん2005/12/09(金) 12:21:49ID:???
流行りだからって何でもかんでもPodcastすればいいってもんでもないよね｡
テキストなら大事なとこだけ拾い読みできるのに｡
0760nobodyさん2005/12/09(金) 12:43:07ID:???
メディアを云々する前にまずGoogleを覚えようぜ
0761nobodyさん2005/12/09(金) 14:16:53ID:???
誤爆ですか？
0762nobodyさん2005/12/09(金) 17:59:40ID:kJFA21a1
Decorator使ってる時にリダイレクトしたら、
サブテンプレート作成中に処理がブチギレるよね。
ポストフィルタでリダイレクトすべきなのか。
そのあたりどうしてる？
0763nobodyさん2005/12/10(土) 14:39:54ID:???
質問です。

mojavi2でSmartyを使っています。
XOOPSのテーマを使っていてsmartyのデリミタが<{と}>です。
$lblocks = array(array('title' => 'エラー',
'content' => '<div><{$error}></div>'));
$renderer->setAttribute('xoops_lblocks',$lblocks);

すると<がサニタイズされて>に変換されて、html上表示されてしまいます。
サニタイズさせない方法ってあるでしょうか?
0764nobodyさん2005/12/10(土) 19:34:26ID:???
>>763
$smarty->left_delimiter = '<{';
$smarty->right_delimiter = '}>';

てか、、マニュアル嫁
0765nobodyさん2005/12/10(土) 23:53:59ID:???
>>764
>>763の
>XOOPSのテーマを使っていてsmartyのデリミタが<{と}>です。
とあるように、その設定はXOOPSのテーマを使うために既にしています。
そのために<と>がサニタイズされて困っているんです。

その設定をしなければ、{と}だけで問題ないのです。
テーマ側に<{$error}>と書けば問題ないのですが、setAttributeで渡そうとすると
サニタイズされてしまいます。

07667642005/12/11(日) 01:36:43ID:???
>>763
>smartyのデリミタが<{と}>です。
これ読めてなかった…　すまん、763
07677622005/12/11(日) 11:51:35ID:???
リダイレクト後にexitしてるのが問題だっただけだった。
リダイレクトっていっても
ヘッダに出力するだけで、
処理が止まるわけじゃないんだよな。
0768nobodyさん2005/12/12(月) 19:50:27ID:???
mojavi3つかってます。

modelで$this->getContext()->getRequest();するのと、
actionで$this->getContext()->getRequest();してモデルに渡すのと
どっちがmvc的に正しいですか？
0769nobodyさん2005/12/12(月) 20:44:06ID:???
>>768
モデルはコントローラやビューと結合していないのが理想なので、action で
リクエストを取得して、それに応じて model に渡すのがよいと思う。
0770nobodyさん2005/12/12(月) 20:44:31ID:???
「結合してない」って言い方は悪いな。「疎結合」に言い替える。
0771nobodyさん2005/12/12(月) 20:44:42ID:???
>>768
前者の方がmodelとactionの結合が疎になりやすい。
07727682005/12/12(月) 21:33:07ID:???
どうもありがとうございました。

さっぱりしました。
0773nobodyさん2005/12/12(月) 23:43:46ID:???
>>769
えええええええええええ？
だったらなんでmodelに
$this->getContext()->getRequest();
できる機能わざわざつけてあるのさ。

actionもMVCのmodelに相当するんじゃないの？
model内で
$this->getContext()->getRequest();とかやって、
actionでgetModelするのが普通だと思うが。

>>772よ。すっきりするのはまだ早い
0774nobodyさん2005/12/12(月) 23:50:24ID:???
moja3て、Modelがあんだ〜
class HogeModel extends Model って感じ？
0775nobodyさん2005/12/13(火) 00:06:36ID:???
>>773
> actionもMVCのmodelに相当するんじゃないの？
違うよ。controllerとmodelのアダプタ（アダプタパターンとは別の意味）。
controllerの一部をコマンドパターンとして抽出したとも見れる。
だから本当はactionはビジネスロジックを書くところじゃないんだけど、ロジックもそのまま書けてしまう手軽さは利点であり欠点でもあると思う。
requestをいじるのはcontrollerであるべきだと思うから俺はaction内でgetRequestして、相応のmodelを呼び出す派。
07767682005/12/13(火) 01:51:59ID:???
やっぱり、model内で
$this->getContext()->getRequest();
のはなんか気持ち悪い。
0777nobodyさん2005/12/13(火) 01:56:13ID:???
俺もactionでrequest派。
最初はmodelでやっていたが
そうなると、起点となるactionを見ただけでは
どんなパラメータをいじっているのかが分からず、
流れを把握しにくくなったから。
またリクエストパラメータはどちらかといえば
プレゼンテーション層に属するものなので
プレゼンテーション層であるactionで受け取るのが理にかなっている
とも思う。
バリデーションやコンバートはactionでやってるんだから
ノータッチでmodelに渡していても疎結合とは言えないのでは？
むしろactionで受け取ってmodelに渡すというレイヤパターンにした
方が疎結合といえる気がする。
0778nobodyさん2005/12/13(火) 10:18:09ID:???
model で request 処理すると，model の unit test がやり辛くなると思う
それって context と request の両方を外部に依存することになるし

action で request を処理しちゃえば model は request の「値」のみに依存することになり
より疎結合になる

# なんてことを周囲に喋ると「日本語喋れ」とか言われる罠ｗ
0779nobodyさん2005/12/13(火) 11:29:59ID:???
記述が楽＝疎結合じゃないんだよね
プロトコルを増やすわけだからむしろ記述は面倒くさくなりがち
0780nobodyさん2005/12/13(火) 14:13:53ID:???
>>773
フレームワークが許容しているのと、理想的な設計との間には
隔たりがあるってことを理解するべき。

元の質問は
> どっちがmvc的に正しいですか？
‥なので、MVC 的には action に依存しない方が理想だろうね。

>>778 のいう「unit test がやり辛い」ってのは、model がフレームワークと
密接に結合していて使い勝手が悪い証拠。結合度が高いので、再利用しずらい
(再利用する時に、間接的にフレームワークにも依存することになる)。

model と action を分離しておけば、例えば、Web アプリとは別に DB に対する
バッチ処理を PHP で書く必要がでてきた時に model を流用できる。

ただ、理想的な設計が、即座に現場で適用されるべきかというと、それは
また別問題だけどな。
0781nobodyさん2005/12/13(火) 18:51:28ID:???
>>780
いや、疎結合とかはlib側で考えるもんなんじゃないの？
＞フレームワークが許容しているのと、理想的な設計との間には
＞隔たりがあるってことを理解するべき。
許容じゃなくて、意図的に実装してるんだとおもうんだけど。
modelは明らかにactionと密接な連携を取るためのものだと思うし。

＞model と action を分離しておけば、例えば、Web アプリとは別に DB に対する
＞バッチ処理を PHP で書く必要がでてきた時に model を流用できる。
その流用はlibでつくったもののがやりやすいよね。
0782nobodyさん2005/12/13(火) 18:54:29ID:???
>>777
自分は逆にactionはどんなmodelを使ってるかの道しるべとして使ってるから
流れ把握は全然困らない。てかむしろしやすい。
0783nobodyさん2005/12/13(火) 18:59:51ID:???
てか、そもそもlibの存在忘れて疎結合とか言ってない？
0784nobodyさん2005/12/13(火) 19:08:07ID:???
libって何さ、ライブラリ？
■ このスレッドは過去ログ倉庫に格納されています