- 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参照汁
- 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だったら常に参照渡しにしたほうが楽な希ガス。
- 326 名前：nobodyさん mailto:sage [2005/10/03(月) 12:48:32 ID:???]
- 配列はよりけりだけど
オブジェクトは一律参照渡しでほとんど問題なくない？
- 327 名前：nobodyさん mailto:sage [2005/10/03(月) 14:42:31 ID:???]
- 問題ないというか、PHP5や他の言語を考えると
必要な場面でのみ値渡しにしたほうがいいと思う
- 328 名前：nobodyさん mailto:sage [2005/10/03(月) 15:56:03 ID:???]
- 要はオブジェクトは特に理由がないなら参照渡しにしとけって話でFA。
- 329 名前：nobodyさん mailto:sage [2005/10/03(月) 16:02:55 ID:???]
- ふりーえーじぇんと宣言？
- 330 名前：nobodyさん mailto:sage [2005/10/03(月) 19:53:20 ID:???]
- っていうか参照渡しとか値渡しとか意味わからん漏れはダメ人間。
- 331 名前：nobodyさん mailto:sage [2005/10/04(火) 03:25:49 ID:???]
- どうしてわかってくれないのっ！
- 332 名前：nobodyさん mailto:sage [2005/10/04(火) 16:01:01 ID:???]
- ティン！
- 333 名前：nobodyさん mailto:sage [2005/10/04(火) 18:09:25 ID:???]
- フレームワークとふかわがものすごいﾐｽﾏｯﾁだな
- 334 名前：nobodyさん mailto:sage [2005/10/04(火) 20:38:36 ID:???]
- _____
/二二ヽ
||・ω・|| ＜ﾃｨﾝ!!!!!
|σ |σ
> >
山崎邦正ならマッチするのに
- 335 名前：nobodyさん [2005/10/05(水) 17:39:44 ID:gDrff9QN]
- requestとかcontrollerをAction中の複数のメソッドで使う時、
initializeでgetしておいてprivateなプロパティーとして持っておくのはｱﾘ？
- 336 名前：nobodyさん mailto:sage [2005/10/05(水) 17:49:44 ID:???]
- 最近主流の複数画面で構成されてるサイトって
フレームワーク（的なもの）がなければ作れないよなぁ。
ベタ書きで作ってるサイトなんてあるんだろうか？
- 337 名前：nobodyさん mailto:sage [2005/10/05(水) 22:36:32 ID:???]
- >>336
複数画面で構成されてるサイトって ?
- 338 名前：nobodyさん mailto:sage [2005/10/05(水) 22:44:00 ID:???]
- >>337
ヘッダ-メイン-右サブ-左サブくらいにエリアが分かれてて
それぞれのエリアのコンテンツ構成が動的に変化するようなの。
ポータルとかニュースサイトのほとんどがこれ系だよね。
- 339 名前：nobodyさん mailto:sage [2005/10/06(木) 01:04:30 ID:???]
- 別にフレームワークが必須だとは思わないけど。
フレームワークが一番効果を発揮するのは、何画面にも渡るアンケートフォームだろうね。
アンケートデータの持ち回りと、ヴァリデーションに応じて遷移先の画面が変わるから。
- 340 名前：nobodyさん mailto:sage [2005/10/06(木) 01:17:22 ID:???]
- >>338
別にベタ書きでも書けるけど、フレームワーク使ったほうが早いときもあるってだけの話だ罠。
>>335
Mojavi系の話だよね？毎回contextから取得するのがMojavi標準的くさいからﾅｼ。
ローカル変数にrequestとか入れるくらいまではｱﾘだと思うが。
例えばヘタに$this->request = "うんこ";とかやると他のメソッドに響くし。
その点では、PHPにfinalがあればMojaviの仕様も大分違ってたのではないかと想像。
少なくとも$this->context->getRequest()か$this->context->requestくらいにはなるんじゃないかな。
$this->requestまでなるかどうかは、何とも言えないがｗ
- 341 名前：nobodyさん mailto:sage [2005/10/06(木) 06:29:57 ID:???]
- >標準的くさいからﾅｼ。
久しぶりにその方言聞いた。なつかしいなー。
- 342 名前：nobodyさん mailto:sage [2005/10/06(木) 13:06:02 ID:???]
- www.glamenv-septzen.net/pukiwiki/index.php?pokox
和製フレームワーク追加
- 343 名前：nobodyさん mailto:sage [2005/10/06(木) 13:07:29 ID:???]
- 仕事でMojavi使ってた人は今どうしてるんだろう
Agaviに流れたのか他に行ったのか
- 344 名前：nobodyさん mailto: [2005/10/06(木) 15:47:14 ID:???]
- >>339
データの持ち回りなんてセッションで十分だと思うのだが・・・・
いまだに俺はフレームワークの利点が分からない。
- 345 名前：nobodyさん mailto:sage [2005/10/06(木) 19:53:34 ID:???]
- >>342
名前似てるけど、俺は和製フレームワークはpokが一押し。
>>343
多分仕事で使ってた人は、少なからず手を加えてるので、
わざわざAgaviには流れてないんじゃないのかな？
>>344
自分一人で作ってたりする人はそうかもね。
「俺的フレームワーク」ってのを知らんうちに使ってたり。
まさか毎回1からなんて事はないでしょ？
- 346 名前：nobodyさん mailto:sage [2005/10/06(木) 20:18:00 ID:???]
- >>345
その pok ってのポインタきぼん
- 347 名前：nobodyさん mailto:sage [2005/10/06(木) 20:24:05 ID:???]
- www.geocities.jp/toyprog/wikimojavi/index.html
ここのおかげでやっとDecoratorを理解した…
自分がﾊﾒﾊﾒされるテンプレートをあらかじめ指定しておけるんだね。
こりゃ便利だ。
- 348 名前：345 mailto:sage [2005/10/06(木) 21:31:38 ID:???]
- >>346
ttp://cgi39.plala.or.jp/klove/
S2Container.PHP5の人ね。
Seasarに関わってる人達を個人的にスゲー注目してる。
パフォーマンス的には？？って感じは否めないけど、
PHPでも結構やれるなって事がわかって良かった。
スゲー勉強になった。
S2Daoとかｽﾝｹﾞｰ期待してる。
俺の中では糞盛り上がってるんだけど、
MLとかｽﾝｹﾞｰ寂しいし、ひょっとしてめちゃくちゃ
ﾏｲﾅｰなのかなぁ・・・と心配になってきてる・・・。
- 349 名前：nobodyさん mailto:sage [2005/10/07(金) 01:02:37 ID:???]
- >>348
ありがとー
Seasar.PHP の ML は読んでるから名前は見ていた人だわ
S2Dao とかおれも期待しているんだけど
正直，きちんと追ってない人には活動が何してんのか見えなさすぎて，
それがマイナーっぽい原因になってるんだろうなーと思う
- 350 名前：nobodyさん mailto:sage [2005/10/07(金) 04:58:48 ID:???]
- フレームワークのウリとしてフォームの取り回しの簡便化がよく喧伝されるけど
俺はそこはあんまり重要じゃないなぁ。
そんなにしょっちゅう書く部分じゃないし、もともと単純な処理がほとんどだし。
デザインパターンに基づいた保守性の高さや、
見通しの良さの方が嬉しい。
簡単なことが簡単になっても、あんまり嬉しくないけど
複雑なものを単純にすることが出来たら、かなり嬉しい。
- 351 名前：nobodyさん mailto:sage [2005/10/07(金) 05:03:27 ID:???]
- privateやprotectedもないPHPでデザパタ重視はどうかと思う
- 352 名前：nobodyさん mailto:sage [2005/10/07(金) 05:20:40 ID:???]
- >>351
釣りなのか、PHP5 を知らないのか、どっち？
- 353 名前：351 mailto:sage [2005/10/07(金) 05:23:35 ID:???]
- >352
釣りだ
350はデザパタがメインのレスじゃないだろ
まぁこれでも読んで考えてくれ
ttp://www.enpitu.ne.jp/usr10/bin/day?id=104241&pg=20050818
このスレとは全然関係ないんだけどさ
- 354 名前：nobodyさん mailto:sage [2005/10/07(金) 08:06:14 ID:???]
- フレームワークを使っているから、オブジェクト指向かというと、そういうわけでもないよな。
メンテナンス性を上げようと思えば、在り物のフレームワークを使うより、
自分なりにそのWEBアプリにあった仕組みを考えた方がメンテナンス性が上がる場合もあるだろうし、
メンテ担当の技量を考えて、クラスをいっさい使わないようにした方がメンテしやすい場合もあるだろう。
- 355 名前：nobodyさん mailto:sage [2005/10/07(金) 13:12:01 ID:???]
- forwardすることを前提としたactionでも、
url直接入力して直呼びすることもできるよね。
何か対策してる？
- 356 名前：nobodyさん mailto:sage [2005/10/07(金) 13:37:39 ID:???]
- してる
- 357 名前：nobodyさん mailto:sage [2005/10/07(金) 13:56:25 ID:???]
- いくつか方法は考えられそうだけど
どんな？
- 358 名前：nobodyさん mailto:sage [2005/10/07(金) 14:04:28 ID:???]
- requestにsetAttributeして飛び先actionで確認
- 359 名前：nobodyさん mailto:sage [2005/10/07(金) 14:12:14 ID:???]
- なるほど thanks
- 360 名前：nobodyさん mailto:sage [2005/10/07(金) 16:36:25 ID:???]
- 結局そういうことにrequestのattributeだとかuserのparameterを使うと、（コントローラの呼び出し等を除いて）実行されるコードの最初から最後までアクセス可能ってことになる。
そうなるとグローバル変数と変わらないんだよな。
もっと各状態の遷移ごとにアクセス制限のかかったデータの受け渡しができればいいんだけど、うまくいかないもんだ。
- 361 名前：nobodyさん mailto:sage [2005/10/07(金) 17:27:56 ID:???]
- セッション管理ではだめなのか？
- 362 名前：nobodyさん mailto:sage [2005/10/07(金) 17:40:15 ID:???]
- >>354
おいおい、そんな事させるからPHP使いはウンコのまんまなんだよ。
クラスを一切使ってねぇ〜システムなんざ見る気しねぇ〜よ。
つーかクラス使わずどうWebアプリ作ったらいいんだろ？すら思う。
- 363 名前：nobodyさん mailto:sage [2005/10/07(金) 17:53:18 ID:???]
- 351の言ってる保守性は、アプリ自体の保守性
354が言ってるのはアプリ上に乗っかってくるデータやコマンドのメンテナンス性
で、フォーカスしてる層が違う感じがするな
- 364 名前：nobodyさん mailto:sage [2005/10/07(金) 18:27:14 ID:???]
- PHP4にはデストラクタないし、例外も投げれないから、クラスをネストさせたり、複雑に組み合わせたりはやりづらいよね。
スコープを明示できないからクラスを使わざるをえないけど、それじゃあクラスをクラスらしく使ったプログラミングとは言えない。
もっとも、WEBアプリというジャンル自体、オブジェクト指向のメリットがあまりないジャンルだと思うね。
どっちみちリクエストのたびにオブジェクト作り直しになるわけで、ユーザからの入力データもリクエストごとにフラットにしかこないわけで。使いどころがない。
- 365 名前：nobodyさん mailto:sage [2005/10/07(金) 18:32:28 ID:???]
- > もっとも、WEBアプリというジャンル自体、オブジェクト指向のメリットがあまりないジャンルだと思うね。
ふーん。
- 366 名前：362 mailto:sage [2005/10/07(金) 18:41:02 ID:???]
- >>364
それは俺に対する回答だと思っていい？
クラス使ってる＝オブジェクト指向っていうのが間違ってると思うよ。
実際自分を顧みるに、オブジェクト指向を意識してクラスを使い始めたが、
オブジェクト指向にはならず、単に構造化になっただけだった。
だがそれだけでもかなり見通しが良くなったと思ったよ。
単にメンテ性だけを考えてもクラスを使用しているアプリと、
クラスを全く使用してないアプリとどっちがメンテし易いか？
って考えるとどっちだと思う？
俺はベタ書きで書かれたものを渡されて「メンテしろ」って言われたら、
とりあえず「作り直させてください」って言うな。
あと、クラスのネストってどういう事？
- 367 名前：nobodyさん mailto:sage [2005/10/07(金) 23:01:26 ID:???]
- DecoratorTemplate使う時で、
HTMLのヘッダ部での
外部JavaScriptファイルの読み込みとか
JavaScriptの初期値設定が必要な場合、どうしてる？
自分が「部分」になれるDecoratorは便利だけど
入れこみたい情報がソース中でバラける時、面倒くさいなぁ。
- 368 名前：nobodyさん mailto:sage [2005/10/07(金) 23:14:07 ID:???]
- 別にクラスを使えばオブジェクト指向になるとは思わないよ。
それとフレームワークとオブジェクト指向とは関連性があるわけじゃないとも思う。
まあ、フレームワークにもよるけど。
これは言うまでもないと思うけど、オブジェクト指向を生かせるのはGUIのデスクトップアプリケーションとか。
WEBアプリの場合、リクエストの度にオブジェクトを作り直さないといけない。
特にPHPは永続化をどうするか？とか、言語機能が少ないとか、速度が落ちるとかっていう欠点もある。
まあ、これからはAjaxとかFlashとかで、高度なGUIを持ったWEBアプリが要求されるだろうから、そうなるとオブジェクト指向のメリットも出てくるかな。
けど、HTML自体があまりオブジェクト指向なプレゼン言語とは思えないんだよなあ。
- 369 名前：nobodyさん mailto:sage [2005/10/07(金) 23:26:18 ID:???]
- >>368
フレームワークとオブジェクト指向とは関連性があるわけじゃないとも思う
って関連ありまくりじゃん。
OOのエッセンスが分かちがたい程たっぷり入ってると思うよ。
OOを使わずともライブラリ集は作れるだろうが、
フレームワークは作りにくいだろう。
- 370 名前：nobodyさん mailto:sage [2005/10/08(土) 00:07:12 ID:???]
- >>368
今時「PHPでOOPすると性能が落ちる」とか言ってるのは時代錯誤もいいとこ。
- 371 名前：367 mailto:sage [2005/10/08(土) 01:39:24 ID:???]
- ViewHelperで解決した(゜д゜)
- 372 名前：nobodyさん mailto:sage [2005/10/08(土) 01:55:47 ID:???]
- デストラクタもないのにオブジェクト指向ってありえるんだろうか？
- 373 名前：nobodyさん mailto:sage [2005/10/08(土) 02:24:56 ID:???]
- なんだこの掃き溜めは
- 374 名前：nobodyさん mailto:sage [2005/10/08(土) 02:26:59 ID:???]
- デストラクタがないとオブジェクト指向なプログラミングができない、
という思考回路が判らない。言語仕様に捉われすぎてる悪寒。
|
 |
