[PHP]フレームワークについて語るｽﾚ２[総合]
■ このスレッドは過去ログ倉庫に格納されています
0001nobodyさん
2005/12/29(木) 18:03:44ID:PQZNoJbD■Phrame
http://phrame.sourceforge.net/
■Mojavi Project
http://www.mojavi.org/
■Agavi
http://agavi.org/
■[ 日本発 ] Maple Project
http://kunit.jp/maple/
■[ 日本発 ] Ethna -PHPウェブアプリケーションフレームワーク-
http://ethna.jp/ethna-tutorial-startup-practice1.html
■[ 日本発 ] guesswork
http://www.guesswork.jp/
■Biscuit
http://bennolan.com/biscuit/
■PHP on TRAX
http://phpontrax.com/
■Web Application Component Toolkit (WACT)
http://www.phpwact.org/
■symfony
http://www.symfony-project.com/
■XOAD
http://wiki.xoad.org/index.php?title=Wiki_Home
■[ 日本発 ] pokox
http://www.glamenv-septzen.net/pukiwiki/index.php?pokox
■[ 日本発 ] 速構Web Framework
http://www.pm9.com/newpm9/itbiz/php/framework/
■CakePHP
http://cakephp.org/
0596nobodyさん
2006/03/26(日) 23:06:30ID:DeU9y+sORewriteRule !\.(js|ico|gif|jpg|png|css)$ index.php
として、
URL/コントロール名/アクション名/
でアクセスさせるからだと思います。（違ってたらごめんなさい）
ここに理屈が書かれています。
http://revilog.com/program/2006/03/006937.html
ここでは REQUEST_URI を PATH_INFO に差し替えて…なんてことをしているようです。
http://tdiary.ishinao.net/20060322.html#p01
フレームワークを使う人なら mod_rewrite に慣れているはずだから、
わざわざフレームワーク側でしなくても…って思ったんです。
0597nobodyさん
2006/03/27(月) 00:27:52ID:???フレームワーク全体は mod_rewrite には依存していない、ってことじゃね？
現状は Preview 版の Router が依存してるけど、適宜書き直せば良いと。
>>596
オープンソースのように不特定多数が使うケースを考えると、apache の設定が
弄れない可能性がある。むしろ、フレームワーク側で用意してない方が糞。
0598nobodyさん
2006/03/27(月) 09:44:30ID:???Router書き直すっていうかRouter Interfaceつかってrouteメソッド書けばいいんじゃない？
Mojavi系っぽいURLでindex.phpにアクセスしたいならこんな感じ
class MojaviRouter implements Zend_Controller_Router_Interface {
public function route(Zend_Controller_Dispatcher_Interface $dispatcher) {
$module = @ $_REQUEST['module'] or $module = 'Default';
// サニタイズしてね
$action = @ $_REQUEST['action'] or $action = 'Index'
// サニタイズしてね
$token = new Zend_Controller_Dispatcher_Token($module, $action, $_REQUEST);
// サニタイズしてね
if (! $dispatcher->isDispatchable($token)
throw new Zend_Controller_Router_Exception('～');
else
return $token;
}
あとはindex.phpの中のどっかで
$controller->setRouter(new MojaviRouter);
とかやればいいんでないかな。
しかしクラス名が長くて眩暈がするな。大したことやってないのに・・・
0601598
2006/03/27(月) 12:04:29ID:???デフォルトのdispatcher使えば598のままで問題ないと思われ。
0602nobodyさん
2006/03/27(月) 13:37:40ID:???っていう書き方はじめて見た。
変数に値がない時の書き方が冗長になるなぁと
ずっと思ってたんだよな。
0603nobodyさん
2006/03/27(月) 14:19:01ID:???書くならむしろこっちでは。
$module = isset($_REQUEST['module']) ? $_REQUEST['module'] : 'Default';
0604nobodyさん
2006/03/27(月) 14:25:12ID:???isset()で確認した変数をもう1回書くのが面倒なんだよねそれ
連想配列なら関数書けるんだけど、普通の変数は空だと引数に渡せないしなぁ
0605nobodyさん
2006/03/27(月) 14:26:31ID:???まあそれ以前にPHPのorがboolしか返さないのがそもそもの難点なんだが・・・
0607nobodyさん
2006/03/27(月) 14:44:49ID:???0608nobodyさん
2006/03/28(火) 02:50:05ID:???別々のActionからDBの同じデータにアクセスしてることあるじゃん。
いくつか方法はありそうだけど
どうやって対処してる？
0609nobodyさん
2006/03/28(火) 07:23:03ID:???0610nobodyさん
2006/03/28(火) 09:45:44ID:???ただアクセスするだけならそのままでもいいし、データの書き込みに関してお互いの整合性が必要なら別口にDAO的なModel作ったらどう？
0611nobodyさん
2006/03/28(火) 14:28:18ID:???agaviのSingletonModelとか、自前でSingletonするとか。
Actionに直接DBへのアクセス書くのはなんか抵抗があるな。
0612608
2006/03/28(火) 14:59:45ID:???同じデータを取るのに複数回クエリ発行するのが気になったんだ。
そのへんはあまり気にしないが正解かな。
0613nobodyさん
2006/03/28(火) 15:56:52ID:???DAO 側でデータをキャッシュしておいて，
同じデータと判断できるような何かがあったらキャッシュを返すとか……
結局は DB アクセスとメモリキャッシュのどちらかでリソースを食うので
状況次第ではどちらも富豪的な発想ってことに．
oracle なんかだと RDBMS 側でもキャッシュしてるから
同じデータを触りに行くクエリとかだと連打しても大して負荷なかったりする場合も．
0615nobodyさん
2006/03/28(火) 18:35:20ID:???0616nobodyさん
2006/03/28(火) 18:52:28ID:???MySQL 4.1.1 以降では、 InnoDB テーブルの使用時、クエリキャッシュはトランザクション内でも機能します
0617nobodyさん
2006/03/28(火) 23:38:47ID:???おまいらはdaoとかつくりますか？
0618nobodyさん
2006/03/28(火) 23:54:31ID:???0620nobodyさん
2006/03/29(水) 15:08:06ID:???http://www.m-takagi.org/docs/php/zend/
0622nobodyさん
2006/03/29(水) 18:14:05ID:???m-takagi.org って php-doc で名前よく見る高木氏じゃないか
心底から感謝を捧げたい！
0623nobodyさん
2006/03/30(木) 00:07:49ID:???やっぱリファレンスが充実しなきゃ良いものも
広まらないからな。良いものかどうかは知らんが。
0624nobodyさん
2006/03/30(木) 12:48:08ID:???彼は結構いい仕事してるなー。他にも色々翻訳しているね。
で、ZF使ってる香具師いるの?
俺時間なくてまだ見ることもしてない...
0625nobodyさん
2006/03/30(木) 18:08:29ID:???0626nobodyさん
2006/03/30(木) 21:12:30ID:???みたいって人はいるでしょ。というか使ってみたいんだけど、なかなか時間が
まわりのツールが集まってくると面白いことになるんだろうけど
ドキュメントは結構早く出てきてる感じがする
サイトはまだかなー
0627nobodyさん
2006/03/31(金) 02:44:42ID:???ishinao さんがZend Frameworkをいろいろ触って所感を書いていますね。
0628nobodyさん
2006/03/31(金) 12:23:04ID:???http://ke-tai.org/index.php?KEMP
0630nobodyさん
2006/04/02(日) 10:11:19ID:???「携帯用」って時点で話にならん。
基本的にＰＣ用サイトも携帯用サイトも一つのフレームワークに収められるようにするのが基本。
0631nobodyさん
2006/04/02(日) 10:25:57ID:???日本の携帯に適したものが当然のごとく実装されてんのか？
そいつは知らんかったな。
0632nobodyさん
2006/04/02(日) 12:12:51ID:???0633nobodyさん
2006/04/02(日) 14:28:56ID:???0634nobodyさん
2006/04/02(日) 15:20:07ID:???ケータイ用に KEMP でいいと思うよ。
0635nobodyさん
2006/04/02(日) 15:27:24ID:???KEMP って Smarty 使っているんじゃないの
0637nobodyさん
2006/04/02(日) 16:15:24ID:???・PC用に特化したフレームワーク
・携帯用に特化したフレームワーク
どれもあっていいと思うけどね。
そりゃどちらにも対応しててどちらに対しても最高の拡張性を備えてるなら文句ないけど、ないものねだりしても始まらない。
0638nobodyさん
2006/04/02(日) 16:23:11ID:???最高の拡張性なんて全く必要ないよ。既存のフレームワークでＰＣ用も携帯用も作れる。
どっちもWEBアプリケーションで、作成に大した差もないのになぜ特化する必要があるの？
0640nobodyさん
2006/04/02(日) 16:51:19ID:???があるから、それに特化したフレームワークがあっても面白いかと思う。
PC版と携帯版があるサイトとかだと、別々のフレームワークが必要になったりして
不便かもしれないけど。
0641637
2006/04/02(日) 16:52:30ID:???俺自身は携帯向け自体作る気ないから別にほしいとは思わないしお前もいらないんだろうけど、欲しい人もいるんじゃないの？
特に携帯の機種依存な処理とかどれくらい面倒くさいのか知らないが、ぱっと見た感じフレームワーク的なものあったら便利になるんだろうとは思った。
別にお前が要らないと考えること自体に対して異論はないよ。
人それぞれだから。
0642nobodyさん
2006/04/02(日) 17:32:21ID:???0644nobodyさん
2006/04/02(日) 17:47:07ID:???>>642の言うようにFilterとかちょこっといじれば
携帯用のフレームワークになるだろ。
0645nobodyさん
2006/04/02(日) 17:50:42ID:???適材適所だし。誰も咎めてはいないよ。
0646nobodyさん
2006/04/02(日) 18:02:06ID:???なんの話というか…、こうやって専用にしか使えないフレームワーク作るより、
汎用のフレームワークに対する、いわばプラグインって形で提供すれば、
使ってくれる人も多くなるし、うまく行けば流行るかもしれん。
と言う意味で、スマートじゃないかな、と思った。
0647nobodyさん
2006/04/02(日) 18:05:56ID:???もし今後ZFが標準になったりとかすれば、プラグイン製作って考えも当たるかもね。
現時点では何とも言えないけど。
0648nobodyさん
2006/04/02(日) 18:13:38ID:???いや、別にmojavi は例として挙げただけだから、あまり気にしないでね。
少なくとも、携帯専用フレームワークよりは、mojavi でも何でも良いんで、
そこそこ知名度のあるフレームワークに寄生した方が、使う側にしても敷居が低くて良いと思うよ。
いや、携帯用のデファクトスタンダードに育て上げるんだ、
って意気込みでやるってんなら、それはそれで良いのかもしれんけど。
ま、個人的感想だと思って頂戴。
0649nobodyさん
2006/04/02(日) 18:23:16ID:???どっちみちどうでもいい結論しか出なさそう。
0650nobodyさん
2006/04/02(日) 18:31:10ID:???それ専用のフレームワークは十分需要があるよ。
絵文字ライブラリだけでも売り物になるんだから。
0651nobodyさん
2006/04/02(日) 18:32:44ID:???0652nobodyさん
2006/04/02(日) 18:54:38ID:???http://headlines.yahoo.co.jp/hl?a=20060401-00000091-myc-sci
0653nobodyさん
2006/04/02(日) 19:00:03ID:???だからその処理をFilterに入れるんだろうよ。
だいたい携帯でもPCでも見れるようなサイトを作る場合
わざわざフレームワークを分けるわけ？
その技術を世に公開するならSmartyやMojaviなどの
プラグインにした方がマシだと思う。
0654nobodyさん
2006/04/02(日) 19:01:50ID:???まあ、公式サイトを作ったことあるやつならすぐわかる話。
0655nobodyさん
2006/04/02(日) 19:09:22ID:???多感な年頃ですね。
どうせMojavi専用＋携帯専用プラグインなんて出てきたらまた文句言いたくなっちゃうんでしょ？
0656nobodyさん
2006/04/02(日) 19:14:23ID:???おれもこないだまでは
「MVCきちんと分離しとけばVだけ変更して携帯サイトできあがり～」とか思ってたんだが
仕事で公式やったら>>650の通りで、>>630なんてのは空論に過ぎねーと思い知った
ていうかもう携帯の仕事はやりたくなくなったｗ
0658nobodyさん
2006/04/02(日) 19:52:01ID:???0659nobodyさん
2006/04/02(日) 20:01:02ID:???653のやり方に反対しているわけじゃないんだ
同じフレームワーク（以下FW）上で656に書いたみたいな大きな違いまで吸収できるならそれでいい
ただ実際、特化FWの代わりができるほどに「こなれた」汎用FWは見たことがない
654も言うとおり、実際「まったく違った」サイトにせざるを得んのだから、
それなら携帯の方は分けて考えて特化FWで作っても問題になりにくいだろうな、ってこと
もちろんFWの学習曲線を2回登らないといけないとかのデメリットも忘れてるわけじゃない
でも携帯サイトの不自然な制約はそれすら凌駕するくらいだと思うってこと
（これは個人的意見だしどこまで対応しなきゃならないかっていう要件にもよると思う）
0660nobodyさん
2006/04/02(日) 20:19:15ID:???mojavi使える？他のフレームワークでも構わない。
filterとrendererで対応できないのって、どの辺？
別に煽ってるとかじゃないよ、携帯コンテンツとか作ったこと無いから、知的好奇心。
0661nobodyさん
2006/04/02(日) 20:32:30ID:???だから、ウェブの資料とかあんまりない。
CP剥奪とかなったらシャレにならない。
まあ、携帯の開発って、フレームワークを適用できる部分が多いと思うよ。
PCのサイトなんかよりずっと。
0662nobodyさん
2006/04/03(月) 02:52:00ID:???どーせ大した情報も持ってないんだろ？
携帯サイトごときでフレームワーク変えるようなアホに
何も聞くことねーよ雑魚。
0664nobodyさん
2006/04/03(月) 03:50:19ID:???春休みって奴か
0666nobodyさん
2006/04/03(月) 09:22:59ID:???基づいて、携帯専用のフレームワークは不要と判断
しているのかを知りたい。
0667nobodyさん
2006/04/03(月) 09:33:50ID:???結論言えばfilter/pluginやrenderer/decoratorでもやればできる。
さらに言えばフレームワーク使わなくてもやればできる。
さらに言えばPHP使わなくても（ｒｙ
作ろうとしているサイトの規模に応じて適切なものを検討してね。
あとはご勝手に、と
0668nobodyさん
2006/04/03(月) 10:21:16ID:???携帯独自のコンテンツを提供するサイトだったら
専用フレームワークが必要十分だろうけど、
両方提供する場合は専用だと嬉しくない
ただまぁ、現状の一般のフレームワークでは
携帯の邪魔くさい部分に対応しきれないのは
間違いないので、携帯向けフィルタ集みたいな
ものもあったらいいね
0669nobodyさん
2006/04/03(月) 10:27:00ID:???その辺の処理とかもフレームワーク側で便利にこなしてくれるといいんじゃない？
いらないいらないって叩くやつからは何も生まれてこないので、どっちかというと
作って公開してくれる人を大切にしたい。
0670nobodyさん
2006/04/03(月) 11:12:37ID:???わかるー！おれも「viewを変えるだけでいいだろ」と思ってたけど、技術的な制約が全然違うから、作り方も別にならざるを得なくて、すごい苦労した。
なんかね、パソコン向けと携帯向けって、使っているのがHTML（とそのサブセット）というぐらいしか共通点ってないんじゃないかと思った。
GET/POSTとかないし、クッキーないし、URLの文字数に厳しい制限あるし、CSSやJavaScriptないし、Sessionはれなかったりするし、認証方式まるで違うし、そのくせ情報少ないし、これでどうやって作れっての？と思った。
もうフルブラウザしかサポートしませんといいたかったよ。
>>659
>でも携帯サイトの不自然な制約はそれすら凌駕するくらいだと思うってこと
はげどー！誰が考えたんだよ、あんな仕様・・・特にi-mode。
>>653
FilterやPluginで対応できる・・・そう思ってたときが自分にもありました。
最初から携帯も視野にいれて設計されたフレームワークならともかく、そうじゃないフレームワークではFilterごときでは対応できなくて、Controllerにも手をいれないと難しい。
「MojaviにFilterいれればクラサバアプリが作れる」というのと同じようなもん。
0672nobodyさん
2006/04/03(月) 11:54:53ID:???実際のブラウザシェアをキャリアが公開してくれると
嬉しいんだよな。例えばこれこれのスペックの端末が
これくらいのペースで減ってるからこの時点で非対応
に、とか判断できる。
この辺は新規開発じゃまったく情報ないから
古い仕様に合わせるってことになるわけだけど、
そうすると制約だらけで何もできないに等しく
なっちゃうんだよな。
実際には 3G じゃなくても PDC の後期の機械は
結構ハイスペックなんで、いろんなことできる。
これは仕様外の端末独自のものだけじゃなくて
仕様上も結構制約緩くなってたりする。
どうでもいいけどキャリアは端末情報をすべて XML で
提供してくれんかな。PDF じゃ全然使えねーよ。
0673659
2006/04/03(月) 13:08:34ID:???>>660
FilterやらRendererやらで対応は，原理的にはそりゃ何だってできるだろうけど．
あるUAには複数画面に分割したHTMLフォームで入力は932+携帯独自コード，
別のUAにはFlash読ませてエラーもFlash生成して返しますよ，なんてのは
実質的に単なる別プログラムでしょう．
あるいは認証とかで，古い端末はセッションIDをURLにくっつけてください，
でもブックマークしてもらうページにはつけちゃダメだからhiddenで渡してください，
あぁでもCookie使える新しい端末は逆にCookie以外は禁止してください，とか．
個別に考えれば「こうすればいいじゃん」とか浮かぶだろうけど，
つまりは対応できないってのではなく，汎用FWの機能内で無理して対応するより
特化FWで支援機能バリバリで対応した方が
コードの見通しもメンテ性も良いだろうなって話だわ．
まぁ「お前の設計が糞」とか言われりゃそれまでなのだが．
>>670 同志がいてくれて嬉しいｗ
0674nobodyさん
2006/04/03(月) 13:24:57ID:???そそ、可能か不可能かといわれれば、可能。
でも、事実上不可能。
単なるフォーム入力画面でも、PCなら一画面ですむのが携帯だとHTML最大サイズが小さいから複数画面にしなきゃいけなかったりとか、
その最大サイズも端末ごとに違うから端末ごとに画面数が違うとか、
そもそもキャリアごと・端末ごとに使えるタグが違うとか。
画面数が変わるとVだけでなくCもかわるし、入力データのバリデーションもやり方が変わってくる。別の画面で入力されたデータとあわせてチェックしなきゃいけないとか。
おれの場合、共通化できたのはMだけだった。
ちょっとスレ違いになってすまんかった。でもこのスレはフレームワーク設計者もみてると思うから、携帯対応も考慮してくれるとうれしい。
0675nobodyさん
2006/04/03(月) 15:54:53ID:???としか思えん。
0676nobodyさん
2006/04/03(月) 16:10:03ID:???理由や具体例を述べよ。
それだけじゃ主張したいことが全然伝わらない。
独り言だったらチラシの裏に書くように。
0677nobodyさん
2006/04/03(月) 18:59:37ID:???>つまりは対応できないってのではなく，汎用FWの機能内で無理して対応するより
>特化FWで支援機能バリバリで対応した方が
>コードの見通しもメンテ性も良いだろうなって話だわ．
なんで汎用だと「無理して対応」になるの？なんで特化だと「バリバリ対応」になるの？
君の上げている理由じゃぁ普通のWEBフレームワークに普通に突っ込めるじゃん。
むしろPCと携帯でVIEWだけ分けてロジック共通にしたい時なんて、特化フレームワーク
なんて使ってたら偉い手間。
0678nobodyさん
2006/04/03(月) 19:10:32ID:???なんでループさせるの？
特化してるのも汎用の拡張もやりたいように
やればいいじゃん。
作ることそのものを否定する必要はあるまい。
専用のものから汎用のものへインポート
できるかもしれないんだし。成果が誰かを
幸せにすりゃそんでいいんだよ。もちろん
まず最初に自己満足を満たすのも大事。
0679nobodyさん
2006/04/03(月) 20:04:37ID:???> 君の上げている理由じゃぁ普通のWEBフレームワークに普通に突っ込めるじゃん。
↓
> 個別に考えれば「こうすればいいじゃん」とか浮かぶだろうけど，
> なんで汎用だと「無理して対応」になるの？なんで特化だと「バリバリ対応」になるの？
なんで？って……ならない理由がわからないんだが．
すごく簡単な喩え話でいうとさ，mb_send_mail()が使える環境と使えない環境で，
日本語のたいていのMUAで正常に読めるように日本語メールを送るのはどっちが楽よ？って話．
0680nobodyさん
2006/04/03(月) 20:21:36ID:???当然、対応させるためにフィルタやらViewやらなんやらを作ったし、
キャリアごとに異なる認証機構もフレームワーク内で収まるようにした。
具体的な方法はいえないが。
もちろん、専用フレームワークをきちっとした形で作り上げてくれるのなら大変ありがたいよ。
0681nobodyさん
2006/04/03(月) 22:07:03ID:???Filterに突っ込めって行ってんだよ！
そんなこともで出来ねーならプログラマなんか辞めちまえよ！
0682nobodyさん
2006/04/03(月) 22:50:27ID:???そんなことも理解できないなら人間なんか辞めちまえよ！
0683nobodyさん
2006/04/03(月) 22:55:34ID:???色んな意見参考にして自分に取り入れていったらええやん
もともとそういうスレだし
0684nobodyさん
2006/04/03(月) 23:01:38ID:???お前はPHPもApacheも使わずに、とっても便利で何でもできちゃうアセンブラでHTTPデーモン書いて携帯サイト作ってやっとけ。
そんなこともできねえならプログラミングやめろ。
0685nobodyさん
2006/04/03(月) 23:33:57ID:???0686nobodyさん
2006/04/03(月) 23:37:37ID:???0687nobodyさん
2006/04/03(月) 23:46:23ID:???2chで叩いてる奴より形にして公開してるやつの方が100倍えらい。
0688nobodyさん
2006/04/04(火) 01:59:52ID:???OS作るの？ご苦労さん。
俺だったらウェブサイト作るためだけにOS作るなどというばかげたことはやらずに、普通に既存のプラットフォームを使うけど。
0689nobodyさん
2006/04/04(火) 02:19:53ID:???0690nobodyさん
2006/04/04(火) 02:31:31ID:???スレ違いだからもう来なくていいよ。
0692nobodyさん
2006/04/04(火) 05:05:36ID:???0693nobodyさん
2006/04/04(火) 06:17:17ID:???他人の自由を制約する必要は一切なし。
0694nobodyさん
2006/04/04(火) 08:38:05ID:???はいはい、携帯用フレームワークは不必要だね、無意味だね、馬鹿だね、ウンコだね、チン毛だね。
誰かにそう同意してもらえるまで駄々こねるだけの甘えん坊さんは(ﾟ⊿ﾟ)ｲﾗﾈ
0695nobodyさん
2006/04/04(火) 10:49:28ID:???0696nobodyさん
2006/04/04(火) 10:54:11ID:???■ このスレッドは過去ログ倉庫に格納されています