前スレ
http://pc11.2ch.net/test/read.cgi/php/1197383840/

過去スレ
【PHP】フレームワークについて語るスレ9【総合】
http://pc11.2ch.net/test/read.cgi/php/1197383840/
【PHP】フレームワークについて語るスレ8【総合】
http://pc11.2ch.net/test/read.cgi/php/1192604501/
【PHP】フレームワークについて語るスレ7【総合】
http://pc11.2ch.net/test/read.cgi/php/1181350116/
【PHP】フレームワークについて語るスレ6【総合】
http://pc11.2ch.net/test/read.cgi/php/1171896620/
[PHP]フレームワークについて語るｽﾚ5[総合]
http://pc10.2ch.net/test/read.cgi/php/1159579507/
[PHP]フレームワークについて語るｽﾚ4[総合]
http://pc8.2ch.net/test/read.cgi/php/1151706907/
[PHP]フレームワークについて語るｽﾚ３[総合]
http://pc8.2ch.net/test/read.cgi/php/1145971945/
[PHP]フレームワークについて語るｽﾚ２[総合]
http://pc8.2ch.net/test/read.cgi/php/1135847024/
【PHP】フレームワークについて語るスレ【総合】
http://pc8.2ch.net/test/read.cgi/php/1123608068/

【洋モノ】
symfony
http://www.symfony-project.com/
code igniter
http://codeigniter.com/
Zend Framework
http://framework.zend.com/manual/ja/index.html
CakePHP
http://www.cakephp.org/

【和モノ】
ちいたん
http://php.cheetan.net/
Ethna
http://ethna.jp/
guesswork
http://classic.guesswork.jp/
maple
http://kunit.jp/maple/

>>1
乙です

最近期待しているのを２つ追加

Piece Framework
http://piece-framework.com/

rhaco
http://www.rhaco.org/

でも、正直おなかいっぱいというかんじ。
3大フレームワーク(Cake, Symfony, ZF)+1(CodeIgniter)で十分という気も

3大フレームワークのサブセット版がほしい。

ごてごてとしたフレームワークをごそっと入れるんじゃなく、
ファイル一枚か少数で完結したフレームワーク・・・

だが、命令などに互換性があり、必要になった時点で、
フルセットのフレームワークに容易に入れ替え可能。

どこで聞くべきか迷ったんですけど、ここにします。

今SimpleTestを使ってテストしています。
SimpleTestにはWebTestCaseといってあたかもブラウザで
アクセスしたかのように、ウェブページに対してhttpプロトコルで
接続・・・その結果をテストということができるのですが、
このメール版はないでしょうか？

つまり、自分のPHPアプリからメール送信・・・そしたら（仮想の）テスト用メールサーバーにメールがたまり、
テストコードから、メールサーバーに来たメールを見てアサーションや、そのメールに書かれているリンクを
クリックなどしてテストを続行という、一連の処理にメールが入る場合のテストの自動化をしたいのです。

なにか良いライブラリ、良い手は無いでしょうか？

あー、そういう手作業テストって面倒だよな
なんか良い手あるなら俺も知りたい

SimpleMailを見つけました。

SimpleMailhttp://www.curioussymbols.com/simplemail/

ちなみに、Windowsで使うときの注意点です。

SimpleMailがSMTPサーバーとしてFakeMailを使用するので別途インストールする必要があります。
perl版は必要なライブラリが入れづらいようなのでpython版を使いました。
python版はWindows版があるのでインストーラーで簡単に入れられます。
あらかじめpython自体も入れておく必要があります。

http://www.lastcraft.com/fakemail.php ここに情報が少し書いてあります。
fakemailerを起動するときは、インストールしたフォルダで、
> fakemail.py --host=localhost --port=10025 --path=.
でいいのですが、そのままではエラーになりました。

エラーメッセージを見ると、「signal.SIGHUP」が定義されていないそうです。
どうせテストだし、あまり重要なものではなさそうなので、削除しました。

> for sig in (signal.SIGINT, signal.SIGTERM, signal.SIGHUP):
↑fakemail.pyの中の「, signal.SIGHUP」を消す。


SimpleMailにはstart()メソッドでfakemailを実行する機能があるのですが、
Linux/Unix用のパスで、perl版のコードの上、fakemail.pyをバックグラウンドで
実行しようとすると、forkなんたらのエラーが発生するのであきらめます。
start()、stop()メソッドを呼ばなくても使えます。
その代わり、テスト開始前にfakemailerを起動しておきましょう。

PHPはモジュールたっぷり入ってるxamppに
perlはperl.exeしか入ってなくて子飼弾脂肪ｗｗｗ

PHPってフレームワーク地獄ですよねｗ

どういう意味？
フレームワークありすぎって意味？

ただ、PHPは良くも悪くも言語仕様が緩いので、
デファクト・スタンダードになったフレームワークは標準で取り込んで、
言語仕様上の優遇を受けるんじゃないか、と思ってる
そうなったらこのフレームワーク地獄も終わるんじゃないの
政治的にZend Frameworkになるのかなと思ってるけど

フレームワーク自体にはそれぞれコンセプトがあるんだから、
一つに落ち着くことはないと思うけどね。
ちょうど.comみたいに、たくさん出てきて、いろいろ淘汰されて、
最終的に数個残るみたいになるんじゃないかなぁ。
ま、資金力や人気もあるからZend Frameworkは残りそうだけど

PHPのフレームワークは、誰でも作れるところが、
利点でもあり、欠点でもあるんだろうね。
ASP.NETのように誰も参入できないようにしてしまうと
選択肢が無い分すっきりとするが、その設計手法から
洩れてしまうと、言語など根本的な部分から変更せざるを
得なくなってしまう。

http://slashdot.jp/security/article.pl?sid=08/02/11/0012230
linuxカーネルに穴があってPHPもちろん脂肪ｗｗｗ

その理屈だとRuby他も脂肪じゃんｗ

Piece以外に継続を利用したWebフローエンジンを持っているPHPフレームワークってある？
JavaだとSpring Web Flowに近いと思うけど、LightweightだとほとんどがFront Controllerだから、
なかなか野心的でないかと思っている。

>>19
WebFlowって継続なの？知らんかった。
つうか、言語で継続サポートしてないのによくやるな。

Pieceはやってる人を応援したくなる
ただ、Piece_ORMのinsertのテーブルデフォルト値の扱いが未だに納得がいかん。
もう少し説明をしてくれればな・・・

WebFlowに近いというか、Pieceは元々がWebFlowとJBoss Seamを参考にしてるからな。当然ある程度は似る。

やっぱそうなんだ。
それぞれのモジュールが個別に使えるようになっているみたいだし、
そのうち既存のアプリにPiece_Flowを組み込んでみたいと思ってるんだよね。
（今はORMとRightはドキュメントがあるけど、Flowの方はちょっと…なので）

今から始めるとするとどのフレームワークがおすすめかな？
少しだけcakePHPをかじってみたけど、まだ日本語のドキュメントが十分とは言い難いし。

>>24
これから始めるなら、php4対応は気にしなくてもいいんじゃない？
俺はまだまだ業務で４を引きずるから、cakeとethnaだけど。

>>24
CodeIgniter
間違っても Symfony はすすめない

>>26
理由をどうぞ

CIは確かにいいけどこれ使うならCakeの方が多少デブになるけどベターかな。
多分組み方にコダワルやつはZendを使って苦労したがるのだろう

>>24
どう考えてもsymfony。作りこみが他の比じゃない。
そもそも全体が太るのを避けるならFWなんて使うべきじゃない。Rasmasのやつ使え。

>>28
Zendが本命とかよく本とかには書かれてますが、どういうところが駄目なんですか？

設計として疎結合を重視しすぎていて、
そのせいで痒い所に手が届かない部分が、
フル装備のsymfonyやcakeに比べると物足りなく思える。

ZFは言ってみれば、
軽量な骨組みに綺麗なクラスライブラリを置いてある感じ。

というのがZFについて人から聞いた話。

symfonyやcakeで届く痒いところってどんなところ？

bakeで焼いてる(笑)ヤツらは、便利と思ってるのかな。

bakeで焼いたら焦げました('A`)

>>34
baka

mb_send_mailまわりってダメダメだな・・・
mb_encode_mimeheaderはmb_internal_encodingが必要って見たけど
PHP4の稼働してるバージョンじゃそれでもだめだったし
自分でヘッダ組み立ててmailで送るしかないじゃん・・・('A`)

mb_send_mail()で使えているけど。
ただ、引数指定にはいろいろノウハウがあったような…
単純にテキストメール送るだけなら、楽なことは楽。

つーか、ここはフレームワークスレじゃん。
フレームワークにメールモジュールないの？

あるけどしょっちゅう化ける
特に洋モノは。
南蛮人に極東のマイナー言語のサポートなんか期待できないのは
当然っちゃ当然だが

まあいい加減ISO-2022-JP（だったっけ？）に変換して送る様なローカル慣習も無くなってくれてもいいんだが。
UTF-8通らないサーバとかメールクライアントとかはもう無視する方向で行きたいな。
（どのみちそっちの方向にしか進まないんだから）

70文字で区切るとかいう仕様も今の時代意味あんの？
そのせいでmb_encode_mimeheaderも腐ってるし
いつの時代の仕様なんだっての

ってか実際的に考えて、70文字区切りなんていらないんじゃないか？
mail関数のサブジェクトの説明には「改行を含んではいけません。」って書いてるし、
実際サブジェクトを適当な文字数で区切ってbase64エンコードした場合と
まったく区切らずにbase64エンコードした場合の結果が
gmail,shuriken,docomo(foma)で同じだったし
恐らく今のクライアントだったらほとんど問題ないだろう。
mb_encode_mimeheader的な区切り処理は
むしろ何かと害があるんじゃないか。

そういう風に考えていくと
mb_send_mailの存在意義が分からないな。
出来ないことを出来ると見せかけるという意味で
むしろ悪影響の方が大きい
前もってmb_internal_encodingを設定しろとか
バッドノウハウが広まってること自体がおかしいだろ
常識で考えて

MIMEの仕様に文句があるならRFCを修正してくれ。

mb_send_mail関数があるおかげで、PHPerにメール(というかMIME)関連の知識が付かない、という弊害もある。
・・・仕様が半端だしあちこちで不具合が出るから結果的にはある程度知らなきゃいけないんだがｗ

本当に半端な関数で、こんなもの実装するくらいならPEARででもまともなMailクラスを育てればいいのに。

俺もmb_send_mailの存在意義がわからん。
mail関数じゃダメなのか？ というか何が問題でmb_send_mailが出来たんだ？

調べろと？ そうですなｗ


とりあえず、subjectはISO-2022-JPにしたあとbase64エンコードしている。
本文はISO-2022-JPにしている。

これでmail関数使っているが、なにか罠があるのか？

>>38
> つーか、ここはフレームワークスレじゃん。
> フレームワークにメールモジュールないの？

じゃあ、フレームワークに絡める。
CakePHP 1.2にはメールモジュールEmailComponentがあるのだが、
このモジュール。mb_send_mailではなく、mail関数を使っている。
当然日本語とか考慮されていない。

charsetというプロパティはあるにはあるのだが、これだけじゃうまくいかない。
なので、EmailComponentを継承して__encode、__renderTemplateメソッドを
オーバーライドしてエンコードおよび、半角カナなどを変換しているよ。

確かにメール関連知識付くの遅かったな
mb_send_mailの挙動が変だから
ずっとメールに対して奇々怪々なイメージがあった
やってみればたいして難しくないんだが。
mailを直接触る方が健康的だな

PHPのCLIって起動やたら遅くね？
CLIが速いスクリプト言語って何？

bash