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
気になった情報を調べていくうちに、連鎖的に付加情報が入ってくる。
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
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を使わずともライブラリ集は作れるだろうが、
フレームワークは作りにくいだろう。
370:nobodyさん
05/10/08 00:07:12
>>368
今時「PHPでOOPすると性能が落ちる」とか言ってるのは時代錯誤もいいとこ。
371:367
05/10/08 01:39:24
ViewHelperで解決した(゜д゜)
372:nobodyさん
05/10/08 01:55:47
デストラクタもないのにオブジェクト指向ってありえるんだろうか？
373:nobodyさん
05/10/08 02:24:56
なんだこの掃き溜めは
374:nobodyさん
05/10/08 02:26:59
デストラクタがないとオブジェクト指向なプログラミングができない、
という思考回路が判らない。言語仕様に捉われすぎてる悪寒。
375:nobodyさん
05/10/08 02:28:24
ありだと思うな。
Cでもオブジェクト指向でまとめられたライブラリやツールキットは山ほどあるし。
オブジェクト指向プログラミング自体はべつに大抵の言語で可能だとおもう。
たしかにPHPはオブジェクト指向言語として設計されたわけじゃないが、
これとPHPでオブジェクト指向プログラミングをする事は矛盾しないだろう。
376:nobodyさん
05/10/08 02:45:50
てか5にはデストラクタもあるよ。
でもウェブアプリでデストラクタを使う機会はあんまりないだろ。
377:nobodyさん
05/10/08 05:08:37
>>372
あるよ
378:nobodyさん
05/10/08 05:09:53
>>370
時代錯誤というより、単に知識が乏しいだけだと思う。
379:nobodyさん
05/10/08 05:32:22
このスレでPHPによるオブジェクト指向プログラミングを否定している
連中は、オブジェクト指向じゃなくてC++ or Java指向になってるんじゃないか？
rubyもデストラクタは持ってないしな(GCがあるからだけど)。
380:nobodyさん
05/10/08 06:07:15
確かにウェブアプリじゃデストラクタなくても、なんとかなる。どうせ1回こっきりでプロセスごと終了するんだから。
そうすると、こったオブジェクト作ってもしょうがないじゃん。シングルトンとか、ウェブアプリでどれくらい意味あるのか。
381:nobodyさん
05/10/08 07:48:43
>>380
SingletonはDB接続に関するクラスで使ってるな俺は。
スゲー便利だしすっきりするなぁって思ったね。
要は使い方によるかなと。
382:nobodyさん
05/10/08 07:56:41
ほっといてやれよ。
383:nobodyさん
05/10/08 08:43:12
>>381
１回のアクセスでオブジェクトが全部ご破算になるWebアプリでシングルトンの意味はある？
$_db_ = new MyDB();
function getDB() {
global $_db_;
return $_db_;
}
:
:
//実際使う場所
$db = getDB();
これでいいんじゃない？
384:nobodyさん
05/10/08 09:07:34
>>383
グローバルオブジェクトを利用したSingletonの実装の一形態だろそれ
いいんじゃない？ と言われりゃそうですねと言うしかないな
Java厨って実装から何から全部Javaと一緒じゃないと否定したがるのがうざいな
385:nobodyさん
05/10/08 09:16:29
>>383
意味が無いと思ったら使わなければいいだけの話じゃん
386:nobodyさん
05/10/08 09:45:38
PHP5にはデストラクタあるだろ。
387:nobodyさん
05/10/08 10:47:02
あるって何回も書かれてるってw
388:nobodyさん
05/10/08 10:56:20
383のやり方だとグローバル空間が汚れるじゃん。
_を使うのはやっぱり苦肉の策だし、クラシックな作法だろう。
389:nobodyさん
05/10/08 11:00:17
おれはsingltonならstaticで書きます。
390:nobodyさん
05/10/08 14:36:34
DB_DataObjectなんかは>>383みたいな感じだね
Java厨というよりJavaを意識しすぎたPHPユーザー、みたいな印象を受ける
Javaを意識するあまり、「PHPじゃないと出来ないことをしないといけない」みたいな傾向ってあったと思う
最近はその対象がRubyに移ってきたみたいだけど
391:nobodyさん
05/10/08 16:18:59
俺はDB接続部分をSingletonにして、各テーブルに発行するSQL文などを集めたクラス
がgetInstanceするって感じに使ってるけど、おかしいのかな？
各テーブルというと語弊があるかな。ある程度のテーブルを纏めたクラス。
JOINする場合（というかJOINしない場合が珍しいけど）は基となるテーブルのクラスに入れる。
$a = Atables();
$b = Btables();
print_r($a->getSelect());
print_r($b->getSelect());
って感じで。
全然スマートじゃないなぁとは思うけど、
DB周りはどうやったらスマートになるのか
全然わからん。解説サイトではロジック部（？）とSQL発行部
が混じっているが、個人的にそれはすごい抵抗があるし。
誰かご教授下さい・・・。
あ、今月のPHPプログラマーズマガジン無料だって！
JPSPAN扱ってるね。あれ@ITかなんかで廣川さんが
解説してて、それ以来使ってるけど、あれ使ってる人って
聞いたことないから不安になってた。
スレ違い＆長文すまん。
392:nobodyさん
05/10/08 16:42:29
OOにデストラクタを重視する奴は意味が分からないな
前時代の遺物的存在じゃん
後片付けは言語側で勝手にやってくれる方が今風だし、ｷﾚｲだ
393:nobodyさん
05/10/08 17:14:13
C++でOOP入りした人は感覚的に染み付いていて、抵抗あるんじゃないかな。
オレも昔はそうだった。ruby, PHP, C#で、すっかり骨抜き？にされたけど。
なんつーか最初の頃は堕落した感じがしたもんだ。
（良い悪いとかじゃんくて、楽チン→堕落、みたいな妙な感覚）
394:nobodyさん
05/10/08 17:52:40
お、お前ら・・・お前ら何言ってんだ？？
お前らの会話の内容がサッパリ分からんぞ、DQNな漏れは。
もうね、難しいとか難しくないとかいうレベルじゃない。
何の予備知識もないスワヒリ語を聞いてる感じ。
395:nobodyさん
05/10/08 18:06:12
>>394
それはDQNだからじゃなくて単にオブジェクト指向開発用語を知らないだけだと思う
つまりそれを勉強すればこの会話の意味はすっかり解るだろうし
勉強して損ないものなのでぜひ習得してみるべし
396:nobodyさん
05/10/08 18:38:45
>>395
勉強できる Web をうpきぼん。
397:nobodyさん
05/10/08 19:05:01
>>392
勝手に行うのはメモリ開放だけだろ。
さらにPHPはfinally構文がない。
398:nobodyさん
05/10/08 21:14:56
finally構文ってオーバーライドを禁止するfinalのことか？
finalならPHP5にあるが。
399:nobodyさん
05/10/08 21:17:47
>>398
例外処理のfinallyでしょ。
Javaなら以下のように書けるけど、PHPではfinallyが書けないので
リソースの破棄を行いたい場合などに二度手間になることがある。
try {
例外の起こりそうな処理
} catch (Exception e) {
例外発生時の処理
} finally {
例外が起きても起きなくても実行したい処理
}
400:383
05/10/08 22:26:28
>>390
> Java厨というよりJavaを意識しすぎたPHPユーザー、みたいな印象を受ける
JavaはHelloWorldくらいしか書いたことないな。
俺のよくいじる言語はSmalltalk, Ruby, PHP, JavaScriptだよ。
あとSchemeも好きだな。
わざわざclass定義してstatic変数用意して２つもメソッド書いて、
結局>>383のたった6行でできることをかえって複雑にするのはアホらしい
ってことだ。
401:nobodyさん
05/10/08 22:41:27
まあ、「Singletonって書きたいだけちゃうんか」というコードが多い
という気はする。
402:nobodyさん
05/10/08 22:43:38
>>309
>>他にもデメリットとして、smartyのようなテンプレートエンジンを使うと実行速度がぐっと下がるし、
これはウソでしょ。
403:nobodyさん
05/10/08 22:45:32
Singletonパターンってイディオムみたいな感じだよね。
確かに無理して本に乗ってる書き方通りにしなくても良いとは思う。
Javaみたいにマルチスレッド環境になることもないし。
404:nobodyさん
05/10/08 23:03:48
383の書き方だと、呼び出し側のコードを見ただけでは
それがSingletonなのかどうかは判別できないじゃん。
確かに伝統的な書き方は記述が面倒だけど、
一人の思考ではなかなか太刀打ちできない強度があるもんだよ。
たくさんの頭脳を経た思考の蓄積や時間による淘汰は馬鹿に出来ない。
405:nobodyさん
05/10/09 00:09:28
>>400
わざわざ冗長に見える記述をするのはそれなりの理由があるからで、
それが感じられないならオブジェクト指向自体が冗長だろう
ていうかSmalltalkとかRubyのほうがよりオブジェクト指向が強いと思うのだが
406:nobodyさん
05/10/09 00:13:58
冗長って何？
407:nobodyさん
05/10/09 00:26:12
>>406
君は初心者向けの本とかをたくさん読んできなさい
フレームワークスレはまだ早い
408:nobodyさん
05/10/09 01:17:58
>>400
class aClass {
function &singlton(){
static $me;
if(!is_object($me)) $me =& new aClass;
return $me;
}
}
$instance =& aClass::singlton();
これがそんなに複雑かな?
わざわざgetDB()とか$_db_とかというのをグローバルな名前空間に
つくる方が複雑化を招く気がする。
実際に作る時はこのままではなんとなく気持ち悪くてスタティックな
コールであることを保証したりしちゃうから、そういうときはたしかにphp4で
ちょっと損した気分になるね。
409:nobodyさん
05/10/09 03:49:12
PHPでのシングルトンには、「リソースを効率よく使うため」ではなくて
「意図を表すコーディング」としての効果を期待しろ、ということで。
410:nobodyさん
05/10/09 07:15:34
>>400
なんか実用的なプログラム書いた事無くて、頭の中で屁理屈こねくり回してるって印象を受けるな～
411:nobodyさん
05/10/09 07:19:12
PHPに限らずアクセスレベルなんかも、
実際に使っちゃうリスクへのヘッジというよりも
意図を埋め込む意味合いの方が強いよね。
412:nobodyさん
05/10/09 11:23:06
意図なんてコメントとして書いておけばよい。
413:nobodyさん
05/10/09 12:57:50
>400
そもそもシングルトンで重要なのは、コンストラクタを private とかにして、
オブジェクトの生成が出来る箇所を限定することの方だろ。
414:nobodyさん
05/10/09 14:48:09
↓これはシングルトン？
/**
* シングルトンとして使ってください（オブジェクトは1度だけしか生成しないでください）。
*/
class Example
{
：
}
415:nobodyさん
05/10/09 14:58:42
プログラムは改変されていくものだから、
コメントがいつの間にか嘘の説明にならないよう、
むしろ少なめ推奨がモダンな作法。
独善的持論をぶってる奴はもう少し勉強しれ。
416:nobodyさん
05/10/09 15:04:08
DB鯖がセッション用と顧客データ用と別だったりとかさー
DBオブジェクト複数接続先で使いたい時とかって割と無い？
417:nobodyさん
05/10/09 15:06:04
↑解かりづらいか、「DBオブジェクトを接続先別に複数生成したい時」と言い換え
418:nobodyさん
05/10/09 15:18:56
俺はSingletonなDBオブジェクトにコネクションコンテナを持たせてる
419:nobodyさん
05/10/09 16:51:24
>>415もまた独善的持論なわけだが。
420:nobodyさん
05/10/09 16:53:47
ﾊｲﾊｲそうだね
421:nobodyさん
05/10/09 18:16:42
あー、415のせいで荒れ始めただろ……責任とって下さい、415
422:nobodyさん
05/10/09 18:49:57
何で糞ｶﾞｷがこんなｽﾚに迷い込んできたんだ…。
423:nobodyさん
05/10/09 18:52:26 j3jR0Qvz
ままー おなかすいたー
424:nobodyさん
05/10/09 18:56:57
>>415
>プログラムは改変されていくものだから、
まあ、その通り。
>コメントがいつの間にか嘘の説明にならないよう、
確かに気をつけないと。
>むしろ少なめ推奨がモダンな作法。
いきなり妄想が入ってきました。
>独善的持論をぶってる奴はもう少し勉強しれ。
独善的持論乙
425:nobodyさん
05/10/09 19:30:17
>>424
だから勉強してから書けって言ってるだろ？
お前の浅薄な意見なんて何の参考にもならねーんだよ。
426:nobodyさん
05/10/09 19:38:21 QrQMlw6M
ソースのコメントを少なめ推奨している、モダンな作法とやらのポインタくれ。
427:nobodyさん
05/10/09 19:38:25
お子ちゃまたちは
XP（エクストリーム・プログラミング）についてなど
調べてみようね。
最近よく出版されてる軽めのプログラミング読本も
結構参考になるよ。
428:nobodyさん
05/10/09 19:39:39
底が知れたなｗ
一瞬俺の知らない技術体系が発生してるのかとおもた
429:nobodyさん
05/10/09 19:45:20
XPってコメント少なめ推奨してるのか？
430:nobodyさん
05/10/09 19:50:40
コメントなきゃ判らんコードはリファクタリング候補ってこと
量が少ないほうがいいとかモダンとか言うのはオカルトつーか誤認
431:nobodyさん
05/10/09 19:56:38
>>430
同じことを簡単に言ってるだけだろ。
まあケチつけたいだけの奴は
Singletonをコメントで実現しとけばいいんじゃねーの？
432:nobodyさん
05/10/09 20:03:13
全く違うよ。XPのレトリックが読めてない典型ﾜﾅﾋﾞｰ君じゃん。
コードとの差異が出ないようにコメントを最小化する、なんてのは
アジャイルでもなんでもないし、リファクタリングしないことが前提の
固定的な開発思想でしょ。
433:nobodyさん
05/10/09 20:07:19
ここはフレームワークについて語るスレですよ。OOPの話は↓でしない？
PHPでオブジェクト指向プログラミング
ｽﾚﾘﾝｸ(php板)
434:nobodyさん
05/10/09 20:18:50
よしフレームワークにおけるアノテーションやAOPの意義について考えようぜｗ
435:nobodyさん
05/10/09 20:29:41
>>432
あー、お前の言うことにも一理あるね。
というか、お前が俺の言葉をどのように捉えたのかは理解したよ。
言葉のツラだけ捉えればまさにオカルトという言葉が相応しいかもしれない。
世の中には言葉をそういう風に使って金儲けや愚かな事をする輩が溢れているから
ダイレクトにそう捉えられたのも無理はないと思う。
だけど俺が言いたいのはそういうことじゃないんだよ。
なんか議論がつまらない方向に発展していきそうなのでこのへんで切り上げますが。
436:nobodyさん
05/10/09 20:35:02
>>435
上の流れがあるから指摘の意義は判ってる奴は普通に判ってるだろ
幼稚な煽りで見れたものじゃないがな
437:nobodyさん
05/10/09 22:21:08
>>434
PHPでリフレクションを利用したコメントアノテーションはちょっと興味ある
言語仕様になくても無理矢理実現できるのがPHPらしいというかなんと言うか
438:nobodyさん
05/10/09 22:33:52
まあ今のとこお守りみたいなもんでコメントと大差ないけどね
439:nobodyさん
05/10/09 23:00:25
>>434
XPはコメントとかコード外のメタデータや宣言を否定するわけじゃないっつの
それがリファクタを困難にするとも言ってない
読めるコードを書けっていう当たり前のことが言いたいだけなんです
440:nobodyさん
05/10/09 23:22:19
みんな理屈はいいから結論を書いてくれよ
>>414はアリ？ナシ？
441:nobodyさん
05/10/09 23:24:45
お子ちゃまは寝る時間ですよ
442:nobodyさん
05/10/09 23:40:49
オフィシャルではアノテーション導入する気はないみたいだなあ。
やっぱりコンパイラが対応してくれないと…フレームワークレベルでは実効力に欠ける。
Maple以外でDI+AOPなフレームワークってないのかな?
443:nobodyさん
05/10/10 00:43:37
>>440
本当に理屈は要らないんだな？
ナシ。
444:nobodyさん
05/10/10 02:00:10
フレームワークのﾒﾝﾃﾅが提供してるサンプルは
どれもこれもシンプル過ぎていまいち参考にならないなぁ
もっと踏み込んだサンプルをﾁﾎﾞﾝﾇ
445:nobodyさん
05/10/10 07:29:44
議論を読んでない俺が思うのは、開発手法の議論は他のスレでやってくれということだ。
つーかガチガチのクラス使いたいならJavaでやれ。
PHPでやらなきゃならん制約があるなら新スレでも立てるろや。
446:nobodyさん
05/10/10 07:35:31
俺が思うのは
フレームワークの開発がどれも停滞し過ぎということだ。
447:nobodyさん
05/10/10 09:25:29
YAMLってJSONみたいな物？
448:nobodyさん
05/10/10 09:35:59
>>442
上にも出てたけどpok。
実務レベルでどうか知らんけど、勉強用にはとても良かった。
>>446
最近はMapleが活発になってきたんじゃないかな？
449:nobodyさん
05/10/10 10:57:46
MapleってM3のDecoratorみたいな
CompositeViewを実現する機構がなくない？
そこが俺的には痛いｯｽ
450:nobodyさん
05/10/10 11:04:05
>>447
違うね。
451:nobodyさん
05/10/10 11:09:10
>>450
どっちも汎用の構造化データ記法でしょ？
同じような物じゃないの？
452:nobodyさん
05/10/10 11:45:47
>>451
JSON と XML が同じようなものである程度には，
JSON と YAML は同じようなものだとは思うが，
一般的には「違うもの」として捉えられていると思う．
てゆーかJSONって形式としちゃ汎用とはいえ
例えばPHP→Javaのデータ転送にJSON形式使う奴なんていないんじゃないかと……
453:nobodyさん
05/10/10 11:50:50
構造をあらわすっていう超大雑把な括りに何か意味あんの?
454:nobodyさん
05/10/10 11:55:22
>>452
だがJSONはそれでいい
455:nobodyさん
05/10/10 12:03:23
>>453
意味っていうかプロトコルの一種だろ
やりとりのための約束ごととして決めておく。
絶対的な必然性はなかなかありえないから
「どっちでもいい」に落ち着きそうな気はする。
456:nobodyさん
05/10/10 13:49:15
強いて言えば
人間に読みやすく設計されてるのがYAML
JavaScriptに読みやすく設計されてるのがJSON
誰もが読みにくい代わりに高機能なのがXML
って感じかねぇ？
457:nobodyさん
05/10/10 13:54:12
確かにYAMLは人が見やすいなぁ
中庸っぽさがPHPと似てるかも
JSONも嫌いじゃないけど
458:nobodyさん
05/10/10 14:37:54
JSONは専らJavaScriptと連携するときに使う印象。
ところでMapleはPHP5には対応しないのかな？
Mapleの目指す方向からしてPHP5で書いた方がずっと楽＆適してるように思うんだけど。
459:nobodyさん
05/10/10 14:44:41
前から4で続けると明言してる
やったことないけど、5じゃ動かんの？
460:nobodyさん
05/10/10 17:11:33
っていうかつまらん議論してるならコンピュータなんて捨てちまえ！！！
別に無くてもあまり生活に困らないぞ。
461:nobodyさん
05/10/10 17:17:24
>>460
この議論がつまらんと思うなら460にはそれが良かったんだろうな
幸せな人生を歩んでくれ
462:nobodyさん
05/10/10 19:13:07
Mapleって4なんだ。
プレゼンテーション層をActionだけにしたところは共感してるんだけど
機能的にはまだMojavi系の方が厚いっぽい。
463:nobodyさん
05/10/10 19:28:10
DIってのは簡単に言うと
器だけおいておくとフレームワークが勝手にオブジェクトを
放り込んでくれるｳﾝｺﾎｳﾘﾅｹﾞ!( ﾟ∀ﾟ)つ=====o
みたいなことを言ってるのかな？
464:nobodyさん
05/10/10 19:38:53 +MnfvWOk
>>463
そんな感じかな。
465:nobodyさん
05/10/10 21:11:32
ｳﾝｺﾎｳﾘﾅｹﾞ!( ﾟ∀ﾟ)つ=====oられるために
Mapleは設定ファイルを用意、
guessworkはプロパティーを用意すると。
Actionだけを見てざっと把握できるから
その点ではguessworkがいいかな…。
466:nobodyさん
05/10/11 12:40:17
勉強してる余裕ないから、いまだにguessworkしか使えない。(´･ω･`)ｼｮﾎﾞｰﾝ
467:nobodyさん
05/10/11 18:13:27
Mojaviで
属性をメソッドから返す作法が面倒くせーと思ってたけど（プロパティー用意で良くね？と）
内部条件によって属性を変えられるメリットがあるんだな。
Mojaviは知るほどに、「よく考えられているなー」という部分がある。
468:nobodyさん
05/10/11 19:47:53 G45STU1Q
>>467
Mojaviだからではなくて、ただの情報隠蔽だろ。
469:nobodyさん
05/10/11 20:54:40
mojavi4って一応作ってるんだな
ソース見る限りでは、完成には程遠いけど
470:nobodyさん
05/10/11 21:58:17
>>468
それもあるだろうね。
ただそれだけじゃなく、コードを書くことを前提としてると思うよ。
471:nobodyさん
05/10/11 23:15:49
>>470
？？
属性をセッターゲッターで操るのはMojavi独自の実装ではなくて定石だろ？
472:nobodyさん
05/10/11 23:33:22
だな。俺もコードを書く時に「ゲッターロボ GO-!!」とか[セッターロボ GO-!!」とか言いながらやってるよ。
473:nobodyさん
05/10/11 23:34:34
単なるセッターゲッターじゃなくて
Actionにとっての設定的な項目を
メソッドの形で実装して返すのがMojavi流じゃん。
しかもプロパティーに対するアクセサじゃないから
セッターゲッターじゃないし。
設定ファイルで済むようなことを
なんでメソッド書きまでしなきゃいけないのかと疑問だったのだが、
確かに利はあるな、と思ったということ。
474:nobodyさん
05/10/11 23:35:27
利→理だね
475:nobodyさん
05/10/12 00:49:34
>>473
セッターゲッターの存在意義わかってる？
476:nobodyさん
05/10/12 02:03:55
>>475
いや当然普通に分かってるけど…。
なんかいまいち伝わらないみたいだな。
477:nobodyさん
05/10/12 10:36:29
>>476
RubyとかRailsの人のよく言う言語重要てやつのことかね。
設定ファイルなどに頼るな、言語で一回だけ書きゃいいのだ。というあの信条。
うちではJava系のひとのStrutsアレルギーでMojaviは使っていないのだけれど。
478:nobodyさん
05/10/12 15:07:00
>>181
遅レスだが
firefoxならOSXでも使えるんだね
昔はMacなんて置いてけぼりだったのに便利な時代になったなぁ
479:nobodyさん
05/10/12 18:11:38
オブジェクト指向的にSQLを組み立てられるソリューションをどなたか知りませんか？
分散DBにしたいので、DBアクセス部分はこっちで書こうと思っています。
SQLのみを書いて欲しいのですが、それに機能を限定したものが
なかなか見つかりません。
480:nobodyさん
05/10/12 23:10:35
PHPで最適なフレームワークはなに？
481:nobodyさん
05/10/12 23:23:10
一長一短で、定番はないよ。
482:nobodyさん
05/10/13 09:49:24
長所短所を比較しているところってないですか？
483:nobodyさん
05/10/14 04:53:33
>>476
いやいやわかってないってｗ
484:nobodyさん
05/10/14 07:20:42
？
分からないのはむしろ君の頭の中だが…。
そもそもがセッターゲッターの話じゃないわけで。
Mojaviを実際に使ったことあるかい？
485:nobodyさん
05/10/14 07:52:01
>>475と>>483はほっとけ
スルーしてりゃ消えるでしょ
486:nobodyさん
05/10/14 11:51:40
この板の人達はスルーすることを知らない
487:nobodyさん
05/10/14 13:55:39
技術者だから基本まじめなんだよ。
だいたいフレームワークスレで煽る意味が分からない…。
488:nobodyさん
05/10/15 13:24:45
>>487
煽る→怒った奴の中に自称女が現れる→女と証明してみろﾌﾞｻｲｺと煽る
→怒った女は、ｵｯﾊﾟｲやﾊﾟﾝﾂ写真をUP→みんな素人エロ画像にﾏｯﾀﾘ
489:nobodyさん
05/10/15 16:04:32
>>488
うむ、とても平和な流れだ。
その流れを、このスレに当てはめるとどうなるんだろう。
490:nobodyさん
05/10/15 23:57:37
ここPHPのフレームワークスレだよね。。。
いま作ってるんだけど、需要あるのかなぁ。
491:nobodyさん
05/10/16 16:16:44
>>490
既存のフレームワークより優れた点があるのなら
492:nobodyさん
05/10/16 16:30:50
既存フレームワークも大分広まってるから
あまりにも独自だと、
学習コストが比較的高くなって普及しないかもね。
かなり戦略的でないとこれから普及されるのは難しいと思う。
493:nobodyさん
05/10/17 01:25:22
>>492
今ある奴で開発がとまり気味のものとか、今あるものをベースに
進化させてくれるひとがいたら結構いいと思うけどな
494:nobodyさん
05/10/17 01:40:18
またforkふえるのか！
agaviかmojavi4に統一しようよもう。
495:490
05/10/19 19:41:56
どうも490です。
今作成してるのはHTMLﾃﾝﾌﾟﾚｰﾄをベースにF/W的なことをやろうって
感じで実装しています。
機能としてはﾃﾝﾌﾟﾚｰﾄ＞PHPの置き換えのオーバーヘッドを少なくするために
中間コードをキャッシュさせる機構や、携帯電話の絵文字変換（ｷｬﾘｱ相互変換）、
標準で使えるDBラッパー（MySQL.PostgreSQL,Oracle,SQLite)等です。
基本的には汎用クラスで動くように作ってあります。
といっても画面に出力するためにコントローラが必要ですが。
プログラム自体の実装は１クラス１モジュール扱いで、ﾃﾝﾌﾟﾚｰﾄから呼び出す
メソッドがコントロールメソッドでその中で他のメソッドを呼び出すのが
モデルメソッドみたいな感じです。んで、HTMLﾃﾝﾌﾟﾚｰﾄがViewです。
たぶんMVC的構造になっています。
クラス実装する前のスケルトン自動生成機能なんかもつけようかと
思ってます。
ﾃﾝﾌﾟﾚｰﾄ中のタグ類は専用タグを使い
条件設定(ifに相当するorやandも可とその逆の動作)タグや、
プログラムに渡すオプション値タグ、繰り返し（ループ）タグ、
絵文字変換タグなんかを組み合わせてViewを書くといった感じです。
496:nobodyさん
05/10/19 19:59:15
>>495
DBラッパーはPDO以上なん？
ＨＴＭＬテンプレートはSmarty以上なん？
497:nobodyさん
05/10/19 21:33:26
今からだとDB抽象クラスはPDOで十分だと思うけど
テンプレートは Smarty 以上である必要なんてないじゃん。
（そもそも何をもって「Smarty以上」とするのか）
Smarty は高機能で普及もしてるけど個人的には良いとは思わないし。
テンプレートエンジンとフレームワークが密に連携するってのも面白いと思うよ。
携帯絵文字は Vodafone のエスケープシーケンス使う奴がウザいね。
DoCoMo や EZweb の絵文字は比較的扱いやすいんだけど。
498:nobodyさん
05/10/19 22:21:53
絵文字変換なんていいんじゃない？
そういうアプローチのフレームワークはまだないし
499:nobodyさん
05/10/19 22:58:41
>>498
絵文字変換だけならフィルターとか掛けてやるだけじゃん
500:nobodyさん
05/10/19 23:18:29
>>499
絵文字はSJISでテンプレートとかDBはEUCJP推奨だから、特にsmarty使うとき色々面倒
501:nobodyさん
05/10/19 23:35:39
iMode/EZwebの絵文字はSJISの私用領域を使ってて、PHPならSJIS-win/eucJP-win/UTF-8 で相互変換可能。
端末が表示できるのはSJIS(-win)だけだけど、ちゃんと変換してやれば途中の処理を eucJP-win/UTF-8 でやっても大丈夫。
あと最近はUTF-8でも（EUCは知らない）携帯キャリアのゲートウェイがSJISに直してくれるっぽい。
とりあえず基本的な絵文字が見られればいいってことなら、EZweb/Vodafoneの絵文字を
iModeの絵文字に変換しておくのがいちばん簡単かな？
iMode絵文字なら他のキャリアでもゲートウェイが端末に応じた絵文字に変換してくれるし。
502:nobodyさん
05/10/20 03:09:08
>>500
smartyを使いこなせていない予感。
503:500
05/10/20 03:16:14
>>502
むしろ使うためにsmartyをハックした
504:nobodyさん
05/10/20 11:28:03
>>503
スーパーハッカーこわー
505:nobodyさん
05/10/20 20:20:44
絵文字変換なんかまさにフィルターの仕事。
506:nobodyさん
05/10/22 00:38:22
ドコモの絵文字をDBに入れるときどうすればいいの？
EUCに変換したら消えちゃうよね？
DBをSJISにするの？
507:nobodyさん
05/10/22 02:52:18
URLﾘﾝｸ(itpro.nikkeibp.co.jp)
Zendが「Zend PHP Framework」なるものを作ってるとのこと。
最終的にはこれに収斂されるのかな。
508:nobodyさん
05/10/22 10:02:06
>>506
絵文字を入れたいタプルをBLOB型に設定してBINARYフラグを有効にする
509:nobodyさん
05/10/22 14:03:08
>>508
そんなことしてオーバーヘッド大丈夫なの？
少量ならそりゃ大丈夫だろうけど、全文検査とかどうよ？
postgresqlのsjisパッチあてるとかは？
510:nobodyさん
05/10/22 18:35:14
>>506
俺は文字参照に変換してる。
511:nobodyさん
05/10/22 20:53:13
CakePHPのソースを漫然と眺めていたんだけど、その語尾の特殊変化の設定ファイルに
penisとtestisがあったよ。これで下品なソースでも安心だね。アダルトサイトにも最適。
でもこれいいわ。なんて言うか、流れに身を任せればとても楽。コンパクトだから見通しもいい。
それにやっぱり死にかけのプロジェクトよりも生きのいい方がいいしね。
512:nobodyさん
05/10/23 02:30:29
>>511
>語尾の特殊変化の設定ファイル
なにそれ
513:nobodyさん
05/10/23 02:34:17
>>510
？xA0; みたいなやつ？
他キャリアのつもみんなドコモのやつに置き換えるの？
てか、フレームワークすれでこんなこと聞いてすまん。
514:nobodyさん
05/10/23 06:55:11
cake
515:nobodyさん
05/10/23 16:59:56
>>512
cakeはRails系なので、規約は設定に勝るっていう哲学で作られてる。
たとえば、Userというモデルが対応するテーブルはUsers決め打ちになる。
だから、特殊な場合の変化形を自前でもっとく必要がある。
もちろん、大抵の規約は上書きすることができるけど、それだとcakeの意味がないしね。
516:nobodyさん
05/10/23 20:58:51
>>507
JavaのJakartaプロジェクトみたいなものかな。
今後の標準になるようなものを作って欲しいなぁ。
517:nobodyさん
05/10/23 21:58:24
>>516
Zend自身が乗り出してるから標準を目指してるんだろうね
これをふまえて今の草の根フレームワークはどう動くんだろ？
Mojavi4は完成するのか…
518:nobodyさん
05/10/23 23:50:08
>>517
Zendはどうせ金になるエンタープライズ領域しか目に入っていないだろうから
既存のフレームワークとは競合しないような予感。
あとは、ZendStudio必須とか、余計なことしちゃいそう。
519:nobodyさん
05/10/24 00:45:36
>>518
たしかに余計なことしちゃいそう
よく考えるとZend提供のPHP関連サービスに
いい評判はあまりないもんなぁ。
520:nobodyさん
05/10/24 03:51:45
URLﾘﾝｸ(www.symfony-project.com)
mojavi + rails = symfony
てか、もう迷うのも面倒なんで
そろそろ定番出てきてﾎｽｨ…
521:nobodyさん
05/10/24 04:36:42
定番を望むのもわかるけど、
何でもできる＝どれも中途半端な性能
てことが往々にしてあるので、すきなの見つけて自分で
進化させていくのがいいかも。
できればsourceforgeとかつかってｗ
522:nobodyさん
05/10/24 15:04:10
Zend PHP Framework
あれどうなってんの？
523:nobodyさん
05/10/24 15:04:59
>>519
Smartyとか？
524:nobodyさん
05/10/25 10:38:07
SmartyってZend発？
525:nobodyさん
05/10/25 12:33:45
違うと思う
526:nobodyさん
05/10/25 22:39:29
まぁZendの事だから、期待出来ないな。
今までノータッチだったけど、Ethnaって良さそうだなぁと思い、
本家のML見て見てみたら、ら○じぃがいるじゃねぇかよ。
あいつ嫌いなんだよな・・・。
坊主憎けりゃ・・・じゃないけど、なんかEthnaやだなぁ・・・。
藤本神は好きなんだけどなぁ・・・。
527:nobodyさん
05/10/25 23:01:50
そんなこと言うもんじゃありません
528:nobodyさん
05/10/25 23:04:45
URLﾘﾝｸ(netevil.org)
ｱｸﾚｺｷﾀｺﾚ
529:nobodyさん
05/10/26 07:10:19
ZendのFrameworkはお布施用にきまってるだろ
530:nobodyさん
05/10/26 08:56:51
いやフレームワークでは金は取らないじゃないか？
531:そりゃないか
05/10/26 09:23:36
Zend Framework Lite 無料
Zend Framework Enterprise 有料
532:nobodyさん
05/10/26 14:00:18
DB周りのコンポーネントとか有料かもな
533:nobodyさん
05/10/27 03:34:49
Zend Studioお布施済みの俺としては、Studio対応で無問題。
534:nobodyさん
05/10/28 21:50:40 geHxPjMK
Mojaviで
モバイル/PCの分岐はどこでどんなふうにやってる？
535:nobodyさん
05/10/29 01:43:09
>>534
やったことないけど、フィルタでforward分けしたらいいんじゃない？
536:nobodyさん
05/10/29 02:16:56
>>534
なにを目的として分岐をするかによる。
機能を分けたいならActionを分けるだろうし、
表示を分けたいだけならViewだろう。
537:nobodyさん
05/10/29 13:30:02
Mojaviのフィルタって好きなだけ作れるけど
プリフィルタしか使わない場合とかポストフィルタしか
使わない場合とかってある？
538:nobodyさん
05/10/29 23:44:53
それはよくあるでしょ。
539:nobodyさん
05/10/30 11:03:38
agavi api 日本語訳
URLﾘﾝｸ(www.geocities.jp)
540:nobodyさん
05/10/30 11:22:35
>>539
乙
541:nobodyさん
05/11/01 22:33:59
php5のひとはどのフレームワークつかってんの
agaviとか？
542:nobodyさん
05/11/01 23:23:56 D/XKY8a/
Mojavi3を使っているんだけど、
複数のActionから共通のViewを呼び出すにはどうするのが綺麗なやりかただろう？
543:nobodyさん
05/11/01 23:39:42
>>542
Actionでarrayかえせばええやん
544:nobodyさん
05/11/02 01:36:57
MojaviはActionとViewが
ｲﾁｲﾁで対応してるからどうやってもトリッキーになりそうだな。
俺はViewを分けるほどのことないだろと思ってｵﾘﾌﾚ作ったけど。
ViewHelperの仕込みとか結構ごちゃつくから分けてもよかったかもと
思ったりもする。
545:nobodyさん
05/11/02 01:46:12
>>544
日本語変。
546:nobodyさん
05/11/02 18:54:03
>>543
ActionでArrayをかえすってどういう具体的にどうすること？
547:nobodyさん
05/11/03 02:43:18
＊＊＊ すべてのPHPユーザーに告ぐ ＊＊＊
URLﾘﾝｸ(www.hardened-php.net)
URLﾘﾝｸ(www.hardened-php.net)
URLﾘﾝｸ(blog.ohgaki.net)
PHPに深刻な脆弱性がある事が発表されました。今まで見つかったPHPの脆弱性の中でも「最悪」の脆弱性です。全てのPHPユーザは今すぐ対処を行う必要があります。
548:nobodyさん
05/11/03 12:11:06
>>546
俺も意味が分からなかった
549:nobodyさん
05/11/03 13:09:55
>>546
Mojavi3ではActionの戻り値として、
第一要素がモジュール名第二要素がビュー名の配列をかえすことによって、
遷移先を指定できる。
550:nobodyさん
05/11/03 16:33:22
>>549
そうなんだ
そりゃ便利だね
551:nobodyさん
05/11/04 23:32:52
テンプレートエンジンをSmarty-lightにしてる人いる？
Smartyとほとんど変わらず使えて、しかも軽くなるなら、
結構お得だと思うけどどうなんだろう。
552:nobodyさん
05/11/05 00:49:33
おいagavi使ってるやついるか
553:nobodyさん
05/11/05 02:20:18
10分で作るCakePHPアプリ for Windows - p4life
URLﾘﾝｸ(p4life.jp)
cakeってここまでやってくれるのか・・・
554:nobodyさん
05/11/05 21:01:35
>>553
それだけ見ると Rails と変わらないよね
555:nobodyさん
05/11/05 21:21:51
簡単すぎて不安になるな
鯖一つで収まるようなｼﾝﾌﾟﾙなアプリにはかなり最強かも…
556:nobodyさん
05/11/05 21:37:15
つーか、rubyの勢いはマジですごい。
557:nobodyさん
05/11/05 21:47:05
海外の連中はそのうち業を煮やして、Rails 用の Ruby を
fork させそうな勢いだよな。
558:nobodyさん
05/11/05 21:49:19
ﾜﾛｽww
559:nobodyさん
05/11/05 23:42:35
EthnaでPEAR::DBじゃなくてADODBって使えるのかな？
560:nobodyさん
05/11/05 23:55:13
>>559
Ethna 専用ｽﾚがあるよ
【PHPフレームワーク】Ethna【スケルトン自動作成】
ｽﾚﾘﾝｸ(php板)l50
561:nobodyさん
05/11/05 23:59:23
>>560
お、サンクス。
ちょうどその辺りの話題のレスがあるね。
562:nobodyさん
05/11/06 01:02:45 1KuwxXQW
S2PHP使ってる方いますか？
どんな感じでしょう。
563:nobodyさん
05/11/06 11:37:34
>>562
流石に仕事に使ってる人はいないだろうね。
触った感じは面白いよ。上の方に出てたpokﾌﾚとして。
まぁ当然まだまだなんだけど、将来はかなり楽しみ。
564:nobodyさん
05/11/06 12:29:44
Mojaviの
index.php/param/value/param/value
形式のURIってmod_rewriteとの併用前提なんだね。
間にindex.phpがまるだしでﾀﾞｾｰURLになるなーとｵﾓｯﾃﾀ…
565:nobodyさん
05/11/06 16:28:01
>>564
ソースは？
566:nobodyさん
05/11/06 19:17:49
>>564
mod_rewrite使わなくても、index.phpに相当するファイルをForceTypeしちゃえばいいと思うよ。
567:nobodyさん
05/11/06 22:26:13
>>564
別に mod_rewrite 前提ってわけじゃないっしょ。
568:564
05/11/07 05:38:11
>>565
そうじゃないかな？と思っただけでソースはないよ
>>566
（入口）URLﾘﾝｸ(hoge.com)
(出口）URLﾘﾝｸ(hoge.com)
これをForthTypeでやるにはどうすればいいの？
考えてもいまいち分からなかった
>>567
まあ検索エンジン対策という意味では
index.phpがあってもなくても関係ないからなぁ
569:nobodyさん
05/11/07 10:02:24
path_info形式にすると
ブラウザがドキュメントURLを誤認識するのが面倒くさいね
リンク全部絶対URLにしなきゃならんのか。
570:nobodyさん
05/11/07 10:39:05
>>564
(入口）URLﾘﾝｸ(example.com)
(出口）URLﾘﾝｸ(example.com)
は無理だけど、
mv index.php hogehogeして、
(入口）URLﾘﾝｸ(example.com)
ならどうよ？
571:nobodyさん
05/11/08 00:44:57
PHPプログラマーズマガジンで Seagull ってのが紹介されてるね。
立ち読みしか読んでないけど。
これ、フレームワーク？ CMS?
572:nobodyさん
05/11/08 03:42:16
>>570
さんくす。
よくよく考えたら、mod_rewriteでindex.phpを無条件にはさむと、
他のファイルへのアクセスに支障が出るから、
そういう方法しかないかもしれない。
573:nobodyさん
05/11/09 02:42:24
URLﾘﾝｸ(longinus.org)
初めて見たんだけど、これの中ちゃんと読んだことある人いる？
574:nobodyさん
05/11/09 09:10:03
>>573
ぱっと見Mojavi系と似てるね
デフォルト拡張子がincなのはセキュリティー上
推奨できないと思う
575:nobodyさん
05/11/09 09:21:44
フレームワーク大杉
576:nobodyさん
05/11/12 16:50:24
Synfony勢いとかサイトのクオリティーで抜きん出てる気がする
これからはこれか？
577:nobodyさん
05/11/12 17:07:53
Symfonyのムービー見たらテンプレートにphp生書きで、
しかもテンプレート中から$user->getAttribute()とか平気でしてる。
最近Smartyみたいなテンプレートエンジンの
意義みたいなものに疑問を感じてきた俺には示唆的だった。
実際テンプレートエンジンから
独自文法の解釈外したら馬鹿みたいに短いコードで書けるんだよね。
もともとPHPはob_系関数があってキャッシュの実装なんかも
やろうと思えばすぐ出来る環境だし。
578:nobodyさん
05/11/13 01:22:28
デザイナーにはHTMLを触らせず、cssだけいじらせる時代になってしまえ
579:sage
05/11/13 08:33:59 nNKS4KNy
>>578
当方デザイナ（つーかコーダかな）ですが、それ大いに賛成です。
開発者からページに掲載するデータの定義だけ教わって
あとはxhtml＆cssと格闘するみたいな。
もしくはxhtmlの出力フォーマットだけもらってもいいや。
tableタグ使ったレイアウトに決別すると、
どうしてもそういう方向になってくる気がします。
580:nobodyさん
05/11/13 09:24:35
もう一歩進んでhtml作るときにtdiary互換のcssを参照するようになったりしたら、
webデザイナーの仕事が減っちゃうかもしれないよ?
でも、むしろその方が本来のグラフィックデザインの実力で勝負できていいのかな。
581:nobodyさん
05/11/13 17:30:56
おまいの作るhtmlは、えらく目的が限定されとるな。
582:nobodyさん
05/11/14 02:43:58
php5なんだけど、何がおすすめ？
583:nobodyさん
05/11/14 11:50:11
これは既出？
URLﾘﾝｸ(www.pm9.com)
何でもいいがFirefoxでもちゃんと見れるように作ってよ・・・orz
584:nobodyさん
05/11/14 12:29:09
ドキュメントとかしっかりしてるみたいだけど，
商用ライセンスってのが・・・
585:nobodyさん
05/11/14 14:49:17
>>583
■クラスタリング
高負荷サイトの為のWebサーバ、DBサーバの並列化に対応しています。
これが気になるなー
ちょっと見てみようかな
586:nobodyさん
05/11/14 21:59:02
>580
tdiary互換のcssって...なんでtdiaryなの？
587:nobodyさん
05/11/15 01:06:37
tDiaryのテーマを変えて喜んでるだけの厨房だから
588:nobodyさん
05/11/17 09:26:30
mojavi2ってsession_destroyは手動でやるしかない？
589:nobodyさん
05/11/19 15:36:29
Symfony見たらActionにショートカット用メソッド
（getRequestParameterとか）付けてたから俺もそうした。
何か綺麗さが損なわれるような気がしてﾔｾ我慢してたけど。
590:nobodyさん
05/11/21 03:01:02
mojaviを勉強しはじめました。
参考になるソースを見ようかなと思うのですが、お勧めのオープンソースなものって
ありませんか?
できればmojavi2系
できれば、smartyとかadodbとか使ってたり
携帯の処理なんて書いてあるとさらに素敵です。
591:nobodyさん
05/11/21 22:25:36
cakePHPってデータベース絡みには結構よさげだけど認証や権限関連が弱いな
592:nobodyさん
05/11/21 23:12:08
mojaviでFPDF使っている人いる？
なんかIEで表示されないんだけど、原因は何？
593:nobodyさん
05/11/21 23:14:05
>>592
あんたもか！漏れもだわ。
594:nobodyさん
05/11/22 00:24:11
>>592
あぁ、それIEのバグ
対処法はいくつかあるけど
595:nobody
05/11/22 12:19:16
mojaviの外に出たら、うまくいった。
596:nobodyさん
05/11/22 12:52:15
view_noneじゃなくてexitすると動くことがある
597:nobodyさん
05/11/22 16:52:59
>>591
Controller の beforeFilter と PEAR::Auth を組み合わせればカンタン。
aclがいらないなら5行もあればできる。
でも、組込み認証の是非に関する議論は一応やってたと思う。
個人的にはこれ以上Controllerは太らないで欲しいんだけど...
598:nobodyさん
05/11/22 19:29:40
>>597
早とちりかな？
認証はともかくとして、権限をどうやってPEAR::AUTHで簡単に？
五行のコード載せてみて
599:nobodyさん
05/11/22 20:31:33
> aclがいらないなら
acl = 権限ジャマイカ？
600:nobodyさん
05/11/22 20:39:40
>>594
対処法キボンヌ
601:nobodyさん
05/11/23 15:11:58
>>598
権限 = acl のつもりだったんだけど、どうしてもAclが欲しいなら今でもMyAclを使える。
うろ覚えで書くとたとえばこんな感じのメソッドをAppControllerにでも追加すればいいはず。
beforeFilterに_aclCheck、componentsにはMyAclを追加してね。
function _aclCheck(){
$this->auth =& new Auth(...);
$this->auth->start();
if(!$this->MyAcl->check($auth->getUserName(),
$this->params["controller"]."/".$this->params["action"]))
$this->_permFailed();
}
たぶんこのままでは動かんと思うけど、流れは大体こんな感じ。
権限不足画面などのViewを含めると5行はハッタリだったね、慌てさせてごめんよ。
nightlyにはさらに高機能なdbAclもあるらしい。
602:nobodyさん
05/11/24 22:26:05
agavi で DBに接続したんですけど、下記
$db = $this->getContext()->getDatabaseManager()->getDatabase()->getConnection();
クエリーを発行するにはどうしますか。
MySQLDatabase.class.phpにはメンバー関数がないようだし。
603:nobodyさん
05/11/25 14:25:00
MVCのModelにあたる部分は、Mojaviで言うとどの部分になるのでしょうか?
actionsでしょうか?
処理の部分をどこに書けばいいのかがわからなくて困っています。
MVCの記事をかなり読んだのですがどの部分がModelなのかちょっとよくわかりませんでした。
604:nobodyさん
05/11/25 14:28:18
>>602
よくわからんけどたぶんmysql_queryでやるんじゃん？
>>603
MojaviにModelあるけど
ActionはMVCのC
605:nobodyさん
05/11/25 14:37:14
Action内から呼び出す自作またはModelをextendsしたクラスあたりと思っていればよいかと。
606:nobodyさん
05/11/25 15:44:35
おいおいお前ら正気か
CってControllerのCじゃないんかよ
ビジネスロジックを担当するんだからActionクラスはModelだろ
それとももっと違う次元の話か？
607:nobodyさん
05/11/25 16:00:45
Action内でビジネスロジックを実行する場合はAction=M
Actionから一層掘り下げてModelを呼ぶ場合は
Action=Cになるんじゃないの？
前から思ってたがあまり峻別できない概念だよな。
MVCがお互いを包摂し合ってる部分がある。
音楽のジャンル分けみたいなもんだな。
厳密な区分が最初からあるわけじゃない。
608:606
05/11/25 16:09:51
なるほどね
まあ確かにそう使う場合もある罠
もともとWebｱﾌﾟﾘの世界の話じゃないしな、曖昧になるのは仕方ないというかなって当然
そういう意味ではDBの設計と似てるところがあるかな
MVCにとらわれすぎてクソな実装かますのが一番ダメダメ
つーか実際書き始めるとMVCとか結構どうでもよくなってくる
設計段階での指針程度にとどめておくべきだろうな
609:nobodyさん
05/11/25 16:20:05
結論
>>603
MVCとかどうでもいいからまず動くように書いてみろ、話はそれからだ
どうしても気持ち悪ければあとでいくらでもリファクタリングするよろし
その過程でだんだんMVCになることもあればそうでない場合もある
っつーのが本質だと思うんだな俺は。
610:nobodyさん
05/11/25 17:24:45
なるほど勉強になりました。
明確な区別はないんですね。
実はもうコーディングをしててformsの下とかviewsの下にもロジックを書いたりしていて
多分違うんだろうなぁ～と思って聞いてみました。
VIEWを返しているあたりは、action=Cと思ったんですけど、その前に処理を書こうかなと
思います。
formsはどこに当たるかといったら、まぁModelと考えておけばいいですかね。
そういうことがナンセンスなのかもしれませんが。
611:nobodyさん
05/11/25 21:04:56
PHP5.1.0リリースだというのに静かなものだね・・・。
俺が思うに、ある程度知識がないとMojavi使いきれないと思うよ。
とりあえずMojaviでいうＶｉｅｗが必要ないフレームワークにしてみたら？
612:nobodyさん
05/11/26 01:25:15 a7zffmpw
mojavi2.0を使っています。
URLﾘﾝｸ(www.stackasterisk.jp)
ここを参考にディレクトリ構造を変えたのですが、
レンタルサーバでhtdocsをベースに指定する事って出来るのでしょうか？
613:nobodyさん
05/11/26 04:50:35
そんな解決はできても難しいし、やるべきじゃない方法だよ。
多分、フレームワークの理解を根本的に間違えてるんじゃないかな。
DocumentRootにindex.phpを置いて、外部からアクセス禁止してる箇所にmojaviフォルダとwebappフォルダを置く。
あとはpath調整して動かすんだよ。
614:nobodyさん
05/11/26 08:50:15
そうそう
わかんないうちはとかくなにもかもマニュアルの通りにしないといけない、と鵜呑みにしがちだけど、
少し冷静に考えてみるとどうでもいい事なんてたくさんあるぜよ。
つーわけでindex.phpはどんな名前のディレクトリにあろうがブラウザから参照できる位置に置くべし
まーほとんどのレン鯖の場合public_html以下に適当な名前のディレクトリ作ってほりこんでるんでないかね。
615:nobodyさん
05/11/26 10:50:33
mojaviで "class IndexAction extends Action"のようにIndexでactionを指定しても
"URLﾘﾝｸ(xxx)"とわざわざ書かないと
Only variable references should be returned by reference と怒られてしまって困ってます。
環境は
PHP 4.4.1-pl1
mojavi 2.0.3 beta です。
616:nobodyさん
05/11/26 11:21:14
それは困りましたね＾＾；；；；；
617:615
05/11/26 11:41:56
すみません、解決しました
618:nobodyさん
05/11/26 12:33:18 2543W0TM
>>617
最近流行ってるね
619:nobodyさん
05/11/26 13:54:07
>>618
よくわかったね
620:nobodyさん
05/11/26 14:23:28
>>619
スキだからさ
621:＼＿＿＿＿＿＿＿＿＿／
05/11/26 15:15:03
Ｖ
＿＿＿＿_
／::::::::::::::::::::::::::＼
/::::::::::::::::::::::::::::::::::::::＼
|:::::::::::::::::|＿|＿|＿|＿|
|;;;;;;;;;;ノ ＼,, ,,／ ヽ
|::（ 6 ー─◎─◎ ）
|ノ （∵∴ （ o o）∴）
／| < ∵ ３ ∵>
::::::＼ ヽ ノ＼
:::::::::::::＼＿＿＿＿＿ノ:::::::::::＼