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

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

■ このスレッドは過去ログ倉庫に格納されています
0001nobodyさん2008/08/24(日) 21:43:37ID:???
前スレ
http://pc11.2ch.net/test/read.cgi/php/1202521438/
0587nobodyさん2008/11/15(土) 09:41:57ID:???
>>585
インプット・アウトプットの対象の幅広さは、ウェブアプリなんかとは比べものにならんように思う。
ウェブアプリの場合は、一部APIサービス的なものを除けば、ほぼ「画面」相手でいいわけだが。

>>586
その理由でテンプレートエンジンを使いたがらない人も未だに多いがな。同じじゃね？
0588nobodyさん2008/11/15(土) 13:00:48ID:???
フレームワークに比べて、テンプレエンジンは開発効率大してよくならないからな。
つーかＦＷに組み込まれてるし
0589nobodyさん2008/11/15(土) 13:15:36ID:???
何かをしない理由にパフォーマンスを上げている場合、大概ちゃんと調べるのとか新しい
やり方を検討するのが面倒くさいことだけの事が多いと思う。

論理削除ってあるじゃん。レコードに削除フラグを立ててデータは残すって言う。
あのフラグのチェックををいちいち手で (del_flag IS NULL OR del_flag = 0) とか書いている
会社があった。
なぜ NOT NULL制約を付けないのかと聞いたら、「重くなる」って答えが返ってきた。
全力でこけた。いろいろ間違ってる。
0590nobodyさん2008/11/15(土) 14:11:03ID:???
12のphp最適化テクニックとか、一時期ブログに出回ったけど、
そのテクニックが使われるタイミングを考えると、誤差でしかないとか、
よくあったよね。
むしろコードが読みにくくなったり、書きにくくなったりと、
その時間のほうがもったいないとか。
0591nobodyさん2008/11/15(土) 14:39:00ID:???
大手でphp使ってサービスやってるといえばYahooなんだけど
たとえば、↓
http://www.sooey.com/journal/2007/05/26/648/
symponyだって。
でもサービスによって違いはあって
http://wakatsukichinatsu.yahoo.co.jp/index.php?itemid=128
↑これなんてPHP?
0592nobodyさん2008/11/15(土) 14:39:25ID:???
論理削除自体間抜け
0593nobodyさん2008/11/15(土) 14:54:51ID:???
論理削除自体が間抜け？
方法がフラグってとこが間抜けってなら少しはわかる気もするが。
0594nobodyさん2008/11/15(土) 14:55:03ID:???
論理削除は必要だろ。
0595nobodyさん2008/11/15(土) 15:09:50ID:???
スレチだけど論理削除ってどういう指定にすればやりやすいですかね。
active enum('Y','N')か、status = 0 なら削除とか？
0596nobodyさん2008/11/15(土) 15:11:46ID:???
>>593
わかんね。
フラグじゃなくてカウンタにするってこと？
0597nobodyさん2008/11/15(土) 16:06:02ID:???
大規模向けではなく一番スケールアウトしやすいFWは?
0598nobodyさん2008/11/15(土) 16:34:55ID:???
スケールアウト考えたらモデルは自分で書かないときつくね？
0599nobodyさん2008/11/15(土) 16:57:52ID:???
ちｒｙ
0600nobodyさん2008/11/15(土) 17:24:52ID:???
>>595
deleted（datetime）がnullかどうか
0601nobodyさん2008/11/15(土) 17:52:20ID:???
int型にして、0だと削除扱いにするのが妥当だろうな。PHPやPerlなら、ブーリアン評価でfalseが帰ってくるし。
0602nobodyさん2008/11/15(土) 17:55:22ID:???
勝手に値はいるのはtimestampだけだっけ？
0603nobodyさん2008/11/15(土) 18:02:15ID:???
>>602
NOT NULL にしておいて default を設定すれば入るだろ
0604nobodyさん2008/11/15(土) 18:49:10ID:???
mysqlはデフォルト値に関数が使えない
0605nobodyさん2008/11/15(土) 18:51:03ID:???
>>600
deletedってどういうこと？
0606nobodyさん2008/11/15(土) 19:09:25ID:???
フィールド名じゃないの？
0607nobodyさん2008/11/15(土) 19:12:51ID:???
ああそういうことか、関数かと思ったｗ
0608nobodyさん2008/11/15(土) 19:13:24ID:???
nullだとインデックスが使われないから論理値のほうが良くない？
0609nobodyさん2008/11/15(土) 19:27:12ID:???
nullかどうかで求めるのは本来正しく無いだろうね
削除された、と言う状態がシステム上にありうるならそれはnullで表現すべきじゃない
0610nobodyさん2008/11/15(土) 19:54:48ID:???
というか、３値論理っての？ NULL を理解していないとか必要性を感じないとかの場合は、
全フィールド NOT NULL で作ってしまえと言いたい。
その方が何かとトラブルが少ないし、コーディングも楽だ。
テキストフィールド？ 空文字でも入れとけ。 数値？ 0が初期値だ。それで都合がわるけりゃ、
-999999999 が初期値だ、文句あるか、ってな感じで。
0611nobodyさん2008/11/15(土) 22:00:11ID:???
>>608
MySQLならenum型でnullを使う分にはNULLでインデックスされると思うよ
他のDBでは知らない
0612nobodyさん2008/11/15(土) 23:07:45ID:???
>>607
そう、カラム名。
id, created(datetime), updated(datetime), deleted(datime)を標準的に使用。

あるいは、statusとしてa)Activei)/Inactive、h)Hidden, b)Obsoleted D)deleted
とか詳しい状態が必要な時に使うとか。
06135952008/11/15(土) 23:12:27ID:???
いろいろやり方あるんすね。すごい勉強になった。
皆さん有り難うございます。
0614nobodyさん2008/11/15(土) 23:21:42ID:???
論理だろうがなんだろうが、削除っていうからカッチリ噛み合わないと思うんだよね
実際問題何も消してないわけなんだし
だから、そういうのは無効化とか不活性化とか利用不可とか、そういう「状態」で呼ぶべきで
削除って言うならならきっちりかっちりまるっと全部消してしまえ！

と思うんだよなー
スレ趣旨と全然関係ないんだけどなー
0615nobodyさん2008/11/15(土) 23:47:46ID:???
>>612
頭文字使うぐらいなら、enum型かSET型じゃね？
まぁ、DB実装によって違うかもしれんけど。
0616nobodyさん2008/11/16(日) 02:05:02ID:???
論理削除はDELETEより早い速度が求められる場合(index更新のコストが馬鹿にならない)とか
警察照会とか、CS対応で必要とかやっぱり要るシーンが多くて>>614みたいに消してしまえーが使えない場合も少なくないよ

>>615
そうだね。
0617nobodyさん2008/11/16(日) 02:08:47ID:???
論理削除っていう呼び方はおかしいね
ソフトウェアなんだから全て論理だし
無効化、凍結、と言う呼び方が正しい
0618nobodyさん2008/11/16(日) 02:19:28ID:???
そうかな？英文でもphysical delete、logical deleteって言葉よく使われるよ。
http://publib.boulder.ibm.com/infocenter/wbihelp/v6rxmx/index.jsp?topic=/com.ibm.wbia_developer.doc/doc/connector_dev_java/java61.htm
0619nobodyさん2008/11/16(日) 03:13:45ID:???
処理速度の場合もあるだろうけど、後から参照しないといけない場面がよくあるからな。安易に削除するわけにはいかないことが多い。
0620nobodyさん2008/11/16(日) 06:39:55ID:???
だからそれを削除って呼ぶなよﾊﾞｰﾔ!!って言いたいんだろう
0621nobodyさん2008/11/16(日) 06:56:48ID:???
論理削除を削除と呼ぶか、単なるステータスかというのは
呼び方の慣習の問題。

言葉遊びをやってもしょうがないんで、ここでは便宜的に、論理削除とは、
物理的には削除せずにサービス上削除されたようにふるまわせること
でいいかな？
0622nobodyさん2008/11/16(日) 09:11:01ID:???
>>600 >>612
滔々と語ってるが、>>612の前者のdeleted （削除日時） はまあともかく、
後者の方では、レコードにユニーク制約のカラムがあった時に不便だろ。

削除フラグ（というかカウンタなど）とセットでユニーク制約にしてしまうって
のは、あんまり流行って無いのか？
0623nobodyさん2008/11/16(日) 12:27:21ID:???
partial index 使っちゃう。
0624nobodyさん2008/11/16(日) 12:33:30ID:???
>>622
詳しく
0625nobodyさん2008/11/16(日) 13:00:36ID:???
>>624
例えばユーザアカウントをユニークにしたいとかで、一意制約をユーザ名カラムに付けるとする。
んで、そのユーザが退会した後、そのデータを残してたら、そのユーザ名がずっと使えない。
それを避けるために、削除データだけ一意制約から考慮外にしたい場合、削除フラグと２カラム連結で
ユニークにしてしまう。
んでレコードを削除する時に、同一なユーザ名を持つデータの削除フラグを、一斉に +1 UPDATEしてしまう。
削除フラグが 1以上なら( というか、0でなければ ) 削除データという扱い。
こんなやり方。マイナーなのかな？と思った。

書いてて思ったが、これ一意制約のカラムが二つ以上あった場合、そのままでは使えないなｗ
もちょっと応用を利かさないと無理か。
整数部分と少数部分で分けるとか桁で分けるとかビットで分けるとかｗｗｗ

＃ DBの一意制約を使わずアプリで常にチェックするなら別にこんなことしなくていいんだけど。
0626nobodyさん2008/11/16(日) 13:06:04ID:???
こんな風にやりたいのなら、削除フラグ自体もユニークにして削除日時を
マイクロ秒まで入れておけばいいのではと後から思ったのは内緒だ。
0627nobodyさん2008/11/16(日) 13:24:25ID:???
って書いて、削除フラグをユニークにしたらそもそも「未削除」の状態はどうするんだと気づいた午後。
飲みながらレスするもんじゃないな。
退散します。
0628nobodyさん2008/11/16(日) 13:45:33ID:???
>>625
その例だと使えなくするケースが多いのでむしろ好都合。たいていサポートチームが要望してくる。
0629nobodyさん2008/11/16(日) 13:51:02ID:???
酔っ払いめ！ｗｗ

さて、ユーザーアカウントを例にすると、ちょっと怖すぎるんだが、
CMSなんかのアイテム管理だと、リビジョン管理に同一itemidで
複数のインスタンス、しかも最新以外は非アクティブっていう状態を
表現するという用途があったりする。
その場合、削除フラグを使わずに、使用目的に合わせたタグを振る。
外部キー側もタグやリビジョン番号を考慮した設計にしないといかんわけだけどね。
0630nobodyさん2008/11/16(日) 14:12:40ID:???
>>629
そういうのの設計はちょっと知りたいなーと思っていたんだけど、
MediaWikiのソースでも読めばいいのかな？
0631nobodyさん2008/11/16(日) 14:19:46ID:???
PACの解説記事でDrupalが良い実装とか見たことあるので同じCMSならこっちは?
リビジョンと直接は関係ないけどソースはしっかりしてるかも
0632nobodyさん2008/11/16(日) 14:26:24ID:???
設計見るのになぜソースを読む
0633nobodyさん2008/11/16(日) 14:43:16ID:???
オープンソースソフトウェアの設計書なんて公開されてる？
0634nobodyさん2008/11/16(日) 15:05:16ID:???
おそれすになったな・・・

>>587
> インプット・アウトプットの対象の幅広さは、ウェブアプリなんかとは比べものにならんように思う。
> ウェブアプリの場合は、一部APIサービス的なものを除けば、ほぼ「画面」相手でいいわけだが。

それをいったら、ウェブじゃないアプリだって、ほぼ画面（ディスプレイ）相手だろ？
なんか比較している対象がずれてるよ。

画面じゃなくてOffice系の大規模アプリだって、結局は画面にGUI表示してファイルに書き込むだけなんだし。
ゲームだってそう。ハードウェアデバイスを扱うものもあるだろうけど、それをウェブアプリでやってはだめってことはない。
ブラウザでコーヒー沸かす装置とかｗ
0635nobodyさん2008/11/16(日) 15:05:49ID:???
>>633
設計書 = ソースコード
0636nobodyさん2008/11/16(日) 15:33:36ID:???
>>634
元のレスが、アプリとは書いてなくて、「ウェブじゃないシステム」って書いてあるからじゃね？
対象がずれてるというか、「Office系の大規模アプリ」とかゲームとかが念頭にあるのは
わかっててわざと書いてるんだろｗ
車のエンジン制御とか、通信インフラ系とかはシステムじゃねーの？って。

>>585
> それにウェブじゃないシステムが何をしているかというと、
> 結局、ファイルにデータ読み書きして、画面に点を表示しているだけともいえる。

いえねーよｗ
これがむしろ、言いたいことと表現がずれてるんじゃね？
0637nobodyさん2008/11/16(日) 17:24:18ID:+7h73lOI
タグの実装を考えています
スペース区切りでtextカラムに入れて、全文検索するのがシンプルでいいかと思ったのですが、
他にいい方法があったら教えてください
0638nobodyさん2008/11/16(日) 17:26:45ID:???
>スペース区切りでtextカラムに入れて、全文検索
これはひどい
0639nobodyさん2008/11/16(日) 17:28:47ID:+7h73lOI
そうですか？ググっていたら同じようなことしてる人もいますが。
http://blog.nomadscafe.jp/archives/000643.html
他にいい方法があれば教えてください。
0640nobodyさん2008/11/16(日) 17:43:46ID:???
タグ単位で編集とかしないならいいんじゃない？
0641nobodyさん2008/11/16(日) 17:44:48ID:???
普通に考えれば
タグテーブル作って
アイテムテーブルとの間に多対多のリレーションテーブル持てばいいだけだよね
いかにもリレーショナルに解決出来るケースだと思うけど
0642nobodyさん2008/11/16(日) 17:45:10ID:???
>>639
それ、フレームワーク関係ないし、それ以前にPHPの問題でもないよ。
DBの問題だからDB関連スレで質問しろよ。
まぁ、正規化すら理解してないみたいだからまずは本でも買って勉強することをオススメするけどね
0643nobodyさん2008/11/16(日) 17:52:11ID:???
だね
基礎知識が足りてなさそう
0644nobodyさん2008/11/16(日) 17:59:55ID:???
なるほど、おっしゃる通りですね。
ありがとうございました。
0645nobodyさん2008/11/16(日) 18:01:45ID:???
俺はついこの間タグテーブルと、タグと記事のリレーションテーブルで作った。
けど、割とありきたりの機能になったのに、
情報が少なくてベストプラクティスな設計が出来たか不安なんだよね。
タグはパターンとしてどっかに情報がまとまっててもいいと思うんだが。
0646nobodyさん2008/11/16(日) 18:10:11ID:???
だから典型的なリレーショナルな設計でいいでしょ
それ以外に特別な事なんて無いんだから
0647nobodyさん2008/11/16(日) 18:20:02ID:???
うん基本的すぎてまとめる気が起きない
不安ってのはRDBの理解が不十分なのかと。
0648nobodyさん2008/11/16(日) 18:26:03ID:???
フレームワークの話題が無いのか
0649nobodyさん2008/11/16(日) 19:46:05ID:???
symfony使ってるんだけどRoRと比べてモデル周りが貧弱で泣いた
0650nobodyさん2008/11/16(日) 20:18:46ID:???
PHPの場合、標準的なDBドライバがないからな。どれも中途半端。
0651nobodyさん2008/11/16(日) 20:20:48ID:???
具体的にちんぽにーとrorでどうちがうの？
0652nobodyさん2008/11/16(日) 20:23:39ID:???
横レスだけど。
RoRのアプリケーションはRubyで書けるけどSymfonyではRubyで書けない。
これは大きい。それに比べりゃモデル周りなんて大差ないんじゃね？
0653nobodyさん2008/11/16(日) 20:25:04ID:???
んなの当たり前じゃん
フレームワークの比較より言語の比較だし
0654nobodyさん2008/11/16(日) 21:54:05ID:???
フレームワークを初めてつかったけど「便利な関数群」ってだけじゃん。
0655nobodyさん2008/11/16(日) 21:56:08ID:???
違うよ
全然違うよ
0656nobodyさん2008/11/16(日) 21:59:31ID:???
>>654
なんという前世紀のライブラリ
まあそれはそれで便利だけど
0657nobodyさん2008/11/16(日) 22:07:04ID:tiBOVYsk
PHPを初めてつかったけど「便利な関数群」ってだけじゃん。
0658nobodyさん2008/11/16(日) 22:19:55ID:???
それはそうだよ
0659nobodyさん2008/11/16(日) 22:21:24ID:???
>>657
それは半分真実
ただWEBフレームワークであるという視点も抜けている
例えば$_POSTや$_COOKIEは関数か？
HTTPヘッダを自動で吐く機能は関数？
PHPはただ単にWEB入出力とDBアクセスに便利な関数群装備のインタプリタとして
使うのもいいし、不十分な（でも拡張も可能な）フレームワークとしても利用出来る

と思ってるけどどうだろ
0660nobodyさん2008/11/16(日) 23:54:00ID:???
フレームワークはパターンとルール
0661nobodyさん2008/11/17(月) 00:16:53ID:???
それは多分定義のレイヤが違う
0662nobodyさん2008/11/17(月) 00:19:03ID:???
>>661
どういうこと？
ｋｗｓｋ
0663nobodyさん2008/11/17(月) 03:03:18ID:???
「便利な関数群」つうだけならそれはライブラリ。
ワークはあるがフレームがない。
0664nobodyさん2008/11/17(月) 22:29:41ID:???
>>657
webプログラミングがまだ試行錯誤だった時代に、
その「便利な関数群」ってだけのことがとても
大きかったから、シェアが取れた。

便利な関数群自体がほとんど無かったからね。

Javaと同じ。
0665nobodyさん2008/11/18(火) 03:06:59ID:???
$_SESSIONとか$_REQUESTとか勝手にcontent-typeが出力されるとか、PHPの言語機能自体にウェブアプリ用の機能が組み込まれてるからな。
0666nobodyさん2008/11/18(火) 03:12:50ID:???
１回Ｃ言語でＷＥＢアプリ作ってみると良く分かる

あとＰＨＰが流行ったのはＷＥＢアプリ（のインタフェース部分）はこの程度の機能で十分って事もあるだろうね
敷居を低くしてしまって素人プログラマーが流入してきても
ＷＥＢ分野には受け皿がある
0667nobodyさん2008/11/18(火) 06:22:10ID:???
webアプリなんて一方通行だからな
アホでも書けるんだよ
0668nobodyさん2008/11/18(火) 10:11:51ID:???
>>664
関数や機能がたくさんあるだけが問題ならPerlが圧勝したはず。
やっぱりmod_phpの管理のお手軽さとPHPの言語自体の簡便さ。
0669nobodyさん2008/11/18(火) 10:27:37ID:???
>>668
ソースインストールはお世辞にもお手軽とは言えなかったがな
未だにrpm以外でのPHP管理を敬遠するサーバ屋もあるくらい
0670nobodyさん2008/11/18(火) 12:15:39ID:???
http://ja.wikipedia.org/wiki/Web%E3%82%A2%E3%83%97%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%83%95%E3%83%AC%E3%83%BC%E3%83%A0%E3%83%AF%E3%83%BC%E3%82%AF

ここで言うプル型アーキテクチャのフレームワークってPHPでなんかある？
0671nobodyさん2008/11/18(火) 12:41:48ID:???
Smarty
0672nobodyさん2008/11/18(火) 13:20:30ID:???
なんか新しいフレームワークがでてきたらしい

Yii Web Programming Frameworkは期待できそう。
http://cakephp.seesaa.net/article/109833179.html
0673nobodyさん2008/11/18(火) 14:00:58ID:???
Perlは組み込み関数は少ない。
CPANモジュールをインストールしなければ行けないから、リモートログインとシェルが使えない共用のレンタルサーバなんかだと使い物にならない。
多少なりともUNIXの知識も要求されるし。
その点、PHPの場合、mbstringが有効になってれば、Pearが使えなくてもどうにでもなる。
0674nobodyさん2008/11/18(火) 14:55:14ID:???
>>673
それはかなり昔の話だけどね。
PHPで global $HTTP_GET_VARS とかしなきゃいけない、ってのに近いくらいｗ

特に、Perl5.8からはEncode標準添付だし、MovableTypeの流行以降は、
そこらのレンタルサーバでも一通りのモジュールは入るようになってる。
DBI・DBMやらも普通に使えるのが大半。
その頃にはみんなレンタルサーバでのPerl CGIから離れてしまってたがなｗ
0675nobodyさん2008/11/18(火) 14:59:41ID:???
>>670
よくわからんが、「イベントドリブン」なんてのを謳ってるようなのは
そうなのかな？
0676nobodyさん2008/11/18(火) 18:21:34ID:???
>>672
ActiveRecordじゃないですか。モデルに強くてうれしす。
制作者はPRADOのひとかぁ
0677nobodyさん2008/11/18(火) 19:49:11ID:???
>>675
EDPとはまた違うような。

ビューがコントローラーにデータをリクエストするようなやつ。
0678nobodyさん2008/11/18(火) 20:42:37ID:???
PHPは5-6年前の時点でPHP4が普及してたから。
そもそも国際版のPHP3ってレンタルサーバで提供されることはほとんどなかった。あっても、すぐに4に移行したから。
Perlの場合、5.8.10になっても標準モジュールだけでは既存のウェブフレームワークは動かない。
モジュールをインストールしても、CatalystみたいなのはCGI環境ではまともな速度が出ないし。
共用レンタルサーバへの設置の難しさがあって、MTがWordPressに抜かれて、XOOPSとかPukiWikiとかフリーのウェブアプリってPHPの一人勝ちになった。
Perlが使われるのは未だにKENTのCGIとか。
そういう反省があって、今のPerl界でMENTAとかの設置の簡単な、標準外のモジュールに依存しないウェブフレームワークが注目されてる。
けど、結局のところ、ベストプラクティスに載ってるようなモダンなPerlを書こうと思えば、適時CPANモジュールをインストールするしかないわけで、これはPerlっていう言語の性格上どうにもならないな。
0679nobodyさん2008/11/18(火) 20:49:25ID:???
>>677
ビューがコントローラーにデータをリクエストする。を読むと、
すごいイベント駆動ぽい気がするんだけど・・・

プル型というのは、いったい何のための仕組みなんだ？
コントローラーがビューにデータを渡すのではなく、
あえてビューがコントローラーにデータをリクエストする理由が知りたい。
0680nobodyさん2008/11/18(火) 21:21:31ID:???
ページデザインだけでサイトが完結しうるところがメリットかな。
オンデマンドに必要なデータを拾いに行くので、自由度が高くなる。
ページに組み込むパーツがいかように変化してもコントローラーを
いじらなくて済むところとか。

まぁ、プッシュ型でも、ビューからコントローラーを呼べるはず。
それが特殊な時だけ利用するのか、常にそうするのかの違いだな。

CMSでイベント駆動だとプル型っぽい動きさせてるのが結構ある。
フレームワークはなんだかんだボトムアップだからプッシュ型が普通で、
それに慣れすぎてる感はある。
0681nobodyさん2008/11/18(火) 22:15:34ID:???
あとプル型はコントローラーが複数あるのも特徴とか英文Wikipediaにかいてなかったっけ

なんかフレームワークスレっぽくなってきた
0682nobodyさん2008/11/18(火) 22:23:17ID:???
英文関係無かった須磨祖
0683nobodyさん2008/11/18(火) 22:54:01ID:???
あんまり詳しくないから変なこと言ってるかもしんないけど
PHPだと複数ファイルに分けてあるものをIncludeしてくしかないわけで、
MVCはコード書く上での概念みたいな感じでPushもPullも厳密には関係ないよね？
JavaServletのforwardみたいに処理投げ渡したりとかできないよね
0684nobodyさん2008/11/18(火) 23:09:54ID:???
フレームワークが何を自動化するかって事だろ
0685nobodyさん2008/11/18(火) 23:29:54ID:???
http://ja.wikipedia.org/wiki/Apache_Tapestry

Tapestryではこんな説明だった。

> Apache Tapestryは、アクションをベースとした仕組みのApache Strutsとは競合する。
> TapestryはStrutsとは違い、コンポーネントベースであり、コード量が少なくて済む点が特徴である。
> またStrutsのようにJSPカスタムタグライブラリを覚えなおす必要がなく、
> 必ずServlet/JSPを作成しなければならないということはなく、
> Javaやネットワークの知識がないウェブデザイナーでも簡単にJava製ウェブアプリケーションを作成できるという利点がある。

アクションをベースとしたStrutsとは違うというあたりが、
なんとなくプル型が分かるような分からないような。
使ってみないと、はっきりしないかなー
0686nobodyさん2008/11/19(水) 00:16:11ID:???
http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks
これ見たらpush/pullが一目瞭然。
■ このスレッドは過去ログ倉庫に格納されています