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

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

[前50を表示]
150:nobodyさん
05/09/06 15:19:20
>>1
>>9
>>83
>>144

で大体既出な気がするけど、他にあんのかな？

151:nobodyさん
05/09/06 16:42:00
海外含めればキリが無いだろう。
まあ、開発終了しているのも結構ありそうだが。
URLﾘﾝｸ(ethna.jp)

152:nobodyさん
05/09/07 00:04:38
あのう，結局，Maple の 3.0.1 って……？
作者さんリリースをまとめる気なくしちゃってるのかなぁ……

153:nobodyさん
05/09/07 00:27:18
>>152
今週中だとさ
作者さんの日記参照

154:nobodyさん
05/09/07 00:51:57
>>148
お前はこのスレ来なくていくね？　て感じ？

155:nobodyさん
05/09/07 01:12:11
>>153
おぉっとほんとだ情報ｻﾝｸｽ

CVS版でも大差ないんだろうけど
どうも性分でスナップショット版みたいのを使う気になれなかったのだけど
これでやっと使ってみることができるわー

156:148
05/09/07 04:13:36 VkYxruOZ
>>154
ごめん、このｽﾚ毎日何回もチェックしてるよ
フレームワーク乱立の理由について思ったこといっただけ

157:nobodyさん
05/09/07 04:25:23
>>156
チェックしてるだけじゃなくて、いつも同じこと書き込んでるよね。

158:148
05/09/07 04:27:27
書き込んだのは148がはじめてだけど？

159:nobodyさん
05/09/07 04:29:52
>>158
お前はこのスレ来なくていくね？　て感じ？

160:148
05/09/07 04:31:10
わかりました　さようなら

161:nobodyさん
05/09/07 04:35:56
>>148
＞実戦投入の話題（具体例）があまり無い
＞PEARとかでやりくりしてた人から見るとシステム全体が助長に感じてしまう
PEARはつかってるの？PEARの実践投入の具体例ってどんなのがあるの？

162:148
05/09/07 04:46:27
実はクラスライブラリとか使ったことありませんし
自分で書いたPHPコードをうごかしたことありません
ごめんね

163:nobodyさん
05/09/07 04:56:22
>>156
別に乱立ってほどの数でもないだろｗ
ためしにjavaとかで探してみろよ
特にビスケットなんて無理やり穿り出したようなもんだし

164:148
05/09/07 05:59:16
今日（昨日か）会社でフレームワーク使ってみればって提案したのさ
そしたらやれ情報が少ないとか、
つかい慣れたライブラリのほうが速いとかいわれてさ、
あげくのはてに「こんどうちで最強のフレームワークつくりましょうよ」
とかいいだしてさ。
まるごとPHPと黄色いやつ職場用に買って持ってったのに
「うはーそれ持ってるwww」みたいなノリだし

で、強烈なディファクトスタンダードみたいなのができれば、
疑いも無くそれ使うくせにっておもった。

でこのｽﾚみたら146と147があったから148を書いた。
もう寝るからレスすんなボケ

165:nobodyさん
05/09/07 08:01:46
>>164
会社の上は現状維持したいアホばかりだから気にすんな

166:nobodyさん
05/09/07 11:48:28
>164
お前そのアホばかりの中に入っててお似合いの職場だからから気にすんな。

167:nobodyさん
05/09/07 11:56:22
164に噛みついてる奴はいったい何があったんだろう…
ほのぼのしてたスレなのに無駄に荒らすなよ

168:nobodyさん
05/09/07 12:02:30
ずっと不思議だったのだが
ﾊﾞﾃﾚﾝのフレームワークやライブラリの情報とか
お前らどこから仕入れてくるんですか？

169:nobodyさん
05/09/07 18:22:46
>>164
誰がそんなレスしろって言ったの？で、
PEARの実践投入の具体例ってどんなのがあるの？

170:nobodyさん
05/09/07 18:23:49
>>168
google
気になった情報を調べていくうちに、連鎖的に付加情報が入ってくる。

171:nobodyさん
05/09/07 21:58:39
>>168
開発者のブログが多いかな

172:nobodyさん
05/09/08 01:36:11
まぁ、日本のサイトだけじゃまず情報は補えないな

173:nobodyさん
05/09/08 01:58:54
>>172
あいまいに発言して見栄はらずに晒したらどうよ？

174:nobodyさん
05/09/08 02:32:08
>>173
google

175:nobodyさん
05/09/08 02:33:39
>>173
たとえば、ビスケットとかなんかはPHP-on-Railsで検索して出てきた。
こんなのが見栄に見えるなんて、かわいそうな子だなｗ

176:nobodyさん
05/09/08 03:00:48
別に英語でもかまわないから
こんなフレームワークがあるよって短評と共に
書いてあるサイトがあれば幸せになれると思わない？

試してみないとわからないって意見もあるが
RailsタイプであるとかJSFタイプであるとか
ある程度の分類が分かれば絞れるわけだし。
wikiでも作ろうかな。

177:nobodyさん
05/09/08 03:40:05
>>176
好きにすればいい

178:nobodyさん
05/09/08 03:44:46
最初は糞めんどくせーと思ってた英語ドキュメントも
最近はわりと読めるようになってきたな

179:nobodyさん
05/09/08 03:45:46
かな。じゃなくて、作った。くらいフットワークが軽くないと
ずっと俺の背中ばっかり見ていることになるぞ。

180:nobodyさん
05/09/08 03:54:52
>>179さんの背中見ているだけでも良いのでお願いします。

181:nobodyさん
05/09/08 04:32:25
googleのfirefox拡張が重宝。
単語調べる手間が省ける

182:nobodyさん
05/09/08 04:36:10
DOS窓でExcite辞書引くスクリプト作ってある
Perlで。

183:nobodyさん
05/09/08 04:36:54
コンポジットビューパターンとかで
viewに渡す変数を得るためのクラスを呼ぶ時って、
list($hoge,$fuga,$moge,$nuko) = $poge->piyo()
みたくするのか、
$poge->piyo($request)
みたくして$requestに入れてもらうのか、どっちが定石？
前者だと、何を受け取っているのか分かりやすいけど、面倒くさい。
そしてある程度コピペコーディングをしないといけなくなる。
後者だと、記述が楽だし、
後でクラスを書き換えても、呼び出し側では書き直す必要がないけど、
何を受け取っているのかは、呼ぶクラスの内部を見ないと分からない。
マジ迷ってます。
教えていやらしい人。

184:nobodyさん
05/09/08 04:45:28
>>181
ツールバー入れてたけどこんな機能あるとは知らなかった
すげー便利じゃん
サンクスちんぽ！

185:184
05/09/08 05:04:51
URLﾘﾝｸ(propel.phpdb.org)
propelのこのページ
単語にカーソル合わせても全然違う単語が出る…
同機能がある翻訳ソフトなら大丈夫かな

186:nobodyさん
05/09/09 03:57:25
Mojaviで
jsとかcssのファイルはどこに置いていますか？

187:nobodyさん
05/09/09 18:57:54 y9gKBfXh
>>186
modpub

188:nobodyさん
05/09/09 23:06:05
PHPが範としていたJava界では
ライトウェイト方向に流れてるから
今、PHPでどんなフレームワークを選べばいいのかは
微妙だねぇ。
Mojavi/Agaviは重い気がするし
かといってMapleやguessworkもまだ過程にあるし。

189:nobodyさん
05/09/10 02:00:04
ViewHelper導入したら
随分分かりやすくなったわ。
PHPフレームワーク文化圏で
ViewHelper軽んじられすぎてね？
ライトウェイトフレームワークとも親和性高いと思うんで
考えてみてくれ＞エバンジェリスト達

190:nobodyさん
05/09/10 04:18:39
>>188
Agaviはかなり軽いだろｗ
あ、ごめん。気がするだけで使ったことないのね。

191:nobodyさん
05/09/10 04:32:02
>>190
動作はどうか知らないが
「考え方」がライトウェイトじゃないじゃん？

192:nobodyさん
05/09/10 14:53:27
そもそもEJBを利用いた開発とPOJOを利用した開発を
対比してライトウェイトって言われてるんじゃないのか？
JAVAでいうライトウェイトを引き合いに出してる
時点で見当違いなキガス
とmojavi信者が反論してみる

193:184
05/09/10 23:41:22
ﾍﾞﾀだけど東芝の翻訳インターネット買ってきた
googleツールバーのチップ表示くらいがちょうどいいんだけど
（翻訳インターネットではポップアップウインドウに表示される）
まあ普通に便利ですわ

194:名無しさん＠そうだ選挙に行こう
05/09/10 23:45:21
いまPHPcakeを試してる。
Railsは知らないけど、全体の見通しはかなりいい。
cakeの流儀にさえ従っていればすごく楽をできる。
まぁ、まだバグはかなりあるけど。

AjaxHelperのドキュメントが無いけど、Railsの奴を読めばいいのかな。

でも、cakeをさわっていちばん感心したのはtracだったりする。
そろそろcvsからsvnへ乗り換えたいなぁ。

195:名無しさん＠そうだ選挙に行こう
05/09/11 04:29:16
cakephpはSVNがsslなせいで、subclipseから引っ張り出せないから駄目。

196:名無しさん＠そうだ選挙に行こう
05/09/11 09:34:06
じゃぁstoneとかでsslトンネルを掘ればいいんじゃないのかな。
でもふつうのsvnクライアントを導入すればsvn coと打つだけなのに

197:nobodyさん
05/09/11 23:51:20 9VoVbPCa
PHP使ってるヤフーはフレームワークになんか使ってるのかな。

198:nobodyさん
05/09/13 09:24:36
さあ皆で乗り換えよう

199:nobodyさん
05/09/13 10:08:43
小規模なWebアプリに特化したフレームワークって出ないもんかな？
BBSとかショッピングカートとか、一般にzipで固めて配布するようなもの向けの。
RoRのようなのはまずコマンドで開発環境をそろえるけど、それとは逆で
コマンド1発で必要なファイルをまとめてzipにパッケージングしてくれるような機能つきとか。
guesswork classicが近いアプローチだったと思うんだけど、似たようなフレームワークってない気がするんだ。

200:nobodyさん
05/09/13 10:21:37
特化するとどうなるの

201:nobodyさん
05/09/13 13:43:15
Mapleが3.0.1になりましたな

202:nobodyさん
05/09/13 15:55:29
URLﾘﾝｸ(sharedance.pureftpd.org)

guesswork開発者のページから拾ってきた情報
複数鯖から使えるセッション管理デーモンだって
面白そう

203:202
05/09/13 16:07:17
保存はファイルベースみたいだな
可用性を考えると
DBで良くね？って気もする。
どのあたりに需要があるのだろう？

204:nobodyさん
05/09/13 20:13:56
>>203
「without the overhead and the complexity of an SQL database」だそうですよ。

205:nobodyさん
05/09/13 20:50:43
>>202
別にデータベースセッションハンドラ使ってりゃ、
普通にできるし

206:nobodyさん
05/09/13 21:53:12
>>205
Sharedanceはセッションデータ専用ってわけじゃなくて、単純なハッシュみたいな
もんだから、なんでも詰め込めるけどね。
sharedance_store('key', 'content');

207:nobodyさん
05/09/13 22:24:39
中規模くらいまでなら便利そうかな？
規模が大きくなるとどうなるか不安がある

208:nobodyさん
05/09/14 00:16:08
>>207
大規模ってたとえばどんなの？

209:nobodyさん
05/09/14 00:57:38
>>208
数千～数万人が同時にアクセスするようなの。
セッション用サーバ自体を分散しないとやっていけないような。

210:nobodyさん
05/09/14 01:36:53
>>209
そうじゃなくて、実際の例とか

211:nobodyさん
05/09/14 01:42:09
大規模なSNSやWeblogサービスなんかはそれなりに
セッション管理の土台を強くしないとダメなんじゃないかな
あとはセッションがクリティカルな金融関係とか

212:nobodyさん
05/09/14 01:43:33
>197
ヤフーはLISPだとばかり思っていたよ。
そういえばPHPのページもあるね。

213:nobodyさん
05/09/14 01:46:39
>>211
SNSなんて会員以外は見れないんだから、知れてると思うんだが。

214:nobodyさん
05/09/14 01:57:58
>>213
mixiでさえ130万近いんだが、その数をたかが知れていると？(;´Д｀)

215:nobodyさん
05/09/14 03:22:03
>>212
Yahoo!がLisp使ってるのは本国のShopping部分だけで、
それも買収した会社がLispで開発していたから、ってだけじゃなかったかな。

216:nobodyさん
05/09/14 09:56:26
>>214
mixiのアクティブユーザが130万人いると思ってるの？

217:nobodyさん
05/09/14 10:11:05
手間をかけさせるな

218:nobodyさん
05/09/14 14:41:43
ひょっとしていちいち説明しなきゃならんのか

219:nobodyさん
05/09/14 15:28:44
話が噛みあってなさそう

220:nobodyさん
05/09/14 15:58:23
もういいよ、マンコの話しようぜ。
同棲してる彼女が俺が寝てると思って毎夜オナニーして困ってる。

221:nobodyさん
05/09/14 16:20:17
なんか自分のこと誤解してそう

222:nobodyさん
05/09/14 17:09:35
>>220
お前もいっしょにオナニーしろ

223:nobodyさん
05/09/14 21:07:30
>>214
でさえ、の使い方がおかしい。

224:nobodyさん
05/09/14 23:52:36 SictETF/
Web Application Component Toolkit (WACT)
URLﾘﾝｸ(www.phpwact.org)

これが世界的にそこそこ有名なPHPフレームワーク
だという情報を入手しました。どなたが調査お願いします。

225:>>224
05/09/15 02:33:20
そこそこ使えるらしい

226:nobodyさん
05/09/16 04:57:46 3ASb8eFe
バリデートってフィルタの中でかけるのが普通かな？

227:nobodyさん
05/09/16 05:14:40
>226
簡単、共通そうなものはそうなるんですかね？

228:nobodyさん
05/09/18 10:58:42
>>227
複雑なのはアクションの中ってこと？

229:nobodyさん
05/09/18 12:20:27
転送量で鯖屋から文句が来たから
出力をバッファして改行を削除する関数を
既存サイト（非フレームワーク）に適用した
ファイル修正しまくりで
こういう時にフィルタが役に立つんだなーと実感した

230:nobodyさん
05/09/18 13:24:44
ヘッダ見て対応してれば圧縮すればもっといいんじゃないかな。
そんなのWebサーバでやれとも思うけど。

231:nobodyさん
05/09/18 13:29:26
>>230
Apacheだったら
つ mod_gzip
まあデフォルトor設定のみでやってくれって気もするけど

232:229
05/09/18 16:46:51
一気に変えるのも不安だったから
zip圧縮はphp側のハンドラでやったよ
zipが受け取れないモバイルに対してもパケ代少し減らせるから
まぁいいかなと。
昔あったみたパケ割みたいなフィルタ作ってもいいかもしんない。

233:nobodyさん
05/09/18 22:22:34
改行削除くらいじゃいくらも圧縮できないんじゃないの。

234:nobodyさん
05/09/18 23:50:42
まあ、確かにそうなんだけど
でも×アクセス数になると馬鹿にならないかなと。
一回書けばコストもかからないしね。
しかし昔書いたプログラムを今いじると汚いこと汚いこと…
アンチパターンやりまくりで保守性最悪
フレームワークはある程度枠にはめるから
矯正器具としての役割もあると思う

235:227
05/09/19 23:44:54
>228
アクションの中にビジネスロジックを書くのはイケテないからコンポーネント作って呼ぶんですかね？

236:nobodyさん
05/09/20 00:50:27
>>235
ビジネスロジックはモデルでやってください。

237:nobodyさん
05/09/20 18:56:18
>>214
幽霊ユーザちゃんと含めて考えてますか？

238:nobodyさん
05/09/21 04:10:55
最近Mojavi/Agavi静かだな…

239:nobodyさん
05/09/22 21:14:04
日経システム構築に
PHPフレームワークの記事があった
1Pだけだけど

240:nobodyさん
05/09/23 07:18:01 7QvlMC8T
PHP5の新機能に対応したフレームワークというのはどのくらいあるんでしょうか？

・例外による（フレームワーク側の）エラーの管理
・interfaceや抽象クラスを使った継承による機能の実装
・オブジェクトの逆参照

あたりを利用すると、かなりすっきりしたフレームワークが書けるんじゃないかなー、と、俺フレームワークを書いてみたりしてるのですが……。

……ますますJavaとの違いが無くなってしまう様な気もしないでもありません(^^;

241:nobodyさん
05/09/23 10:10:02
mojaviつかったら、header("Location: http…　ってつかっちゃいかんの？
$controller->forward(… に統一すべき？

242:nobodyさん
05/09/23 10:34:02
>>241
$controller->redirect($url)を使うんじゃない？

243:nobodyさん
05/09/24 00:01:50
うむ。

244:nobodyさん
05/09/24 01:54:49
>>242
しっかし$controller->redirect($url)って使いづらくないか？
$controller->redirect($module, $action)にしてくれたほうがありがたい希ガス。
まー大した違いじゃないんだけどさ。
ラッパ書いたら気持ち的にずいぶん楽になったもんで。

ﾋﾞﾐｮｰにﾁﾗｼ

245:nobodyさん
05/09/24 02:19:29
>>244
俺もﾓｼﾞｬ使ってる時それ思ったな
module,actionをurlにするメソッドあったよね。
あれ呼んでから呼べということなんだろうけど。

246:nobodyさん
05/09/24 03:41:42
>>245
だったらフレームワークが自分で自動的に呼べって話だよなー

247:nobodyさん
05/09/24 10:58:21
で、>>244 に戻る、と。

Agavi で標準装備して貰いますか。

248:nobodyさん
05/09/25 23:54:29
>>245
getControllerPathでしょ？

249:nobodyさん
05/09/26 01:24:18
>>248
M2にはあったのにM3にはなくなってしまった。
アガビにもない。

250:nobodyさん
05/09/26 16:39:07
Mojaviでサブテンプレート実現する時って
ActionChainにregisterしてexecuteしてfetchした結果を
Viewに渡してる？
それとも他のやり方があるのかな？

251:nobodyさん
05/09/26 18:00:20
>>250
mojaviのwikiにサンプル付きであったような気がするけど今はアクセスできないっぽ。
URLﾘﾝｸ(www.geocities.jp)
にそれの訳っぽいのがある。

252:250
05/09/26 19:59:45
>>251
ありがとう
Mojavi系サイトはかなり回ったつもりだったけど
このサイトは初めて知ったよ

253:nobodyさん
05/09/27 04:52:10
>>244
クエリがmoduleとactionだけなんてことまずほとんど無いだろ。

254:244
05/09/27 07:02:06
まあ実際書いたラッパの引数はmodule、action、params、プラスアルファみたいな感じだけど、
漏れの場合サイト内でリダイレクトすべき部分は大概moduleとactionで事足りたな。
リダイレクト自体そんな頻繁でもないし。

ヒント：ケースバイケース

255:nobodyさん
05/09/27 10:04:39
Agaviも全然動きないってどうなんｺﾚ
仕事で使わないでﾖｶｯﾀよ( ´ー`)フゥー．．．

256:nobodyさん
05/09/27 12:00:15
(Moj|Ag)aviを仕事で使ってる香具師なんかいないいない。
みんな本当は趣味でやってんだよ。
あー暗い暗い。

257:nobodyさん
05/09/27 13:39:45
Mojaviにはﾒﾝﾃﾅを迷走させる呪いがかかっているんだよ
ホープ・ダイヤモンドのように・・・

258:nobodyさん
05/09/27 13:45:00
上位でRequest->Parameterを
取得していて、
ActionChain中の子Actionでも同じパラメータを使う時って、どうしてる？

1 Request->attributeにでも入れ直す
2 もう一度request->getParameter()する

259:nobodyさん
05/09/27 14:21:10
>>251
そこ見てやっとデコレーションパターンを理解したよ
slotでテンプレートに渡す表示用パラメータを切り分けてるのが便利そう

260:nobodyさん
05/09/27 19:38:07
MapleやEthnaにCommandパターンが使われてるって
本に書いてあったんだけど本当？

261:nobodyさん
05/09/27 20:59:19 0
Actionがあるのがｺﾏﾝﾄﾞﾊﾟﾀｰﾝだよ
ほとんどのフレームワークはそれでは？

262:nobodyさん
05/09/28 01:31:23
>>255
あれ以上変にいじくられる必要も無い。

263:nobodyさん
05/09/28 01:34:22
>>254
つーかforwardじゃいかんのか

264:nobodyさん
05/09/28 02:20:56
>>254
ヒント：リダイレクト自体そんな頻繁でもないし。

265:nobodyさん
05/09/28 06:35:26
>>262
まだ埋まってないとこポコポコあるじゃん

266:nobodyさん
05/09/28 07:00:02
なんかサブテンプレートってさー
クライアントサイドプログラムだったら、
サブウインドウとかの規格を定めた
アピアランスクラスを作って、
そこにモデルデータを渡して実現するじゃん？
アピアランスクラスはリプレース可能にして。

一方Mojaviとかのウェブアプリフレームワークって
各テンプレートファイルをひな形にした
サブテンプレートを先に作っておいて、
親テンプレートに後からハメハメするやり方じゃん？
このやり方だと、親テンプレートとサブテンプレートに
一貫したアピアランスを実現しにくくない？
なんていうか、
サブテンプレートシステムを
ひとつのクラスにまとめておかないと
アピアランスのリプレースがしにくい、と思う。
どうなんかな、このへん。

267:nobodyさん
05/09/28 13:50:54
なんかカタカナばかりだな。
今風なのか？

268:nobodyさん
05/09/28 14:11:20
いや日本語でどう言えとw

269:nobodyさん
05/09/28 14:11:53
ああ、たしかにナウでヤングなモボっぽいな

270:nobodyさん
05/09/28 16:24:02
アピアランス＝外観
テンプレート＝雛形
リプレース＝入れ替え
ハメハメ＝嵌め込む
サブ＝男色

271:nobodyさん
05/09/28 21:39:30
>>270
・・・男色の雛形は
単一化されないと
見た目ではハメ辛いと思う。
どうなんかな、このへん。
【意訳】
ぱっと見、ゲイはゲイらしくしてくれないと
そのときになってびっくりする。
どう思いますかみなさん。
【私の意見】
そー思います。

272:nobodyさん
05/09/29 02:01:15
カタカナ語は「一般名詞ではなく、テクニカルタームですよ」という
サインだから
単なる訳以上の機能性もある。

273:266
05/09/29 11:21:35
サブテンプレート間で一貫したアピアランスを実現する方法を考えたよ(´･ω･`)
共通プレゼンテーションロジック保持クラス
GrobalViewHelperを作っておいて
どのテンプレートを作るときにもそいつを派遣しておく…（・∀・）ｺﾚﾀﾞ!!

274:nobodyさん
05/09/29 11:28:07
Globalだった(´･ω･`)

275:nobodyさん
05/09/30 16:21:47
いいかお前ら、ド素人の俺が今からすっごいこと言うぞ・・・・
気の弱い奴はパンツ脱いどけ。。。。

「っていうかフレームワークって何だよ！？」

276:nobodyさん
05/09/30 16:42:01
>>275
『枠組み』の事です。従来のライブラリと比較すると

ライブラリではそれを使ってどのように作るかを必死に考えなければならなかったのが
フレームワークでは、このように作りますってのがフレームワーク側で決まっているので
共通できないロジックやパラメータだけ与えればアプリケーションが出来てしまう。

277:nobodyさん
05/09/30 16:45:14
どの程度勝手に決められているのか？ってのが
フレームワーク選択基準のひとつになり
例えばStrutsなんかは自由度が高い事で有名。

278:nobodyさん
05/09/30 19:43:03
>>276
親切にありがとう。
でもド素人にはまだちょっと理解しづらい。。。

つまりアレか、PHPでも、VBみたいにマウスでフォームやボタン配置できるとか？？

279:名無し
05/09/30 19:47:16 gpQXP9hq
どうもこんばんわ

280:nobodyさん
05/09/30 19:47:48 gpQXP9hq
はじめてです

281:nobodyさん
05/09/30 19:49:19 gpQXP9hq
いきなりですけどおちます

282:nobodyさん
05/09/30 22:22:00
和製フレームワークって
Viewクラス用意してないものがほとんどだよね。
実際Viewでやることってテンプレートにassignするだけ
みたいなもんだし。
面倒なだけのViewｲﾗﾈ(ﾟдﾟ)､ﾍﾟｯ

283:nobodyさん
05/09/30 22:26:22
じゃあ、いいじゃん

284:nobodyさん
05/09/30 22:43:42
あとMojaviはRequestのattributesと
UserのParameterが役割的にｶﾌﾞってるのが美しくない。
ｼﾝﾌﾟﾙｲｽﾞﾍﾞｽﾄなんじゃい(*ﾟдﾟ)､ﾍﾟｯ

285:nobodyさん
05/10/01 03:49:30
>>284
どうかぶってんの？

286:nobodyさん
05/10/01 03:58:54
セッションの実装がねぇ。
逆にどうすりゃいいんだ？今ならいい方法があれば提案出来るんじゃないか。

つーかおまいらがどうやってるのか不思議で仕方ない。
どう文句つけようと、PHP5 だと現状、俺 Maple, Mojavi の二択だと思うんだが。
それ以外のフレームワークを実戦投入したという話は聞いたことないし。

287:nobodyさん
05/10/01 04:03:57
>>285
両方とも汎用コンテナ
かぶってるからuser->parameterはあまり使わないけど

288:nobodyさん
05/10/01 11:04:43
やはりフレームワークの「意味」と「利点」、「用途」がサッパリわからない・・・
実はこれらを説明するのって難しい？

289:nobodyさん
05/10/01 12:04:04
>>288
解っちゃえば何てことない話なんだけど説明しようとすると難しい

例えばDBとか使ったサイト作るっしょ
んで別のサイトを作る時に，前作ったサイトのパーツを流用したりするっしょ
で，それを繰り返してくと，今度は逆に，パーツの方を流用しやすく作るようになるっしょ

そういうパーツが色々な機能を網羅していくと
最終的には「サイトごとに同じような処理はみんな共通」とか
「ここをちょっと変えるだけで各サイトに適用可能」とかになっていく
その集合体の完成形がいわゆる「フレームワーク」

……ってな説明でどうかなぁ？

# もちろん今あるフレームワークが上記のようなボトムアップで作られたものなわけではないが……

290:nobodyさん
05/10/01 13:33:56
>288
小規模の案件やってる限りはわからないし、使う必要も無いよ。
フレームワークの利点がわかる状態、というのがフレームワークが必要な状態。

291:nobodyさん
05/10/01 14:20:43
>>289
なるほどぉ・・・、ってことは、いま自分がやってる作業（この部分は他でも
使いまわしやすいように作ろう）ってのも、ある意味で自作フレームワーク？？

それを追及していくと、ほとんどどんなサイトやシステムでも部品は共通なものばかりだよね。
よっぽど斬新なものでない限り、既存の部品を既存の組み立て方すればいいだけだよねぇ。
フレームワークがそういうものだとしたら、Webアプリ作成が劇的に簡単になりそう。
・・・でもMojaviとかの説明を読んだりすると、もうそれ自体が難しく感じる。。。

>>290
ってことは、俺はまだ必要な状態ではないのかな・・・。

292:nobodyさん
05/10/01 14:42:28
>>291
ある意味「俺フレームワーク」とかいわれるものがソレなんだと思うよ
そして他人が書いた「俺フレームワーク」は慣れるまでは大抵使いにくい
ただ自分より頭の良い人が書いたものならたぶん慣れれば自分のより効率良くなるのだろう
でもそれは今まで自分が思いつきもしなかったような発想で作られていたりするから
学習曲線の最初はだいぶきっつかったりする

>>290の言ってるのは
慣れちゃった後なら小規模案件でも使わない理由はないと思うけど
小規模案件のためにわざわざ慣れる必要があるかってーと
それではC/P比が悪い，ってことじゃないかな
大規模だと少しでも効率良くなるとかける人数で効くので大きいのと
よく整備されたフレームワークはそれに則ったコードを書けばいいのでコードが変に発散しにくいのが利点

293:nobodyさん
05/10/01 14:45:18
デザイナ含めて3人ぐらいの小規模しかつくらないけど
俺は「俺フレームワーク」捨てちゃいたい時ある。糞コードだもんなあ

294:290
05/10/01 14:45:40
>291
覚えると気持ちの上での楽さはあるけどね。
MVCの切り分けや入力値チェックなどを、どこに書くべきかを含めて明示的に示してくれるわけだし。
でもフレームワーク使ってなかった頃はそんなの自分で勝手に分けて書いてたわけだし
数週間くらいでできるような案件を一人でやるなら
無いなら無いで普通に作れるし、大して手間も変わらないように思う。

そんなこと関係なしに、興味があるなら使ってみるのが良いよ。

295:290
05/10/01 14:47:50
>292
素晴らしいフォローが入ってる。
まったくその通りです。サンクス。

296:nobodyさん
05/10/01 16:35:15
フレームワークは楽をするためのものと言われて、
実際そうなんだけど、
その楽さって「記述量が少ない楽さ」じゃないよね
記述量は、逆に迂遠に思える時も多々あって、
俺なんかは「ﾊｧ？どこが楽なんだよ。面倒くさいだろ」と
反発を感じながら自分なりのお手軽メソッドを追加してたりしていって
気づいたら何だか見通しが悪くなってた。
提供者は
「コーディング量は、そんなに減らないし、逆に増えるかもしれません。ただし、長い目で考えると楽です」と言ってほしいところ。
最初から「とにかく楽したい」の精神で行くと、
その良さを理解するのに結構時間がかかる。

297:nobodyさん
05/10/01 17:08:24
単純なものを作るとしても、フレームワーク使って作ると、
余計なこと考えないで済むから楽ちんだと思ってしまう漏れは負け組？

298:nobodyさん
05/10/01 21:01:51
とりあえずここまで説明してもらってもまだフレームワークの良さが
イマイチ分からない俺は、ちまちま自力でやっていこうと思いまつ。

そうしてるうちにフレームワークが必要になる日が来るかもしれない。
むしろ最初の基礎は全部自分でやれるようにしといたほうが後々いいかも。

299:nobodyさん
05/10/01 21:10:53
ちまちまアセンブラで大規模アプリを書けるようにがんばります。ということ？
馬鹿馬鹿しい。

300:nobodyさん
05/10/01 21:21:42
>>299
なんでいきなりアセンブラが出てくるんだ？
比喩にしてもおかしいし？？？

301:nobodyさん
05/10/01 21:32:08
小さなプログラムを個人で書きなぐってるって人なんじゃないの？

仕事で似たような案件を多くあつかっていると、大枠で共通することが
多いことに気づいてくる。それをくくりだして同じ事を何度もしなくても
いいようにしようと思うわけだ。
言語レベルではライブラリとして共有できるようになってる。
さらに扱う対象によっては毎回似たようなプログラムの流れになることがある。
その似たような部分の構成を使いまわしできるようにしておくと、効率があがる。

299さんの言っていることも極端ではあるけど考え方としては同じこと。
アセンブラがあれば何でも記述できるけど、WEBアプリなんか書く時にはPHPが
適しているのでPHPで書く。毎回アセンブラからまずPHP（あるいは俺言語）を作って
仕事に取り組むってのは能率悪そうでしょ？

ただフレームワークを必要としない人や場合もあるのだから 290さんの言うように
必要としていない状況なのかもしれない。

302:nobodyさん
05/10/01 21:38:29
ちょっと流れ無視なのかもしれませんが、
クラス・ライブラリとフレームワークの違いって何ですか？

ライブラリ群＝フレームワーク？と思っているんですが。

303:nobodyさん
05/10/01 21:56:33
・画面遷移の仕組み
・入力データのヴァリデーション
・HTML表示のためのテンプレートエンジン
・セッション管理
・アクセス制御
あたりの機能を体系的にまとめたものが、いわゆるフレームワークと言っていいと思う。
特に上3つはフレームワークと呼ばれるものには必ず存在するかな。
ただ、それぞれの機能単独のライブラリもあるから、そういうライブラリを自分で組み合わせても構わないし、
そっちの方がいい場合もあるだろう。

304:nobodyさん
05/10/01 22:48:16
保守性のメリットもあるお

305:nobodyさん
05/10/01 22:55:55
フレームワークの意味や利点が理解できない漏れは、
当然クラスの良さも分からないし使ったこともない。
「良さが分からない」というか、「使用法を習得するほうがめんどい」。

だからPEARも一度も使ったことなく（ちょっと調べて断念）、
よく使う機能については「俺ライブラリ」（せいぜい自作関数）的なものを作って
ファイルにまとめて、それをincludeしたり部分的にコピペして貼ったりして再利用してる。
それで十分便利だし苦にも思わない。

306:nobodyさん
05/10/01 23:10:17
>>305
苦にも思わないならそれでいいんじゃないかな？
上で大規模小規模って話が出てきてるけど
大規模→大人数となってくるとそれを苦に思う人も出てくるだろう
その時になったらまた考えればいいと思う

繰り返しになるけど，最初の学習曲線をよじ登る手間が，
初めから登らなかった場合の手間の総量を上回らないなら，登らない方がトータルで良いしね

ただ経験から言わせてもらうと，
仕事でPHPをやってる限り，結果的にはたぶん総量を上回ることになると思う……

307:nobodyさん
05/10/02 00:39:45
まあ、PHPは標準関数の機能が多いから、PEAR使わなくても構わない場合は多いけどな。
Perlの場合、CGI、DBI、HTML::Template、CGI::Sessionあたりを使わざるを得ないけど。
ただし、PHPは名前空間が区切れないから、クラスを使わないとグローバル変数名の衝突をさけられない。
なんで、処理がある程度複雑になってきたら、クラスを使うしかなくなる。

308:nobodyさん
05/10/02 01:42:18
自分1人で開発してるうちは
フレームワークの恩恵はそれほどないかもしれない
小規模のものを作るのには必要ない
単純なメールフォーム作るのにフレームワークなんていらない

複数人でそれなりに規模のあるものの
開発をしようとするとそれぞれのスキルと作り方で
同じ処理の流れのものを作っていても
コードや構成はばらついていく

だから遷移方法や処理のプロセスはこういうやり方で
ここにそのコードを置いてくださいという
取り決めがフレームワークで
チーム全員がその取り決めにならって開発していく事で
誰が書いても全体の構成がある程度統一されていく部分が
フレームワークを使う事の一番のメリットなんじゃないのかな

309:nobodyさん
05/10/02 02:06:00
PHPには、PerlのCGI::ApplicationやJavaのStrutsほどメジャーなものはないし、開発者全員がそのフレームワーク自体を覚えないといけないってコストがかかる。
他にもデメリットとして、smartyのようなテンプレートエンジンを使うと実行速度がぐっと下がるし、
標準であるべきDBクラスのPEAR_DBは、標準関数と比べて圧倒的に速度が遅い。代替のDBクラスもあるけど、これも乱立していて学習コストがかかる。
さらに言うと、PHP開発者のスキルは概して低い。
PHP開発者の確保は、Perl開発者、Java開発者の確保よ低コストだけど、PHPでOOPやフレームワークを扱える開発者をそろえるのは難しい。
こういったデメリットを乗り越えて、なおフレームワークにメリットがあるかどうかを考えないといけない。

310:nobodyさん
05/10/02 02:36:39
PHPのスレで言うのもアレなんだがRubyのRails試してみるといい。
あとAppleのWebObjectsとか。Gauche(Scheme)なKahuaも
ええよ。

311:nobodyさん
05/10/02 09:25:07
ライブラリは自分の書いたコードがライブラリのコードを呼び出す
フレームワークは自分の書いたコードがフレームワークのコードから呼ばれる

基礎の基礎。

312:302
05/10/02 09:44:41
>>303
分かりやすい説明ありがとうございます。
Webアプリ用のフレームワークについてはなんとなく分かったような気がします。
でも「Mac OS XのCocoaフレームワーク」なんていうのを
聞いたことありますが、あれはHTMLとは関係ないですよね。
そういう場合はどう考えればいいのか。

>>311
呼び出す方向による分類は新鮮です。いや、これに関しては無知でした。
デスクトップ・アプリで言うところのイベント駆動型かどうかという分類でしょうか。
ありがとうございます。

313:nobodyさん
05/10/02 10:35:14
チーム開発のメリットだとしても、それフレームワーク使うより、
PECLで独自の拡張関数を増やすほうがよろしいんじゃないでしょうかね

314:nobodyさん
05/10/02 13:12:15
扱っている案件において検討した結果
そういう結論に至ったのならそういうケースもある。

当然フレームワークを利用する方が良いケースもあるでしょう。

315:nobodyさん
05/10/02 13:18:58
PECLで独自関数っていうとCで拡張モジュールを書くということ?
それがチーム開発においてプラスになるのはかなり特殊なケースに思えるけど。

ていうかそんなの実際にあるんかいな。

316:nobodyさん
05/10/02 16:48:05
あなたまかせの特定のフレームワークを使い倒すよりは、
独自拡張をあわせたほうがいい気はするけどな

317:nobodyさん
05/10/02 16:59:18
>>311
シンプルだけど本質的な定義だな。

318:nobodyさん
05/10/02 19:28:25
$context =& $this->getContext();
$controller =& $context->getController();
$request =& $context->getRequest();
------------
$controller =& $this->getContext()->getController();
$request =& $this->getContext()->getRequest();

あなたはDOTCH派？

319:nobodyさん
05/10/02 19:39:32
そもそも PHP4 じゃ前者でしか書けない罠

320:nobodyさん
05/10/02 22:32:53
どっちも意味不明派。

321:nobodyさん
05/10/02 22:42:00
後者は&いらないんじゃないか？

そんな自分は「= &$foo」派

322:nobodyさん
05/10/03 04:04:57
>>318
PHP5では&はいらないわけだが。
むしろそのへんのことも含めMojavi系は面倒くさいので、そっとごみ箱にいれた派。

323:nobodyさん
05/10/03 09:12:25
>>322
めんどくさいかなぁ？？
フレームワーク使わずにどうWebアプリ構築してるのか知りたい。
べた書き？後から見辛くない？

324:nobodyさん
05/10/03 09:14:42
別にPHP4だから、かならず参照渡ししないといけないわけじゃない。
対象のオブジェクトや配列の複雑さの程度だとか、後から値を変えたいかとかによる。

325:nobodyさん
05/10/03 10:55:25
>>324
まあ確かにそうだけどさ、プロパティを変えないつもりでオブジェクト値渡ししといたら、後々になってからやっぱりプロパティを変える操作をした場合に辻褄あわなくなるじゃん。
PHP4だったら常に参照渡しにしたほうが楽な希ガス。

326:nobodyさん
05/10/03 12:48:32
配列はよりけりだけど
オブジェクトは一律参照渡しでほとんど問題なくない？

327:nobodyさん
05/10/03 14:42:31
問題ないというか、PHP5や他の言語を考えると
必要な場面でのみ値渡しにしたほうがいいと思う

328:nobodyさん
05/10/03 15:56:03
要はオブジェクトは特に理由がないなら参照渡しにしとけって話でFA。

329:nobodyさん
05/10/03 16:02:55
ふりーえーじぇんと宣言？

330:nobodyさん
05/10/03 19:53:20
っていうか参照渡しとか値渡しとか意味わからん漏れはダメ人間。

331:nobodyさん
05/10/04 03:25:49
どうしてわかってくれないのっ！

332:nobodyさん
05/10/04 16:01:01
ティン！

333:nobodyさん
05/10/04 18:09:25
フレームワークとふかわがものすごいﾐｽﾏｯﾁだな

334:nobodyさん
05/10/04 20:38:36
　　　 _____
　　 /二二ヽ
　　||・ω・||　＜ﾃｨﾝ!!!!!
　　　|σ　|σ
　　　> 　>

山崎邦正ならマッチするのに

335:nobodyさん
05/10/05 17:39:44 gDrff9QN
requestとかcontrollerをAction中の複数のメソッドで使う時、
initializeでgetしておいてprivateなプロパティーとして持っておくのはｱﾘ？

336:nobodyさん
05/10/05 17:49:44
最近主流の複数画面で構成されてるサイトって
フレームワーク（的なもの）がなければ作れないよなぁ。
ベタ書きで作ってるサイトなんてあるんだろうか？

337:nobodyさん
05/10/05 22:36:32
>>336
複数画面で構成されてるサイトって ?

338:nobodyさん
05/10/05 22:44:00
>>337
ヘッダ-メイン-右サブ-左サブくらいにエリアが分かれてて
それぞれのエリアのコンテンツ構成が動的に変化するようなの。
ポータルとかニュースサイトのほとんどがこれ系だよね。

339:nobodyさん
05/10/06 01:04:30
別にフレームワークが必須だとは思わないけど。
フレームワークが一番効果を発揮するのは、何画面にも渡るアンケートフォームだろうね。
アンケートデータの持ち回りと、ヴァリデーションに応じて遷移先の画面が変わるから。

340:nobodyさん
05/10/06 01:17:22
>>338
別にベタ書きでも書けるけど、フレームワーク使ったほうが早いときもあるってだけの話だ罠。

>>335
Mojavi系の話だよね？毎回contextから取得するのがMojavi標準的くさいからﾅｼ。
ローカル変数にrequestとか入れるくらいまではｱﾘだと思うが。

例えばヘタに$this->request = "うんこ";とかやると他のメソッドに響くし。
その点では、PHPにfinalがあればMojaviの仕様も大分違ってたのではないかと想像。
少なくとも$this->context->getRequest()か$this->context->requestくらいにはなるんじゃないかな。
$this->requestまでなるかどうかは、何とも言えないがｗ

341:nobodyさん
05/10/06 06:29:57
>標準的くさいからﾅｼ。
久しぶりにその方言聞いた。なつかしいなー。

342:nobodyさん
05/10/06 13:06:02
URLﾘﾝｸ(www.glamenv-septzen.net)

和製フレームワーク追加

343:nobodyさん
05/10/06 13:07:29
仕事でMojavi使ってた人は今どうしてるんだろう
Agaviに流れたのか他に行ったのか

344:nobodyさん
05/10/06 15:47:14
>>339
データの持ち回りなんてセッションで十分だと思うのだが・・・・
いまだに俺はフレームワークの利点が分からない。

345:nobodyさん
05/10/06 19:53:34
>>342
名前似てるけど、俺は和製フレームワークはpokが一押し。

>>343
多分仕事で使ってた人は、少なからず手を加えてるので、
わざわざAgaviには流れてないんじゃないのかな？

>>344
自分一人で作ってたりする人はそうかもね。
「俺的フレームワーク」ってのを知らんうちに使ってたり。
まさか毎回1からなんて事はないでしょ？

346:nobodyさん
05/10/06 20:18:00
>>345
その pok ってのポインタきぼん

347:nobodyさん
05/10/06 20:24:05
URLﾘﾝｸ(www.geocities.jp)
ここのおかげでやっとDecoratorを理解した…
自分がﾊﾒﾊﾒされるテンプレートをあらかじめ指定しておけるんだね。
こりゃ便利だ。

348:345
05/10/06 21:31:38
>>346
URLﾘﾝｸ(cgi39.plala.or.jp)
S2Container.PHP5の人ね。
Seasarに関わってる人達を個人的にスゲー注目してる。
パフォーマンス的には？？って感じは否めないけど、
PHPでも結構やれるなって事がわかって良かった。
スゲー勉強になった。
S2Daoとかｽﾝｹﾞｰ期待してる。
俺の中では糞盛り上がってるんだけど、
MLとかｽﾝｹﾞｰ寂しいし、ひょっとしてめちゃくちゃ
ﾏｲﾅｰなのかなぁ・・・と心配になってきてる・・・。

349:nobodyさん
05/10/07 01:02:37
>>348
ありがとー

Seasar.PHP の ML は読んでるから名前は見ていた人だわ
S2Dao とかおれも期待しているんだけど
正直，きちんと追ってない人には活動が何してんのか見えなさすぎて，
それがマイナーっぽい原因になってるんだろうなーと思う

350:nobodyさん
05/10/07 04:58:48
フレームワークのウリとしてフォームの取り回しの簡便化がよく喧伝されるけど
俺はそこはあんまり重要じゃないなぁ。
そんなにしょっちゅう書く部分じゃないし、もともと単純な処理がほとんどだし。
デザインパターンに基づいた保守性の高さや、
見通しの良さの方が嬉しい。
簡単なことが簡単になっても、あんまり嬉しくないけど
複雑なものを単純にすることが出来たら、かなり嬉しい。

351:nobodyさん
05/10/07 05:03:27
privateやprotectedもないPHPでデザパタ重視はどうかと思う

352:nobodyさん
05/10/07 05:20:40
>>351
釣りなのか、PHP5 を知らないのか、どっち？

353:351
05/10/07 05:23:35
>352
釣りだ
350はデザパタがメインのレスじゃないだろ
まぁこれでも読んで考えてくれ
URLﾘﾝｸ(www.enpitu.ne.jp)
このスレとは全然関係ないんだけどさ

354:nobodyさん
05/10/07 08:06:14
フレームワークを使っているから、オブジェクト指向かというと、そういうわけでもないよな。
メンテナンス性を上げようと思えば、在り物のフレームワークを使うより、
自分なりにそのWEBアプリにあった仕組みを考えた方がメンテナンス性が上がる場合もあるだろうし、
メンテ担当の技量を考えて、クラスをいっさい使わないようにした方がメンテしやすい場合もあるだろう。

355:nobodyさん
05/10/07 13:12:01
forwardすることを前提としたactionでも、
url直接入力して直呼びすることもできるよね。
何か対策してる？

356:nobodyさん
05/10/07 13:37:39
してる

357:nobodyさん
05/10/07 13:56:25
いくつか方法は考えられそうだけど
どんな？

358:nobodyさん
05/10/07 14:04:28
requestにsetAttributeして飛び先actionで確認

359:nobodyさん
05/10/07 14:12:14
なるほど　thanks

360:nobodyさん
05/10/07 16:36:25
結局そういうことにrequestのattributeだとかuserのparameterを使うと、（コントローラの呼び出し等を除いて）実行されるコードの最初から最後までアクセス可能ってことになる。
そうなるとグローバル変数と変わらないんだよな。
もっと各状態の遷移ごとにアクセス制限のかかったデータの受け渡しができればいいんだけど、うまくいかないもんだ。

361:nobodyさん
05/10/07 17:27:56
セッション管理ではだめなのか？

362:nobodyさん
05/10/07 17:40:15
>>354
おいおい、そんな事させるからPHP使いはウンコのまんまなんだよ。
クラスを一切使ってねぇ～システムなんざ見る気しねぇ～よ。
つーかクラス使わずどうWebアプリ作ったらいいんだろ？すら思う。

363:nobodyさん
05/10/07 17:53:18
351の言ってる保守性は、アプリ自体の保守性
354が言ってるのはアプリ上に乗っかってくるデータやコマンドのメンテナンス性
で、フォーカスしてる層が違う感じがするな

364:nobodyさん
05/10/07 18:27:14
PHP4にはデストラクタないし、例外も投げれないから、クラスをネストさせたり、複雑に組み合わせたりはやりづらいよね。
スコープを明示できないからクラスを使わざるをえないけど、それじゃあクラスをクラスらしく使ったプログラミングとは言えない。
もっとも、WEBアプリというジャンル自体、オブジェクト指向のメリットがあまりないジャンルだと思うね。
どっちみちリクエストのたびにオブジェクト作り直しになるわけで、ユーザからの入力データもリクエストごとにフラットにしかこないわけで。使いどころがない。

365:nobodyさん
05/10/07 18:32:28
> もっとも、WEBアプリというジャンル自体、オブジェクト指向のメリットがあまりないジャンルだと思うね。

ふーん。

366:362
05/10/07 18:41:02
>>364
それは俺に対する回答だと思っていい？

クラス使ってる＝オブジェクト指向っていうのが間違ってると思うよ。
実際自分を顧みるに、オブジェクト指向を意識してクラスを使い始めたが、
オブジェクト指向にはならず、単に構造化になっただけだった。
だがそれだけでもかなり見通しが良くなったと思ったよ。

単にメンテ性だけを考えてもクラスを使用しているアプリと、
クラスを全く使用してないアプリとどっちがメンテし易いか？
って考えるとどっちだと思う？
俺はベタ書きで書かれたものを渡されて「メンテしろ」って言われたら、
とりあえず「作り直させてください」って言うな。

あと、クラスのネストってどういう事？

367:nobodyさん
05/10/07 23:01:26
DecoratorTemplate使う時で、
HTMLのヘッダ部での
外部JavaScriptファイルの読み込みとか
JavaScriptの初期値設定が必要な場合、どうしてる？
自分が「部分」になれるDecoratorは便利だけど
入れこみたい情報がソース中でバラける時、面倒くさいなぁ。

368:nobodyさん
05/10/07 23:14:07
別にクラスを使えばオブジェクト指向になるとは思わないよ。
それとフレームワークとオブジェクト指向とは関連性があるわけじゃないとも思う。
まあ、フレームワークにもよるけど。
これは言うまでもないと思うけど、オブジェクト指向を生かせるのはGUIのデスクトップアプリケーションとか。
WEBアプリの場合、リクエストの度にオブジェクトを作り直さないといけない。
特にPHPは永続化をどうするか？とか、言語機能が少ないとか、速度が落ちるとかっていう欠点もある。
まあ、これからはAjaxとかFlashとかで、高度なGUIを持ったWEBアプリが要求されるだろうから、そうなるとオブジェクト指向のメリットも出てくるかな。
けど、HTML自体があまりオブジェクト指向なプレゼン言語とは思えないんだよなあ。

369:nobodyさん
05/10/07 23:26:18
>>368
フレームワークとオブジェクト指向とは関連性があるわけじゃないとも思う

って関連ありまくりじゃん。
OOのエッセンスが分かちがたい程たっぷり入ってると思うよ。
OOを使わずともライブラリ集は作れるだろうが、
フレームワークは作りにくいだろう。

次ページ