07/07/03 19:01:16
>>173
俺FWはSymfonyしか使ったことないんだけど、DBからデータ持ってくるのは
やっぱりSQL文直書きしちゃうなぁ・・・。
SQL書かないと、後で見たときすごい解りにくくない？
でも、SQL文がPHP内に混じるとやっぱり汚いね。
PHP版S2Daoの、2way SQLが良さそうなんだけど、時間ないのでまだ見れてない。
includeするファイルが多くなり過ぎて、Symfonyと併せるとすっごい遅くなりそうな気もする。
そうなると、CIと組み合わせた方が良いのかな？
176:nobodyさん
07/07/03 23:05:23
ちょっとややこしくなると、結局同じようにややこしかったりするし、
SQL自体がそもそも簡便に抽象化されたものとしてあるんだから、
プレースホルダを使ったりするくらいでも別にいいよな。
177:nobodyさん
07/07/03 23:33:46
同意。
無駄にプァイル多くなるし。
あとから参照しずらい。
178:nobodyさん
07/07/04 00:02:35
まあCIのactive recordは使い物にならんから、SQLガチガチ書きたい奴はある意味お勧め。
179:nobodyさん
07/07/04 00:15:23
>>178のカキコも使いもんにならんから目を汚したいヤツには違う意味でお勧め。
180:nobodyさん
07/07/04 03:43:53
情報出さないで文句ばっかいってる生産性のないやつがいるな。
>>175
Symfonyは使ったことないけど、Cakeの方がシンプルだということだからもっとみやすいんじゃない？
Cakeは慣れれば、一目見ただけでどんなデータとってきてるか分かるよ。
SQL文書くならRailsを模倣してるSymfonyとかCakeとか使わないで違うＦＷ使うべきなんじゃないかと思うけど。
181:nobodyさん
07/07/04 09:20:11
Cakeとsymfonyやったらどっちのほうが覚えやすい？
182:nobodyさん
07/07/04 13:18:56
railsはDB操作レイヤーといえばORMというような、間違った風潮を作ったね。
183:nobodyさん
07/07/04 13:20:14
一見コード量から言えばCakeの方が「覚えやす」そうだけど、
symfonyの方が業務にすぐ使えるだろうね。
「覚える」ことは必要ないし。マニュアルにしたがってサクサクという感じで進むよ。
それと引き換えに「退屈さ」に耐えなければならない、という感じ。
横道にそれながらも楽しんで仕事したいならCake。
184:nobodyさん
07/07/04 14:51:32
>>181 業務ならCake 趣味ならSymfony (Cakeは4,5対応ということだけで、別に悪意はないから)
185:nobodyさん
07/07/04 17:50:11 PWYSy+4p
退屈な方がいいよね
186:nobodyさん
07/07/04 19:11:13
ああ、そう思う。仕事はそういうもんだな。
187:nobodyさん
07/07/06 02:47:18
>>184
逆だな。
今更4なんて実用に耐えないから、両対応にして精度落としてるcakeは趣味にしか使えん。
188:nobodyさん
07/07/06 04:09:17
精度なんか落ちてないぞ。4と5に対応できるようにコードを裏側で切り替えてるだけ。
普通に優れてる
189:nobodyさん
07/07/06 09:49:02
>>187
精度って何の精度？
190:nobodyさん
07/07/06 09:59:30
業務でSymfony使えばいいじゃない。 使いたい人は・・・。
191:nobodyさん
07/07/06 10:00:04
むしろsymfonyが趣味にしか使えないというところに、突っ込むべきかと。
ありえんだろ。
192:nobodyさん
07/07/06 10:17:04
symfonyは趣味にはキツいな。どんなマゾやねん
193:nobodyさん
07/07/06 20:14:10
〉189
性能といいたいのだと思われ
194:nobodyさん
07/07/06 22:44:53
趣味でやるなら、cakeかEthna。
仕事はsymfony。
仕事ならサーバー構築からできるからphp5を選択できるけど、趣味だと安いサーバーを借りたりするので
php4で動くやつの方がいい。
195:nobodyさん
07/07/06 23:27:00
>>194 のような趣味のような仕事をしてみたい。
196:nobodyさん
07/07/07 05:07:04 1nTQ87n9
まず趣味で色々使ってみる。
そして自分なりのFAを出す。
それを仕事の現場で推薦する。
通らないこともあるが自分はこうしてる。
「2chで支持されてたので、これ使います。」
じゃまずいだろ。ｗ
197:nobodyさん
07/07/07 06:05:50
URLﾘﾝｸ(www.symfony-project.com)
ﾌﾗﾝﾁｮｽ「PHP4 is dead! いまどきPHP4にも対応してる中途半端なCakeはﾌﾟｷﾞｬｰものだ」
198:nobodyさん
07/07/07 08:49:30
正直、symfonyは機能をあれこれ盛り込んでるから
そこそこ利用出来るようになるまで時間が掛かりすぎる & ソースが見難い。
199:nobodyさん
07/07/07 10:08:07
>>198
よくそういう意見を聞くけど、まずは自分が使いたいと思う機能だけ
使っていけば、複雑でも何でもないんじゃないかと思うんだが、どう？
ソースについても、Cakeの方が汚いと聞いた事はあるが、確認はしてないなぁ。
あ、見難いと汚いは違うか？
200:nobodyさん
07/07/07 10:13:33
うん、むしろ、なにも考えずに使えてしまうよ。
symfonyに実装されてる機能を「そこそこ利用できる」学習する時間
＜Cake（とかCIとかライトウエイトのＦＷ）を使って自作点検する時間
って感じだから、symfonyは「退屈」なのよ。でもそれくらいならsymfony
よりは今後はＺＦ使いたい気がする。
201:nobodyさん
07/07/07 11:01:17
ZFはあんだけ時間かけてあのザマだからなあ
202:nobodyさん
07/07/07 11:10:13
ん、ZFわるくないじゃん。機能もそろってるし。
どこが「あのザマ」なの？
203:nobodyさん
07/07/07 11:30:41
ZFがJAVAライクなフレームワークになってるのも分からず、叩きたがってる中二病なので、ご勘弁ください。
204:nobodyさん
07/07/07 11:32:56
ZFはフレームワークって言うより
ライブラリ感が強いから
自前で用意しなきゃいけないことが多い
ソースは読みやすい
205:nobodyさん
07/07/07 11:45:21
symfonyあたりからZF見て足らないっていう部分が、
本当にＦＷの必須要素なのかが疑問だけどね。
206:nobodyさん
07/07/07 12:53:56
別にsymfonyを叩きたいわけじゃないがsymfony信者多いな
207:nobodyさん
07/07/07 13:00:32
PHP4って今でも多くのサイトで使われてるだろ。
PHP5はメモリを食いすぎるからね。
シンフォニーみたいな高機能なフレームワークはエクステンション化しないと実用的でないね。
208:nobodyさん
07/07/07 14:28:41
> PHP5はメモリを食いすぎるからね。
具体的な数字希望
209:nobodyさん
07/07/07 15:16:07
海外国内問わずPHP4互換のFW未だにアップデートし続ける
FWの作者に告ぐ、はっきり言って老害だ、とっとと辞めてくれ
少しでもPHPの未来を考える気があるなら
そのサポート対象から4を切れ、今すぐに
そしてその4互換FWで未だに4のコードを書きつづけるユーザの人達、
4のコードでそのFWの使い方やサンプルをブログに書きつづける人達、
5のサポートをしないレンタルサーバ管理者の人達、
どうか心改めこれから5をインストールして5のコードを書くか
PHPを捨て去るかどちらかを選択して欲しい
これ以上4のコードを生産するべきではない
これ以上4のコードを書く人間を生産するべきではない
これ以上4のコードを書く人間を放置していてはいけない
PHPユーザは尊厳の意をもって4を葬り去るべき
210:nobodyさん
07/07/07 15:51:51
>>209
4のコードはたいがい5でも動くだろ・・。
5を普及させたいなら、レンサバ屋に5を入れるように頼んどけ。
そして君は自分の愚かさを自覚してもっと謙虚になりなさい。
211:nobodyさん
07/07/07 15:57:10
仕事であの中途半端なオブジェクト指向をさわりたくない。
212:nobodyさん
07/07/07 16:45:01 ORHn68Tc
PHP5は最近レンサバでも入ってるよ。
ってか、最近は最悪でもVPS以上を使わせることにしてる。
213:nobodyさん
07/07/07 22:00:26 9N+o65yz
最近symfony使い始めて、掲示板なんか試しにつくってみたけどさ、
設定ファイルでだいたいの調整ができるから、実際のビジネスに使う
には、結構いいんでは？
ビジネスでは、スピードよりも保守性が重んじられることも多いから…。
214:nobodyさん
07/07/07 22:12:49
そうね。
何年も保守していくことを考えると、今さらphp4 てどうだろう。。
ていうか数年先にphpはどうなっているんだろうか。
215:nobodyさん
07/07/07 23:46:32
php6でまた仕様が変わってうんざりしてrubyに
216:nobodyさん
07/07/08 01:50:14
ruby 2 で仕様が変わってうんざりして pythonに
217:nobodyさん
07/07/08 01:55:49
一方perlはのんびりと静かに暮らしていた
218:nobodyさん
07/07/08 03:09:35
>>214
そもそもweb業界なんてリアルタイムで変わるものなんで
数年先なんて考えるだけ無駄。
219:nobodyさん
07/07/08 05:34:20
209の駄文にワラタ(笑)
220:nobodyさん
07/07/08 12:19:25
PHP4 is dead, long live PHP5!
221:nobodyさん
07/07/08 12:22:42
次のPHPにレキシカル変数、パッケージが導入されない限り、軽いPHP4で十分だな。
222:nobodyさん
07/07/08 13:46:19
php4が軽いとか思ってる奴まだ居たんだ…
223:nobodyさん
07/07/08 15:11:30
軽いPHP4で十分だよ！
224:nobodyさん
07/07/08 15:53:46
>>222
php4が軽いとか思ってるのではなく、軽いPHP4で十分なのではないか？
225:nobodyさん
07/07/08 16:23:47
じゃあ軽いPHP5でいいじゃん
226:nobodyさん
07/07/08 19:31:40
>>208
ペチパーは自分で調べることが出来ないのかねえ。
↓これでPHP4と5で計ってみろ。
ps -eo vsz,command | grep httpd | awk '{sum+=$1}END{print sum}'
PHP5はこのでっぷり太ったプロセスでHTMLも画像も処理しないといけないんだ。
もっともYahooみたいにモジュールを全部外してコンパイルすれば4も5もそんなに違わないのかも。
が、ビジネスロジックをエクステンションに任せるというのは極めて例外的なPHPの使い方だから参考にならないな。
227:nobodyさん
07/07/08 20:40:27
おまえら4と5の負荷の差がボトルネックに感じる程の
WEBアプリを作ってんのかと小一時間問い詰めたい
例外処理とマジックメソッド使えるだけでも
どれだけ開発が楽になって生産性上がると思ってんだよ
微々たるPHPのバージョン差の負荷とか考える前に
自分が開発するためのフットワークを
軽くすることを先に考えるのがプログラマだろうが
228:nobodyさん
07/07/08 21:12:47
富豪的発想が主流になるのはまだまだ先ってことだね。
目の前の負荷を軽くすることが優先されて、
それに割く労力を別の改良に振れるのに気づけない。
229:nobodyさん
07/07/08 21:20:14
>>226
バージョンで要求される標準モジュールがコンパイル時に違うのにあれこれ言うお前こそばかだろ
230:nobodyさん
07/07/08 22:37:30
ウェブアプリが複雑であるかそうでないかは関係ないよ。静的なHTMLでも画像でも同じこと。同じApacheを使うんだから。
むろんJavaのコンテナやfastcgiのように独立したアプリケーションサーバを用意して、ウェブサーバと分離できればいいんだが、そのコストがPHP5導入のメリットに見合わないつーこと。
バージョン3から4、4.xは順調にリプレースされていったのに、どうして日本でも海外でもPHP5への移行が進まないのか。
それは、確かにVistaには目新しい機能があるが、重くてバギーだし、XPは安定していて困ることはないよ。っていうのと似たような話。
231:nobodyさん
07/07/08 22:45:45
パーソナルユースのOS話しと業務ベースのPHP導入の話しとを一緒にしてるってのが輪をかけてバカ
232:nobodyさん
07/07/08 23:22:56
> バージョン3から4、4.xは順調にリプレースされていったのに、どうして日本でも海外でもPHP5への移行が進まないのか。
すごーーく単純な理由で、
ひとつのapacheで共存できないから。
重いから5にしないって話はほとんど（皆無ではない）聞かないね……
233:nobodyさん
07/07/08 23:33:37
PHP4 is dead ＝ PHP is dead
ｵ､ｵ、ｵﾜﾀｰｵﾜｵﾜｵﾜﾀｰ♪
＼ PHP is 全部 dead♪／
♪＼(^o^) ♪
＿ ) > ＿ ｷｭｯｷｭ♪
／.◎。／◎｡／|
＼(^o^)／.|￣￣￣￣￣| | ＼(^o^)／
) ) .| |／ ノ ノ
(((( >￣ > )))) ＼(^o^)／ ((( <￣< ))))
) )
((( >￣ > ))))
234:nobodyさん
07/07/08 23:39:25
＞PHP5への移行が進まない
そもそも、これがどれだけ説得力を持つはなしなのかね。
個人レベルのPHPサイトとかが多いからそうなってるだけだろ。
業務ベースなら、新規は５が当然。既にあるやつもそれなりにリニューアルするなら５で
動かすようにリファクタかけるよ。
235:nobodyさん
07/07/09 00:20:13
PHP4脂肪→
オブジェクト指向が理解できない大多数のプログラマ（PHPerの80％）の離脱→
PHP脂肪
236:nobodyさん
07/07/09 07:09:04
drupal使ってるやついねーのかな
結構色々できると思うんだけど
237:nobodyさん
07/07/09 08:16:21
drupalはフレームワークなわけ？
何が魅力なの？
Webページつくるだけなら違うcmsあるし、Webサービスつくるなら足りないだろ？
238:nobodyさん
07/07/09 09:11:54
URLﾘﾝｸ(en.wikipedia.org)
にweb application frameworkって書かれてるよ
魅力はより少ない手間で作れたり、
高負荷のサイトで使われてたり、他のCMSより拡張性が高かったり。
cckとか色々モジュールがあるし、足りなければモジュールを作って拡張できるから
よっぽど複雑なことをするのでない限り、
大抵のことはdrupalでもできると思うんだが
Webサービスとかはできるかどうかわからないから、「結構」って表現にしたんだけど。
完璧じゃなくても、ほとんどの場合に十分使えればいいんじゃないかと
239:nobodyさん
07/07/09 09:14:01
すれ違い、それいっちゃ、XOOPSだって、フレームワークだろ。
240:nobodyさん
07/07/09 09:25:18
>>239
やっぱそっか。スマソ
でもフレームワークとの境界線って曖昧な感じになってきてるよね
241:nobodyさん
07/07/09 09:55:48
ＣＭＳがMVC意識せずにどんどん肥大化していく中で、今で言うフレーム
ワークが展開していったっていう時間の流れだよ。自分はDrupalはその
最中に出てきた「スマート」なＣＭＳ奴で、XOOPSは一時代前のカオスCMS
っていう押さえをしてる。
242:nobodyさん
07/07/09 10:11:55
もうｶｴﾘ
ｽﾚﾘﾝｸ(php板)
243:nobodyさん
07/07/09 20:20:17 sJXKqrgb
>>232
それあるなぁ。そこを簡単に共存できるようにしてれば、
余裕でPHP5が使えるようになったし、PHP4のコードもそのままにできた。
244:nobodyさん
07/07/09 21:22:09
共存なんか大した手間じゃない。
245:nobodyさん
07/07/10 21:53:08
まあriverse proxyとか含めればいくらでも出来るからなあ。
246:nobodyさん
07/07/10 22:30:17
大した手間かけずに共存環境に移行できるサービスばかりだったらそれでよかったんだろうさ
247:nobodyさん
07/07/10 22:58:26
？言ってる意味がわからん
248:nobodyさん
07/07/12 22:09:49
>>241
Drupalは何が「スマート」なの?
XOOPSはコード的に古いから乗り換えるか
ZFあたりで出てきそうなCMSを探すか考えているところ
249:nobodyさん
07/07/12 22:47:39
CMSなんか使ってるやつはくず。
コード気にする価値なし。
250:nobodyさん
07/07/12 22:49:58
249はよくいるような「皆が使ってるものを否定する自分ｶｺｲｲ」なお子様に見えなくもないが
重厚長大なフルセットCMSって今もうそういう対象でもないよな
251:nobodyさん
07/07/12 22:51:34
どのFWもプレゼンテーション層がお粗末なのがどうもなぁ。
Smartyとかデザイナにしてみたらえらい負担だろうし。
もっと連携のしやすいものがあればいいんだけど。
252:nobodyさん
07/07/12 23:00:41
>>249
頭堅いなあ
出来上がるもんが結局同じなら、車輪の再発明しなくてもいいのに
253:nobodyさん
07/07/12 23:18:40
今日びＰＨＰもできないデザイナーは死滅したらいいよ
254:nobodyさん
07/07/12 23:30:31
>>253
お前がな
255:nobodyさん
07/07/12 23:36:15
うむ。今更感の漂う話題ではあるが
俺もついでに今更感の漂う話を投下しとくか
おまいら、CMSが好きならZope + Ploneが最強じゃね？
256:nobodyさん
07/07/14 16:14:49
PHP4サポート打ち切りって影響甚大じゃね？
稼動してるサイトは膨大で
そのうちPHP5に移行できるのはどれだけあるのか？
サイバーテロが吹き荒れそう
257:nobodyさん
07/07/14 16:36:57
正直遅いぐらい
ようやく4排除への大義名分を得られるわけだ
258:nobodyさん
07/07/14 17:44:07
これで4しか入ってなかったレンサバも5に切り替わるといいな。
259:nobodyさん
07/07/14 18:32:17
今PHP3で走ってるサイトってどのくらいあるのかな
260:nobodyさん
07/07/14 18:36:19
4から5のリプレースがうまくいかなかったのを教訓に
6は5と共存できるような仕組みが欲しいところだな
261:nobodyさん
07/07/14 18:48:36
「仕様が完全上位互換」とかじゃダメなんだよな
共存させたい環境のひとは新環境での再テストとかもしたくないだろうし
262:nobodyさん
07/07/15 00:13:42
そもそもそのテスト費用が出して貰えないから困るわけで。
263:nobodyさん
07/07/16 23:55:55 jJDluNIm
皆さん地震大丈夫ですか？
NTTの災害用ブロードバンド伝言板（web171）はPHPなんだね。
不謹慎かもしれないけど、ちょっと嬉しい…。
264:nobodyさん
07/07/17 11:54:09
そうかな? PHPだと大規模災害時とかでロードが大きくなったときに
ホイホイとスケールできるのかちょっと心配な気が...
265:nobodyさん
07/07/17 12:08:08
スケールできるよPHP
266:nobodyさん
07/07/17 14:31:06
サーバ、ネットワーク周りの改善でなんとでもなる。
267:nobodyさん
07/07/17 17:20:35
>>251
連携のしやすいものって例えばどんなもの?
php直書きとsmarty以外の簡単な方法って浮かばないんだけど
268:nobodyさん
07/07/17 17:32:55
もっと直感的に使える高機能な独自タグってことだろ。MTみたいな感じじゃないか？
269:nobodyさん
07/07/17 19:53:06
>>251が曖昧で分からないが
連携に関しては基本デザイナに埋め込みさせなきゃいいと思うんだが
270:nobodyさん
07/07/18 00:09:10
そんな事いってるから日本のPHPサイトは手抜きデザインばっかりなんだが
271:nobodyさん
07/07/18 00:32:13
>>270
なんでそうなるんだよｗ
デザイン→HTMLコーディングまでデザイナ側で落とし込んで
PHPの埋め込みだけプログラマがやればって話なのに
「そんな事いってるから」の後になんで手抜きデザイン？
272:nobodyさん
07/07/18 03:49:36
あとで修正はいったらどうすんの？
273:nobodyさん
07/07/18 09:01:06
適時対応
静的部分だけの修正でデザイナだけで
修正できるようであればデザイナが修正
修正箇所に動的な部分を含んで
埋め込みコードの修正も伴うのであればプログラマが修正
で、なんか困ることある？
274:nobodyさん
07/07/18 11:00:52
結局デザイナーっていらないね
275:nobodyさん
07/07/18 11:14:27
状況から真っ当な結論を導き出すのが極端に下手な奴がいるな
276:nobodyさん
07/07/18 11:31:24
まともにデザイナと連携して仕事したことないんだろうな
277:nobodyさん
07/07/18 16:25:07 3R7D5ath
SmartyのかわりにPHPTALとかじゃだめなの？
278:nobodyさん
07/07/18 17:49:45
デザイナーと仕事するのが偉いと勘違いしてるやつがぽつぽつ
279:nobodyさん
07/07/18 18:40:20
自分が一番偉いんだと勘違いしてるやつが・・・
280:nobodyさん
07/07/18 18:43:56
コーダーでPGもこなす俺が真の勝ち組。
デザイナにはデザイン画像だけ描いてもらえばおｋ。
HTML起こすのは自分でできるもん♪
281:nobodyさん
07/07/18 18:45:26 sJyKZns/
全部一人でやれる奴が最強な訳で・・・
282:nobodyさん
07/07/18 18:49:11
実際ヘタな紙デザイナに変なHTML書かせるより
画像だけ描いてもらってHTMLに起こすのはプログラマがやった方が
結果としてキレイなものが出来上がる気がする
283:nobodyさん
07/07/18 19:17:22
ズレてきてるな
どう役割分担して連携するかって話だろ
誰が偉いとかおまえらのHTMLコーダー自慢とかはどうでもいいよ
284:nobodyさん
07/07/19 10:09:35
読みこみファイル数がすごい数になってるんだけど
アクセラレータつこうたら大丈夫？
お前らどうしてますか？
285:nobodyさん
07/07/19 12:33:42
>>284
まずコードを見直す
286:nobodyさん
07/07/19 14:46:00 Qs6wUD6U
>>284
主要フレームワークってeaダメだよね？
287:nobodyさん
07/07/19 15:12:56
cakeはいけてますが
288:nobodyさん
07/07/19 21:29:14
なんでeaってダメなの?
xcacheならOK?
289:nobodyさん
07/07/19 21:44:14
異常動作することがあるらしいね>ea
アクセラレータのスレにあったはず
別にフレームワークは関係ないと思うが
290:nobodyさん
07/07/20 04:21:50
>>285
フレームワーク自体がファイル読みこみまくりだからコード見直しても意味ない
hello,worldですらファイルが数十個読まれる
つまりフレームワーク使うのは阿呆
ついでにいえばウェブプログラムごときでオブジェクト指向使うやつも阿呆
291:nobodyさん
07/07/20 04:56:45
とオブジェクト指向が理解できない阿呆が申しております。
292:nobodyさん
07/07/20 09:49:57 xk3U0lu8
protectedな変数持ってるとEA動きません。
293:nobodyさん
07/07/20 10:14:17
まじで？
俺オワタ＼(^o^)／
294:nobodyさん
07/07/20 10:19:26
本当に必要なファイル読み込みなのかどうかコードを見直せ。
ＦＷ側で不要なインスタンスを発行しまくっているようなら、
それをコロすように継承自前クラスで上書き。
ＦＷって結局汎用だから、MVCの過程で、余分な処理をしてることが往々にしてある。
次に、ページキャッシュを考えろ。キャッシュ処理可能ページとそうでないページの
振り分けをちゃんとできるようにコードを見直す。
アクセとかハードウエア性能向上という手がつかえないなら、それしかないだろう。
295:nobodyさん
07/07/20 10:35:03
気にしないのが一番
296:nobodyさん
07/07/20 12:42:12
inodeは上限あるけど
オープンできるファイルに上限てあんの？
297:nobodyさん
07/07/20 12:59:27
少なくともlinux, bsdにはある
windowsは知らん
298:nobodyさん
07/07/20 14:44:44
>>292
いつの話よ？ 0.9.5.1 では直ってる。
299:nobodyさん
07/07/20 21:35:41 g4/DmFJL
>>298
protectedの件は直ったらしい。
でも、例外キャッチできないんだって。
URLﾘﾝｸ(d.hatena.ne.jp)
300:nobodyさん
07/07/20 21:40:09
>>299
オプティマイザのバグということは、オフにすれば (eaccelerator.optimizer = 0) おｋ？
キャッシュの恩恵は受けられるし。
301:nobodyさん
07/07/20 21:53:04
だいたいPHPはバギーすぎるんだよ。何、PHP5は安定しているので、PHP4は開発中止？こっちはキムチパッチ当ててる所だ。
302:nobodyさん
07/07/20 22:17:02
>>299
それは使い物にならんな・・・
303:nobodyさん
07/07/21 02:40:16
オプチマイザなんてたいした効果もないんだからオフでおk
304:nobodyさん
07/07/21 05:04:00
ポン入れでまもとに使えない時点でアウト。
たまに案件でphp.iniをグチャグチャいじってさらにPHP_VALUEまでいじってるあるのに遭遇するが、
開発サーバで再現しきれん設定とかがあってむかつく。
305:nobodyさん
07/07/21 10:31:30
アウトならこんなところまで来てネガってないで他の言語使えばいいじゃん……
何がしたいんだ？
再現しきれんってのは「設定できる場所を自分が把握できてない」って意味なだけだろ？
306:nobodyさん
07/07/22 08:29:26
O/Rマッパって何のためにあるんだ？
返り値がオブジェクトの配列である必要性がねーだろ
普通の連想配列で何の問題もない
307:nobodyさん
07/07/22 11:19:49
>>306
OOP的にかっこいいから、とかそういうことなんじゃない？
たぶんOOP的なものと非OOP的なものが混在するのを嫌ってるんだろう。
308:nobodyさん
07/07/22 11:31:11
ＯＯＰのためにマッパが作られてるんだけどね。
309:nobodyさん
07/07/22 12:26:09
何の問題もないなら使わなきゃいい
まあそれをわざわざここに書いてる事自体
「なんでO/Rマッパがいいのかわかりません」
って書いてるようなもんなんだけどねｗ
310:nobodyさん
07/07/22 12:41:59
>>309
お前も分からないんだろ
強がるなよ
311:nobodyさん
07/07/22 13:03:41
>>310
普通に使ってるよ
てかO/Rマッパのメリットが分からないとか
O/Rマッパ使う理由がかっこいいからとか
そんなレベルでFWのスレに来る奴ってなんなのｗｗｗ
312:nobodyさん
07/07/22 13:05:08
>>311
メリットが分からないまま使ってるんだろ
やせ我慢乙ｗｗｗｗ
313:nobodyさん
07/07/22 13:28:44
Oは、おぶじぇくとのおー
314:307
07/07/22 13:30:46
そういやFWのスレだったｗ
315:nobodyさん
07/07/22 17:05:31
ヘルパーってかっこつけて言ってるけど単なる関数なんだな
本来viewのものなのに
グローバルスコープにあるのもダサいことこの上なし
316:nobodyさん
07/07/22 17:07:10
オーバーライドできないのもまたビッチなり
317:nobodyさん
07/07/22 17:22:22
それはおれも思った
ただのグローバルスコープにある関数がいつのまにヘルパなんて呼ばれて美化されてんだ，ってｗ
変数は view 展開時のみグローバルスコープに登録されるものが多いようだから
関数もそうするようになってるフレームワークがあってもいいように思うが
パフォーマンスとか色々の面で現実的じゃなさそうかな……
318:nobodyさん
07/07/22 17:32:02
CakePHPとかsymfonyのヘルパーってクラスじゃなかったっけ
319:nobodyさん
07/07/22 17:34:57
rubyみたいにレシーバが省略できないから
railsのviewライクに使えるよう突き詰めた結果がああなったと思われる
まあ早い話が$this書きたくないっていうことだな
俺もview helperとはいえ単なるfunctionにするのは好みじゃないな
ZFのview helperはクラス（オブジェクト）になっている
view helperがfunctionになってるのはsymfonyだっけ？他にもあるかな
320:nobodyさん
07/07/22 17:36:07
>>318
cakeは見たことないけどsymfonyは関数だった
321:318
07/07/22 17:39:28
あ、symfonyはfunctionか。ごめん
322:nobodyさん
07/07/22 17:40:35
cakeはクラス。CIは関数
323:nobodyさん
07/07/22 17:45:28
関数使うFWでも
読むファイル指定してるだけだからstaticなクラス書いてもいいけどね
324:nobodyさん
07/07/22 17:47:58
staticなクラスにしちゃうと今度は使う時名前が長くなるんだよ
phpのどうしようもないところｗ
325:nobodyさん
07/07/22 17:50:08
でも俺はstaticなクラス作って書いてる。
後から一括置換なんかも便利だし。
326:nobodyさん
07/07/22 17:59:50
俺は関数でもいいと思う派だけど、
関数の場合、初めから用意されてるヘルパーがFW側に置いてあるのはどうかと思う。
コマンドでアプリケーションのディレクトリ構造を展開したときに、アプリ側に展開して欲しい。
クラスにした方がいいと思ったらクラスを作る。libなイメージ。
327:nobodyさん
07/07/22 18:03:24
staticクラスで、ヘルパー関数を一旦ラップするのをお勧めする
328:nobodyさん
07/07/22 18:10:22
viewにview helperがmixinされるような形のが一番いいよ
$thisを書くのは必要経費で
329:nobodyさん
07/07/22 18:19:34
うーんmixinかー
メソッド名が元のviewと被ったら？
330:nobodyさん
07/07/22 18:33:50
unit test時にわかるでしょ
331:nobodyさん
07/07/22 18:56:57
>>327
意図は？
staticクラスというのはstaticメソッド群からなるクラスのことだと思うが、
staticメソッドでラップしても関数を関数でラップするのと変わらない。
クラスの(static)プロパティも使用しいくつかのヘルパー関数群を
関連するものとして扱うなら、それはstaticよりもインスタンスにして
投げるインスタンスで振る舞いを変えられるようにしたほうが意味があると思うのだが。
332:nobodyさん
07/07/22 19:04:54
そこまでやるなら、既存のヘルパ関数なんかそもそも使わん。ヘルパー用クラスを
書くよ。保守を考えてstaticにするのは同一関数（メソッド）名で、とりあえずヘルパ使ってるってことを
明示しつつ拡張するため。関数を同一関数名でラップすることは出来ないからね。
333:nobodyさん
07/07/22 19:18:21 3PPkob3E
単にネームスペースの代わりだね。俺もやるよ。
334:nobodyさん
07/07/22 19:28:48
まあFW側で直接定義されてるfunctionじゃな
オーバーライドすらできんしな、FWのソースを書き換えとか御免だ
ラッパーがstatic/dynamicどっちがいいとかは抜きにして
ラップして使う事自体に意味はちゃんとある
335:nobodyさん
07/07/22 19:34:02
関数だとどこで定義されているか、わかりにくいしねえ。
336:nobodyさん
07/07/22 19:37:03
うん、grepすりゃいいからそれは別に困らないがｗ
337:nobodyさん
07/07/22 19:50:04
関数ヘルパでも接頭辞付けたらラップできるな
338:nobodyさん
07/07/22 20:44:06
～～すれば～～が無くてもおｋ
って発想を減らしていかないと「誰でも使えるフレームワーク」にならないんだろうね
わかってる人だけでいじるならこの思想の方が楽でいいんだがｗ
>>319
CodeIgniterも関数じゃなかったかな？
339:nobodyさん
07/07/22 20:56:10
「誰でも使えるフレームワーク」とか要らん
340:nobodyさん
07/07/22 22:16:39
誰でも使えないフレームワーク誕生の瞬間である
341:nobodyさん
07/07/23 00:56:07
>>317
変数はグローバルスコープに登録されてるわけじゃないよ
メソッド中のローカルスコープにテンプレートを読み込んでるだけ。
テンプレートを基準にして見るとグローバルスコープかと思えるけど。
342:nobodyさん
07/07/23 07:09:56
>>338
ＦＷが機能を実装してなくてもいいんじゃないのかね。
外部ライブラリの導入やユーザ拡張がしやすい設計（ＭＶＣが可能な限り疎結合的）
であることが、いいＦＷの第一条件だと思うよ。
その上で個別に、ＸＸのルータクラスは使いやすいとか、モデルが書きやすいとか、
そういう評価が出てくると思う。
343:nobodyさん
07/07/23 12:45:58
>>342
ＦＷとは何か？を理解してないやつが語ってるんだからしょうがあるまい。
こう書くと誤解を招く恐れもあるんだが、「仕様こそがＦＷである」とでも書いておくかな。
じゃないと、いつまで経ってもＦＷとライブラリの違いも判らん奴が妙な書込みを続けるし。
344:nobodyさん
07/07/23 20:12:12
＞仕様こそがＦＷ
ﾜｹﾜｶﾗﾝ
345:nobodyさん
07/07/23 21:56:37
こう書くと誤解を招く恐れもあるんだが、
「『仕様こそがFWである』こそ妙な書込み」とでも書いておくかな。
じゃないと、いつまで経っても妙な書込みとそうでない書込みの
違いも判らん奴が妙な書込みを続けるし。
346:nobodyさん
07/07/23 22:58:29
フレームワークこそがＦＷである。
347:nobodyさん
07/07/24 01:46:05
最近出てきてるとかを見ると、バッドノウハウの温床だな。
348:nobodyさん
07/07/24 02:52:11 Wl3XMVYJ
Fireworks
349:nobodyさん
07/07/24 09:36:30
Firewall
350:nobodyさん
07/07/24 11:38:30
Frank Williams
351:nobodyさん
07/07/24 11:45:34
>>347
たとえば？典型例は？
352:nobodyさん
07/07/24 12:58:42
for ( $i=0,$count=count($contents); $i<$count; $i++ ){
}
ループ中のカウントを減らすためにこういう書き方すんのって
バッドノウハウですか？普通にあり？
353:nobodyさん
07/07/24 13:07:30
>>352
アリじゃね？
354:nobodyさん
07/07/24 13:35:50
「for文の条件内でcount()を使うな」はバッドノウハウではないと思うけど
その書き方はどうかと……
$count=count($contents);
for ( $i=0; $i<$count; $i++ ){
}
の方が見る人が理解しやすいと思うなぁ
355:nobodyさん
07/07/24 14:12:03
激しくどっちでも良過ぎて溜息が漏れる
356:nobodyさん
07/07/24 14:12:23
なにが「どうかと……」だよ。いたって普通だろうが。
357:nobodyさん
07/07/24 14:33:10
ワンライナーで書けるものは書けばいいじゃんっていう空気が
phpはあんまりないよな言語仕様による要因が大きいけれども
rubyとかは仕様も使う側もそういう空気に満ち溢れてるから
コードは短いけど行単位の情報量が必然的に多くなる
358:nobodyさん
07/07/24 14:44:56
forの式1はカンマ区切りで複数とれるのね。しらんかったよ。
359:nobodyさん
07/07/24 14:49:19
>>352
forループで関数呼び出しを避けたほうがいい
URLﾘﾝｸ(lint.s1.x-beat.com)
360:nobodyさん
07/07/24 15:02:17
>>359
せっかくだから環境も分かるようにしてくれよ。
いつのベンチかわからん。
361:nobodyさん
07/07/24 15:04:45
>>359
>>352 の関数呼び出しは、評価部分ではなくて、初期代入部分だから、
そのベンチはあてはまらんだろ？
362:nobodyさん
07/07/24 15:19:32
>>359
よく読め
それを避けたいから
for ( $i=0; $i<count($contents); $i++ ){
でなく
for ( $i=0,$count=count($contents); $i<$count; $i++ ){
なんだろ
363:359
07/07/24 15:22:22
>>361
>>352の書き方でいいよといいたかった
364:nobodyさん
07/07/24 19:12:05
たしかに、自分がPHPで書くときは出来るだけワンライナーは避けてるなぁ。
他者が関わる場合は、極端に言えば本当の初心者が見ても解るように書いてる。
コードの「格好良さ」より、「解りやすさ」重視って感じかな。
365:nobodyさん
07/07/24 19:56:24
俺もそう。
なんかワンライナーの方がかっこよくみられるけどね。
わかりやすい方がいい。
Rubyみたいに . で右につないでいけると、
ワンライナーも使いやすくなるんだけど。
366:nobodyさん ◆wSaCDPDEl2
07/07/24 20:10:07
ワンライナーでなんか書いて
367:nobodyさん
07/07/24 21:03:40
おとこわりだ！
368:nobodyさん
07/07/24 21:07:06
どう考えても>>354のほうが視認性があるだろ。
369:nobodyさん
07/07/24 21:31:29
for文のループに関する議論は、確かsymfonyで話題になったことが
あったみたいだけど、コレすなわち「FWを利用することによるバッドノウハウ」
とはならんよね。
370:nobodyさん
07/07/24 22:02:50
一方ロシアは
foreach ($contents as $i => $content) { }
を使った
371:nobodyさん
07/07/24 22:32:45
>>370
なるほど
それいいな
パフォーマンスも問題ない？
372:nobodyさん
07/07/24 22:38:28
それは、パフォ的にありまくり。使っちゃいけないだろうな。
373:nobodyさん
07/07/24 22:44:17
えええええ
ロシア駄目じゃん
374:nobodyさん
07/07/24 22:46:08
手元のテストループで言えば、ロシアは1.5倍増の時間がかかってる。
ロシアの負け。
375:nobodyさん
07/07/24 22:51:50
つーかPHPならforeachふつうに使うだろ。。
おまえら本当にPHP使ってるのか。
376:nobodyさん
07/07/24 22:55:11
連想配列なら使うけど普通の配列なら使わない
377:nobodyさん
07/07/24 22:55:26
for使う事自体が少ないしな
378:nobodyさん
07/07/24 22:59:14
連想配列の話してるわけじゃないんだけどね。
379:nobodyさん
07/07/24 23:06:02
・中身だけ使う
foreach ($array as $value) { }
・キーだけ使う
foreach (array_keys($array) as $key) { }
・両方使う
foreach ($array as $key => $value) { }
for使うってのは滅多にないな
しかしFWのスレなのに重隅論議だな
380:nobodyさん
07/07/24 23:12:00
前にも出た結論な気がするけど
FW使うってだけでそんな重隅最適化なんてぜんぶチャラだよなｗ
381:nobodyさん
07/07/24 23:19:46
最適化っていう視点じゃなくて綺麗で視認性がある書き方したい
ってことで見れば別に重箱でもない。
382:nobodyさん
07/07/25 00:38:21
>綺麗で視認性がある書き方したい
そんなもんPHP使ってる時点で(
383:nobodyさん
07/07/25 00:46:56
お前みたいな思考停止はイラネ
384:nobodyさん
07/07/25 01:11:06
ブロックスコープのある言語の使用者にとっては、ブロック内での使い捨ての変数は初期化式で宣言するのが当たり前なんだけどな。
この辺にペチパーの底力を感じる。
385:nobodyさん
07/07/25 01:34:40
つーか>>370では>>352と挙動が別物なんだがな
386:nobodyさん
07/07/25 02:26:41
人を見下さずに普通に発言できんものですかねおまいら
387:nobodyさん
07/07/25 18:00:18
仕様です
388:nobodyさん
07/07/26 01:09:42
>>351
ページごとにいちいちサブコントローラ(Action)を書かないと動かないような、
無駄にStrutsの汚点を継承しているEthnaとか。
処理系の実装してる組織のくせに言語仕様じゃなくて
コーディングルールでゴリゴリ縛ってるZendとか
しょうもない所でPEAR::DBに依存してるくせにDB::getAll()がラップされてなくて、
結局メンバのPEAR::DBインスタンスに直接アクセスするしか解決方法が無かったりとか
どうせ作業の流れなんて機能単位でしかやらないのに
ファイル構成でモデルとビューのディレクトリががロンドン・パリなみに離れてるわ
さらにそれぞれアクション命名規則に縛られてかなりディープなディレクトリ構成になるわで
Eclipseの画面からはみでてしまって小さい修正のたびに
スクロールバーいじらんなんハメになってたりとか
PHPなんて標準でフォームバリデータとモデル仕様がないから面倒なだけなのに
FWなんて大げさなもんにして一生使いもしないクラスを多重に内包して無駄なメモリ・CPU時間食ってる
PHP用FWの存在意義とか。
389:nobodyさん
07/07/26 01:14:46
今度は>>388が素晴らしいFWを教えてくれるそうです。
390:nobodyさん
07/07/26 01:23:09
ページごとにサブコントローラを書かずに動くとしたらどんなの？
391:nobodyさん
07/07/26 02:59:01
簡単さでいうと、
ちいたん＞CodeIgniter＞CakePHP＞Symfony
ですか？
392:nobodyさん
07/07/26 09:27:58
>>388
最近の、って言っときながらほとんどEthnaの話だけかよｗ
Ethnaみたいな旧態依然なFW使ってりゃそりゃBKだらけになるわなｗ
393:nobodyさん
07/07/26 11:28:09
BKって何？
394:nobodyさん
07/07/26 11:33:52
>>モデルとビューのディレクトリががロンドン・パリなみに離れてる
こんなん自分で変えたらいいだけじゃね
395:nobodyさん
07/07/26 11:47:08
ディレクトリ構成自体がＦＷの設計であるということも
わからない奴はＦＷを触るなよ
396:nobodyさん
07/07/26 11:50:57
こう書くと誤解を招く恐れもあるんだが、「ディレクトリ構成こそがＦＷである」とでも書いておくかな。
397:nobodyさん
07/07/26 11:53:52
>>393
＞URLﾘﾝｸ(ja.wikipedia.org)
好みのものを選んでくれ
398:nobodyさん
07/07/26 14:20:46
>>388
> 処理系の実装してる組織のくせに言語仕様じゃなくて
> コーディングルールでゴリゴリ縛ってるZendとか
これはまさにその通りだな。
つーか、PHPの開発チームってどういう構成になってるんだ？
399:nobodyさん
07/07/26 14:36:21
>>397
俺はBerryz工房だな
400:nobodyさん
07/07/26 14:37:54
FW（的なもの）ありきなものがいいんなら
勝手にcoldfusionなりwebobjectsなりやってくれ
401:nobodyさん
07/07/26 16:45:14
>>398
コーディングルールでゴリゴリ縛ってるって具体的にどういう所？
クラスの命名規則ってこと？
402:nobodyさん
07/07/26 22:00:26
>>399
俺は美少女教育が気になる
403:nobodyさん
07/07/26 22:03:45
>>401
これらね↓
URLﾘﾝｸ(framework.zend.com)
?>書かないのも気持ち悪い～とか思ってたけど、
自然と書かなくなったな。なんかめんどうだから。
404:nobodyさん
07/07/26 22:31:48
へー。
？＞省略は糞だろうなあ。
単にヘッダの空文字列送出防ぐためにやってるんでしょ？
本末転倒だ
405:nobodyさん
07/07/26 22:59:42
さっさと <?php を省略できるようにしろよ、糞Zend
406:nobodyさん
07/07/27 00:16:54
sigilは好みもあるからどっちでもいいけど、つけるんだったらコレくらいはパースしてほしい。
<?php
$a = array('a'=>1);
print "$a['a']\n";
?>
↑エラー
#!/usr/bin/perl
%a = ('a'=>1);
print "$a{'a'}\n";
↑「1」。当然の勝利。
407:nobodyさん
07/07/27 00:32:26
片方を文法に従わず書いて他方を文法に従って書いて何が勝利なのか全然わからんがｗ
既存の文法が気に食わないならソースにパッチ当ててオリジナルのPHP作って使ったら？
408:nobodyさん
07/07/27 00:57:19
要するにPHPのパーサーがヘボってこと。
409:nobodyさん
07/07/27 01:36:06
要してねーだろ
ヘボいのはPHPの文字列解釈仕様であってパーサはその仕様の通りに正常に動いてるんだろーが
自分が何を気に入らないのかすら理解できてないアフォですか？
410:nobodyさん
07/07/27 01:47:46
仕様って…ｗ。
まあ、PHPはprint $a['a']."\n";とやるしかないわな。
$a = 0 || 100;とか3項演算子の左結合とか、たいそうな仕様だわ。
こういうのが積み重なって、PHPのヘボソースが出来上がる。
411:nobodyさん
07/07/27 02:17:30
print "{$a['a']}\n";
何もそんなに自信満々で無知をひけらかすことはないと思うんだ。
412:nobodyさん
07/07/27 02:19:41
print "$a[a]\n"; もしくは print "{$a[a]}\n";
PHPの糞仕様を擁護する気はさらさらねーが
悪口言いたい一心で研究不足を自慢されてもバカじゃね?としか思えん
413:nobodyさん
07/07/27 02:49:11
>>411
その{}を面倒と思わないなら、それでいいよ。俺はノーサンキュー。
414:nobodyさん
07/07/27 02:51:10
>>412残念
配列ですべきこととしてはならないこと
なぜ、$foo[bar] は使用できないのか?
URLﾘﾝｸ(www.php.net)
415:nobodyさん
07/07/27 09:26:41
>>412は釣りだろ？でなきゃ考え付かない
416:nobodyさん
07/07/27 15:20:29
codeigniterのリンクヘルパの仕様おかしくね？
引数の順序はfunc(label,uri…）だろ、感覚的に考えて。
anchor(uri,label)ってなめてんのかこの野郎
417:nobodyさん
07/07/27 15:44:12
<a href="url">label</a> の順序に従ってるんじゃないか？
感覚の問題だから一概には言えないが俺もlabelが前の方が自然だと思う
418:nobodyさん
07/07/27 15:57:50
<a href="url">label</a>において
href…属性
label…内容
重要度から言えば内容>属性だから、
第一引数は内容=labelがふさわしい
419:nobodyさん
07/07/27 15:59:34
>>416 のanchor(uri,label) しか見てないけど、
labelは省略可能な気がするから（urlで代替できる）、
それでいいんじゃない。
省略可能かどうかは知らんが。
420:nobodyさん
07/07/27 16:00:16
フレームワークでは標準的な、
「mod_rewriteを使ってindex.phpを隠す方式」の正式な名称って何ですか？
421:nobodyさん
07/07/27 16:01:22
>>419
symfony様に喧嘩売ってんのか
422:419
07/07/27 16:05:30
マニュアル見たらurlで代替すると書いてるじゃん。
URLﾘﾝｸ(userguide.cilab.info)
だからこれでいい。
423:nobodyさん
07/07/27 16:15:18
>>420
正確に指し示すこれっていう名前はないなそう言われてみれば
WEBFWのほぼ標準的な仕様なのにな
424:nobodyさん
07/07/27 16:33:38
PATH_INFO方式とはまた別なの？
425:nobodyさん
07/07/27 16:51:30
>>424
PATH_INFOの場合は、..../index.php/foo/barが機能するから直接の関係性はない。
426:nobodyさん
07/07/27 16:58:19
隠れディスパッチャ方式でok
427:nobodyさん
07/07/27 18:39:49
indexの話でもなくて
リライトルータ、URLマッパーの話でもない?
428:nobodyさん
07/07/27 20:18:55
mod_rewriteを使ったフロントコントローラ、かなあ
429:nobodyさん
07/07/27 20:38:49
>>428
機能そのまま説明してるだけじゃんｗ
430:nobodyさん
07/07/27 20:42:59
>>422
ラベルをURL自体にするケースがどれだけあるのかと。
そんなレアケースのために引数の順序が決定されるのは納得いかない
あー納得いかないね
431:nobodyさん
07/07/27 20:54:43
>>427
ゼンブ違う
432:nobodyさん
07/07/27 21:14:22
いってる意味ﾜｶﾗﾝなあ。
URLが先、ラベルが後のほうが直感的にＯＫだろ
433:nobodyさん
07/07/27 21:34:14
まあ、感覚だから個人差はあるな
symfonyはlabel,url
ciはurl,label
他は？
434:nobodyさん
07/07/27 21:38:41
そもそも中に入るテキストを
「ラベル」って呼ぶ事に何の疑問を感じてないおまえらにイライラする
435:nobodyさん
07/07/27 21:42:39
呼んでいる奴に付き合ってあげてるだけだからそこでイライラするな
そんなこといえば「中に入るテキスト」なんてW3C定義と全然違うだろ。
436:nobodyさん
07/07/27 21:42:42
話題を振った416の用語に合わせてるだけだと思うが
そういう434は何と呼ぶのが良いと思う？
個人的には「アンカ」「アンカ文」あたりかと思うが
「ラベル」の方がより多くの人に意味が伝わりそうな気がするな
437:nobodyさん
07/07/27 21:45:46
どうでもいい定義に拘ってる434の方にイライラする
普通に伝わればいいだろ
テーマの中核じゃないんだから
438:nobodyさん
07/07/27 21:55:14
434の人気に、嫉妬はしない
439:434
07/07/27 22:04:29
リアル涙目なんで
引き続き 【PHP】フレームワークについて語るスレ7【総合】 でお楽しみください
「中に入るテキスト」はねーよ俺、反論できない
440:nobodyさん
07/07/27 22:21:40
泣いてるの？
441:nobodyさん
07/07/27 23:06:40
>>433
cakeのバヤイ
link (label,url)
442:nobodyさん
07/07/27 23:21:22
ZFの場合
リンクのヘルパ自体無い
443:nobodyさん
07/07/27 23:27:43
二大人気FWのsymfonyとcakeが
label,urlを採用しているということは
ciは異端
ZFはなめすぎワロタ
444:nobodyさん
07/07/27 23:29:50
>>416
ヒント：イニシャルは姓と名が逆
445:nobodyさん
07/07/28 02:19:59
CIって規模小さいけど作ってるヤツ頭いいな～。
label,urlは前々から疑問感じてた。
446:nobodyさん
07/07/28 02:55:44
擁護みたいな形になるが、俺も「ラベル」の意味がわからず読んでたが、
434を読んでやっと<a href=url>この部分</a>のことだとわかった
もちろんlink(label, url)ってペアで書いてあればすぐわかることだけど
447:nobodyさん
07/07/28 03:32:53
ciのヘルパが気持ち悪いから
my_anchor作りました(`Д´)
448:nobodyさん
07/07/28 03:36:13
ラベルって呼ぶのは
GUIのプログラミングの文化
449:nobodyさん
07/07/28 09:13:03
>>446
>>417も読まないわけですか？
450:nobodyさん
07/07/28 10:14:49
>>430
そんなにレアケースとも思わないけど。
入力されたURLを<a>タグに置き換える時とかに使わない？
ま、どっちが先だろうがどーでも良いけど、
>>447みたいな事するくらいなら他のFW使えば良いのに。
451:nobodyさん
07/07/28 10:19:23
>>449
そりゃ気付かなかった
452:nobodyさん
07/07/28 10:51:50
>>450
いやいやいや
他のFW使うくらいならヘルパ作る方が断然楽だろ
リンクヘルパの引数の順番の好みのために、学習曲線を登る苦労とか実装されてるユーティリティ機能とかを完全に無視できる奴はそうそういないだろｗ
453:nobodyさん
07/07/28 14:27:44
そのうち誰かがどっちでもいい関数作って、それが後々
セキュリティホールになったりするのがぺちぱークオリティ、
とか言ってみる。まぁ、冗談だけど。
454:nobodyさん
07/07/28 15:02:30
いや、あるあるｗ
455:nobodyさん
07/07/31 03:39:25
俺俺フレームワーク作ってるが
複数DBの抽象化面倒くせえええ
取得できるカラム情報のデータ形式がDBによってかなり違うし
456:nobodyさん
07/07/31 09:11:20
>>455
DBのアダプタみたいな面白くない割に大変で
クリティカルな部分はライブラリ使った方が楽だぜ
俺もO/Rマッパは自分で書いてるけど
DBの抽象化はZend_Db_Adapterでやってる
457:nobodyさん
07/07/31 14:24:55
>>456
ZFはいまいちな印象があったんだが
そんなのがあったのかー
見てみるわ。ありがとう。
458:nobodyさん
07/08/03 00:36:40
>>455
URLﾘﾝｸ(journal.mycom.co.jp)
PHP版Ruby on Rails? - DB操作クラスを自動生成する"PHP Object Generator
こんなので手間を省けませんか？
459:nobodyさん
07/08/03 00:54:56
>>458
結構良さそうだね
既に100万オブジェクト以上発行してるのか
てか字ちっさ！
460:nobodyさん
07/08/03 00:56:38
PHP版Ruby on Railsっていう呼び方は全然違くない？
ジャンルが違う感じだ
461:nobodyさん
07/08/03 00:58:26
なんかもうちょっとでもrailsと被ってたら
タイトルにrailsって書いとけみたいなノリで書いてるな
462:nobodyさん
07/08/03 01:01:07
たしかにｗ
463:nobodyさん
07/08/03 01:26:34
そのうち「生鮮食品版 rails！？」とかもう何でもrails付けときゃ売れるだろ的な
しかしまぁDBの抽象化だのDAOだのってのは
それこそもういっそ言語仕様に取り込んじゃってくれよって話だなぁ……
464:nobodyさん
07/08/03 02:50:28
URLﾘﾝｸ(www.tsujita.jp)ベンチマーク
code igniter以外遅すぎｗｗｗ
ｵ､ｵ、ｵﾜﾀｰｵﾜｵﾜｵﾜﾀｰ♪
＼ CodeIgniter以外ｵﾜﾀｰｵﾜｵｵﾜｵﾜﾀ／
♪＼(^o^) ♪
＿ ) > ＿ ｷｭｯｷｭ♪
／.◎。／◎｡／|
＼(^o^)／.|￣￣￣￣￣| | ＼(^o^)／
) ) .| |／ ノ ノ
(((( >￣ > )))) ＼(^o^)／ ((( <￣< ))))
) )
((( >￣ > ))))
465:nobodyさん
07/08/03 06:23:12
>>458
The BSD Licenseって…
普通ライセンスに"The"なんて付けないだろ
466:nobodyさん
07/08/03 09:53:47
>>465
釣りネタを探す目の付け所は悪くないが表現がやや幼稚すぎる
さらなる精進を望む
467:nobodyさん
07/08/03 09:58:12
表現の問題でなくて、Theをつけないと思ってる頭が幼稚
468:nobodyさん
07/08/03 10:07:16
日本語を話してるのにtheとかつけたら
The PHP frameworkみたいな滑稽さになるね
469:nobodyさん
07/08/03 11:10:03
へーPHP frameworkって固有名詞なんだ
470:nobodyさん
07/08/03 11:17:57
新しいバンドの名前
471:nobodyさん
07/08/03 11:20:35
なぜPHP frameworkが固有名詞？
472:nobodyさん
07/08/03 12:42:33
冠詞(The)を付けるからって勘違いしてんじゃね？
473:nobodyさん
07/08/03 15:03:22
BSD licenseのTheは固有名詞のTheだろ。
474:nobodyさん
07/08/03 15:43:51
Theで固有名詞って、いったいいつの時代の教育を受けたんだ？
固有名詞かどうかなんて考えて話すやつなんていないっつーの。
対象物を知ってるやつ相手ならThe、知らないやつならa、ってだけ。
The PHP frameworkのTheは、PHPはみんな知ってるからついてる。
The BSD licenseもBSDをみんなが知ってるからついてる。
475:nobodyさん
07/08/03 15:54:37
(ﾟдﾟ)ﾎﾟｶｰﾝ
476:nobodyさん
07/08/03 15:56:26
ザ・ガマン
477:nobodyさん
07/08/03 16:13:23
PHP frameworkもBSD licenseも一般名詞であって、固有名詞じゃない。
定冠詞theは、他の一般名詞同様、文脈と英文法に従って付けられる。
しかし日本語で話している時に、そのような文脈的なtheは普通つけない。
「俺、そのフレームワーク知ってる！」という意味で「俺、the framework知ってる！」
なんて言うのは明らかにおかしい。
もちろんThe PHP Frameworkという「名称」のフレームワークを作れば固有名詞にもなるがな。
そうでない限り、日本語の文脈でtheをつけるのはおかしい。
478:nobodyさん
07/08/03 17:03:16
なにをいっているのかわからない
479:nobodyさん
07/08/03 17:17:06
the PHP frameworkもthe BSD licenseもおかしいってことだろ
480:nobodyさん
07/08/03 17:46:39
えーっと
「The BSD Licence」というライセンス名なんだけどー……
「BSD Licence」に the を付けるかどうかなんて話はそもそも無関係なのよ
そもそも英語の名称の話をしてるのに「日本語で話してる時」って前提が既におかしいし
「ビーエスディーライセンス」という日本語名詞の話だと言い張りたいならそれでもいいけど
だとしたら皆と前提が違いすぎて会話になってないのは自分でもわからないかね？
481:nobodyさん
07/08/03 17:58:54
theの話とかどうでもいいよ
ほんとしねばいいのに
482:nobodyさん
07/08/03 19:20:34
BSD licenceでググると57,200件見つかるが
"The BSD licence"でググると7件しか見つからない
つまりそういうことだ
483:nobodyさん
07/08/03 19:55:20
しゃれにならんほどどうでも良い話題に萎え
484:nobodyさん
07/08/03 19:57:35
THE END
485:nobodyさん
07/08/03 20:55:04
> The BSD Licence の検索結果 約 1,260,000 件中 1 - 50 件目 (0.14 秒)
……？('A`)
URLﾘﾝｸ(www.opensource.org)
とか見たことあるか？
486:nobodyさん
07/08/03 21:15:20
BSDライセンスのことを「The BSD Licence」って書く奴を
きもいと思うか思わないかだけの話だから、正解はないな
487:nobodyさん
07/08/03 22:52:50
中一レベルの英語で揉めてんじゃねーよｗｗ
488:nobodyさん
07/08/04 00:07:31
でもまあそのendにあたって、 licence には突っ込んでおきたい。
489:nobodyさん
07/08/04 00:56:44
私は yu を fackします
490:nobodyさん
07/08/04 02:58:01
ファイルのキャッシュ付いてるFW多いけど
ファイル数あほほど増えるな。
しかもディレクトリ掘りまくりでduでトータルサイズ計算するのにも
やたら時間かかる。
DBに入れた方がいいだろこれ。
491:nobodyさん
07/08/04 03:37:25
古いキャッシュファイルを定期的に捨てるようにしたよ
これって常識？
492:nobodyさん
07/08/04 09:36:44
普通はcronで削除する
493:nobodyさん
07/08/04 09:45:54
お好みで。場合によるし一般論はない。
494:nobodyさん
07/08/04 17:23:21
結局、FW実装のCacheじゃなくて、PEARのCache/Cache Liteを使っちゃうな。
495:nobodyさん
07/08/04 18:37:45
使い勝手いいの？
ってか使い勝手悪い糞キャッシュしか実装してないのに
「キャッシュ実装！軽い！」とか宣伝するFW作者反省しろ
496:nobodyさん
07/08/04 22:27:45
ＦＷ実装のCacheが、処理プロセスと不可分になっちゃってるから柔軟性に
欠けるという面と、ファイルキャッシュ以外のサーバーAPI系（たとえばyoutube)の
ＰＥＡＲ実装が結局ＰＥＡＲのcache使ってるからね。どうせ導入しなきゃならないなら
最初から使わないって感じ
497:nobodyさん
07/08/06 18:54:30 HUsmqTvF
興味深い話題age
498:nobodyさん
07/08/08 09:20:09
EthnaといいPieceといいMapleといい
国産フレームワークって何でマニュアルがええ加減なやつばっかなんだ？ｗ
499:nobodyさん
07/08/08 10:23:09
ドキュメント整備ってめんどくさいから
500:nobodyさん
07/08/08 15:50:49
どの分野でもテクノロジーを文章して伝達・教育する技術や能力は英語圏は他のついづいを許さんよね。
501:nobodyさん
07/08/08 16:27:51
釣り針が太すぎます
502:nobodyさん
07/08/08 17:29:25
>>499
ドキュメントの書き方を教わらないからだよ。
日本の国語教育の問題が大きい
503:nobodyさん
07/08/08 19:16:09
仕様が固まりきってないからドキュメントにしにくいんじゃね？
ドキュメント化すると実態と乖離していきかねないから、
ちょっと曖昧なままにしておきたいっていうか。
すくなくとも俺はそういうのあるね。
504:nobodyさん
07/08/08 21:34:38
つまり面倒だと
505:nobodyさん
07/08/08 21:38:33
日本には「見て技術を盗め」という文化がある・・・のか？
506:nobodyさん
07/08/08 21:58:32
>>503
アウトラインを作っておくという文章技術上の発想がないからそうなる。
507:nobodyさん
07/08/08 22:00:49
>>506みたいに何もしないくせにしたり顔で文句言う奴ばかりいるので
真面目にやる気がしなくなるという事情もある
508:nobodyさん
07/08/08 22:06:35
>>507
まあいいんじゃね。お前のような人のせいにする奴のプログラムは誰も使わないから。
509:nobodyさん
07/08/08 22:08:01
なんでアウトラインが関係あるのかよく分からないな
ソース改変
だけの労力が、
ソースを改変＋ドキュメント改変
になるのがしんどいんだよ
まあ、ドキュメントを書くことでインターフェイスが簡素になるという
いい作用もあるけど…
510:nobodyさん
07/08/08 22:08:55
testを載せるだけでも違うけどね。
511:nobodyさん
07/08/08 22:24:39
ちいたん使ってみた。けっこう扱い易くていい感じなんだが、
MojaviやSymfonyに慣れてるとフロントコントローラが欲しくなるな。
アクションの遷移が従来通りだからなあ。よくもわるくも。
アクションといえば、action()がクラスじゃなくて関数での実装なのは、
ソースコピペする時に
ｸﾗｽ名変ｴﾙﾉﾓﾏﾝﾄﾞｸｾ
なんだと気付いた。Mojviじゃけっこうそんなクラスないぞって怒られたからな。
512:nobodyさん
07/08/09 00:05:10
>>511 さあ、つくろ
513:nobodyさん
07/08/09 00:12:52
PHPの分際でaf->getとかアホじゃね？って思う。
$_REQUEST上書きで十分。
てかPHP自体にバリデータがない時点でそこから発展する事になるFWなんてウンコ化は既定路線なんだがな。
514:nobodyさん
07/08/09 00:41:52
>>513 ウンコ！
515:nobodyさん
07/08/11 01:37:44
いよいよ政治的に大成功してきたRuby
貧民言語PHPm9 (^Д^)ﾌﾟｷﾞｬｰ
516:nobodyさん
07/08/11 06:53:19
他言語をわざわざ貶す理由が分からない。
自分が好きな言語使ってればいいだろｗ
517:nobodyさん
07/08/11 19:22:45
cakeとかMapleとか、まぁPHP用に現存するフレームワークって
MVCを実現するため「だけ」のライブラリ？
518:nobodyさん
07/08/11 20:51:28
＞MVCを実現するため「だけ」のライブラリ
が何を示しているのか理解しかねるが、
MVCの分離構造を実現するだけという意味であれば、
そのほかにもActiveRecordだのORMだのDIだの実現すんじゃね
MVCの分離構造を実現するだけでよければちいたん超おすすめｗｗｗ
519:nobodyさん
07/08/11 22:48:35
漏れんとこ、開発チームごとにレベル差があってさ、
ずっと生PHPだけで力任せに案件こなしてきていて、
生PHPじゃないっていうだけでなかなか受け付けないような
DQNぎみの連中対策がそろそろ必要なんだよね。
でもいきなり本格的なフレームワークだと学習コストが云々、
兵隊にはメンテさせられん云々……
とかなんとか管理職に言われてしまうよな。
それを避ける意味でも、
ちいたんに限らなくってもいいんだけど、
あのくらいの規模でコードの見通しの効くフレームワークで小さい案件やらせて
段階的にMVC開発に慣れさせるといいかもしれんと思ってる。
もちろん悩み易いconfig類のカスタマイズは先に片付けておいて、
あとはアクションとコンポーネントとテンプレート作るだけとなるように
兵隊向け作業手順のマニュアル書くんだけどな。
520:nobodyさん
07/08/12 00:15:54
>>518
ちいたん初耳だった。調べてみる。
> ＞MVCを実現するため「だけ」のライブラリ
> が何を示しているのか理解しかねるが、
ごめん、質問の意図と質問文が乖離してた。
まぁFWによるんだろうけど、
PHP用のFWを使う ＝ MVCサイト構築
ってことになるのかな。
つまり。そのFWでサイト構築するには、MVC方式を余儀なくされてしまうとか。
もしそうだったら、なんかそれって「縛り」だよなぁってふと思っただけ。
>>519
DQN環境乙。
何でもかんでもMVCってのもどうかと思うけど、
とりあえずそういうときはMVCとかOOPとか、
開発手法の素晴らしさをアピールするといいかもしれん。
もうしたのかもだけど。
うちは、「一時の痛みを我慢して、その後が楽になるなら」
ってことで学習コストとか割いてくれた。
521:nobodyさん
07/08/12 00:33:30
>>520
MVCサイトというのもいまいちよくわからん表現だが
そもそもフレームワークっていうのは縛りでしょ
フレームワークの提供する枠組み＝制約というのが一定のルールになって
同じフレームワークを使っている人間のコンセンサス取りやすくなったり
問題点の発見が早くなったり
そもそも問題が発生しづらくなるわけで
522:519
07/08/12 00:45:01
>>520
なるほど。言う通りですよ。一部DQNなのをなんとかしたい。
ときどき手法の説明をしたり改善策として提案してるんだけど、
従来の流れと違うといまいちピンと来ないらしい。
既存案件におわれて勉強する時間もとれてないようだし。
漏れのところでいちばん効果的だったのは、
10ページくらいの小規模な案件をあっというまに片付けて、
目の前で速度差を見せつけた時かな。
慣れれば効果あるっていうのは分かったみたいだった。
規模によってはMVCでさえ大袈裟すぎる場合や、
ビューの要らないバッチ処理やインタフェース物ももちろんあるわけで。
そこは適材適所。
本格的なフレームワークで大き目の案件だと、
開発速度以上に分業しやすさとメンテ性のためにMVC開発をするんだと思ってるんだけど、
開発速度ほど有利さを披露しにくいのが難点だよね。
523:nobodyさん
07/08/12 04:41:54
>>520
pradoっていうのが、確かMVCじゃなくてイベントドリブン型のどうのこうのって読んだな
URLﾘﾝｸ(www.pradosoft.com)
URLﾘﾝｸ(hain.jp)
ということらしいよ。
524:nobodyさん
07/08/12 04:46:34
ピースFWもイベントドリブンらしいね
525:nobodyさん
07/08/12 11:25:05
そのpradoのページを何枚か眺めただけだけど、ＭＶＣ的に実装していくんじゃないの結局は。
View部分はこうだ、って言ってるだけで、そのイベントに対応するクラスはコントローラを基底に
持つと思うぜ。
526:nobodyさん
07/08/12 12:16:16
viewにガシガシロジック書いてく時点でMVC分離じゃねーべ
527:nobodyさん
07/08/12 12:19:57
普通にやれば、結局そのview用コントローラー実装することになるんだよ。
528:nobodyさん
07/08/12 15:38:41
なるほど理解しました。おもろそうだなprado。でもコンポーネント溜まるまではちときついか
529:nobodyさん
07/08/12 16:38:41
ウェブアプリにイベントドリブンもへったくれもねーよ。
530:nobodyさん
07/08/12 17:09:33
出たな半生野郎
531:nobodyさん
07/08/14 11:16:41
んじゃこっちに
Akelos
URLﾘﾝｸ(www.akelos.org)
532:nobodyさん
07/08/15 10:43:19
>>531
このようにあえてRoRクローン風って明言した（影響を受けているとかいうんじゃなくて）ＦＷとしては、
他にどんなのがあるの？
533:nobodyさん
07/08/15 14:34:24
建てたお
【PHP】PHP on Rails
ｽﾚﾘﾝｸ(php板)
534:nobodyさん
07/08/15 14:41:17
533は何勘違いしてるんだ？
削除依頼だしてこいよ。
535:nobodyさん
07/08/15 14:57:18
PHP on Rails って PHP on Trax の旧名だよな
536:nobodyさん
07/08/18 16:49:31 XeatXWbb
はーいはい。みなさん。こんな本出ますよ。
神本ですよっと。
URLﾘﾝｸ(www.cbook24.com)
537:nobodyさん
07/08/18 18:23:53
こいつも佐久間と一緒で本出しすぎだな。
538:nobodyさん
07/08/18 20:21:23
>>536
発売したら立ち読みしてこよっと
539:nobodyさん
07/08/18 20:41:35
そしたらレポして３行で総括よろしく
540:nobodyさん
07/08/18 21:57:37
なんかドキュメント印刷しただけっぽい内容だな。
541:nobodyさん
07/08/19 23:13:36
携帯サイトに相性がいいフレームワークってある？
542:nobodyさん
07/08/20 00:12:15
>>541
何を求めてフレームワーク使おうとしているかがわからんから答えようがない
543:nobodyさん
07/08/20 19:52:44
URLﾘﾝｸ(ke-tai.org)
544:nobodyさん
07/08/22 01:33:27
フレームワーク本は予想通り、マニュアルコピペ＆彼女の他作の流用でした
545:nobodyさん
07/08/22 08:04:04 4atvg3yr
>>544
Zend_Smartyの部分なんかがっかりしたよ。
あれじゃ、Ｓｍａｒｔｙの良さ死んどる
546:nobodyさん
07/08/22 13:40:39
掲示板の投稿で
フォーム記入→確認顔面→投稿
この流れを簡単にしやすいFWないかな？
547:nobodyさん
07/08/22 14:22:32
PEARのQuickFormだか何だかは？
548:nobodyさん
07/08/22 15:33:07
一瞬いい本が出ると思ったが
マニュアルをネットからダウンロードすればいいだけの話か
549:nobodyさん
07/08/23 15:37:34 gq3i3Qc4
>>546
確認顔面というのは、投稿者の顔が不細工だとフィルタかける
っていうことですか？。FWレベルでは、そういう実装はないと思います。
550:nobodyさん
07/08/24 00:12:40
>>546
顔面はともかくethnaかな？
551:nobodyさん
07/08/24 00:42:54 YoTG53/u
なぜethnaが優位性を持つのか説明してくれ
552:nobodyさん
07/08/24 00:47:43
ふじもと神の顔面が優位(=イケメン)なのかと思った。
553:nobodyさん
07/08/24 03:46:39
>>547
QFCは死んでる。
やるだけ時間の無駄。
554:nobodyさん
07/08/25 15:41:51 m12CHPqL
QFがダメな子とは良く聞くけど、
ダメさを今一理解していない俺に、QFの機能でダメな点を教えてくれ。
QF無しだと確認画面尽きデータ更新画面作るの超面倒臭くない？
入力値のバリデートもフィルタも。
そういう時は皆QF以外の何使ってるんでしょう。
555:nobodyさん
07/08/25 15:55:04
> そういう時は皆QF以外の何使ってるんでしょう。
CakePHPなどのフレームワーク。
556:nobodyさん
07/08/25 16:40:10
QFはフォームの組み立てから入力のバリデートにHTML出力まで全部こなそうとするんで
特に入力値のバリデーションとかで
Mojaviとかのフルスタックのフレームワークに組み込みにくいという事情があった
でも今でもSymfonyとかCakeとかCIとかが持つフォームシステムで
QFほど何から何まできちんとやってくれるものはないと思う
特にバリデーションJavaScript自動生成とfreeze()あたりは
今風のフレームワークでも何らかで実装してほしいものだなー
あとQFCは死んでるしやるだけ時間の無駄だと思うｗ
557:nobodyさん
07/08/25 16:54:28
>>554
2年前の記事だけど
URLﾘﾝｸ(hatotech.org)
一時期QFが取り上げられて流行ったけど
QFだとフォームのエレメント主導の作りになっちゃうんだな
フォームにvalidationがぶら下がっちゃうっていうか
コントローラにエレメント生成のコードが入っちゃうし
あと複雑なフォームの構成になるとトリッキーなコードになりやすかった
現状のFWなら大体フォームエレメントの生成はViewHelper、
入力値のvalidationはValidatorでやる形が主流だな
歴史的にそういう経緯があって、今こうなっているということは
結局今の形がよりベターな構成だということなんじゃないかな
558:nobodyさん
07/08/25 16:55:36
>>555
>>556
自社製FWしか使った事が無くて、
それはQFを組み込んだものでして。
CIとかCakeのマニュアルを流し読み程度はしてみたものの、
面倒臭い確認画面尽きの時の画面遷移コントロールなんかがカバーされてるようには見えなくて、不思議に思ってました。
海の向こうでは確認画面あまり出さないからなのかな、とか。
フォーム要素をPHPオブジェクトと対応させるQFの発想は悪くないと思うのになぁ、とか。
まぁ、とりあえず実際にCI、Cake辺り触ってみるのが早そうですね。
559:nobodyさん
07/08/25 17:09:11
>>557
確かにフォーム要素をQFでごにゃごにゃ書くのは面倒ですね。
書き方覚えるのも。個人的にはjsと同じ書き方でやらせてくれればいいのにと思います。
560:nobodyさん
07/08/25 17:36:07
JavaScriptによるクライアントサイドバリデーションはUI的には良いかもしれないけど
信頼性は皆無なので、結局サーバサイドでのバリデーションが必要になるよね。
だからバリデーションJavaScript自動生成を好んで実装したがるFW作者は少ないと思う。
フォーム要素とPHPオブジェクトのバインディングとは少し違うけど、
HTML_Template_Flexyでのフォーム要素の扱いは知っておいて損はないかも。
561:nobodyさん
07/08/25 18:24:06
>>560
QFだとバリデーションをひとつ設定すればサーバサイドとクライアントサイドを自動的にやってくれるんで
信頼性をサーバサイドで確保しつつUI利便性のためクライアントサイドで……ってのが
とても簡単にできたのよ
（自作ルールセットではさすがにそうもいかないけど）
最近じゃクライアントサイドの利便性はAJAX使えってことになっちゃうのかなぁ
でもそれ自体をやりやすくしてるフレームワークってあるのかな
AJAX対応のASP.NETとかはそれに近いことをやってた気がするが……
562:nobodyさん
07/08/25 18:45:15 CTb1TM+m
そもそも、フォームの生成なんてするもんじゃないだろ。
それに、主要フレームワークはほとんどビューヘルパーとか用意してるけど、
実際問題、ベタ書きした方が正確だし、デザイナーにも易しいだろ。
563:nobodyさん
07/08/25 19:07:06 S/G680iY
>>562
自分もそう思う。
564:nobodyさん
07/08/25 20:34:11
QF2なんてのも出てきてる。。。
なんだこりゃ。
565:nobodyさん
07/08/25 21:31:26
>>562
フォームがDBのテーブルへの操作窓であるような概念のアプリの場合は
クラスがバリデータとかを提供する方がむしろ自然になるような設計もあると思う
QFでそれをやろうとすると、HTMLとか$_POSTとかまでQFが面倒みちゃうんで
その辺が激しく気持ち悪いことになるのが難点だけど……
HTMLについてはベタ書きよりもきちんと生成されたものの方が正確って考え方もできると思うよ
あとデザイナはフォームがどうなろうと周囲の枠だけ書けば良いような場合もあるし。
結局いつもの「適材適所で」みたいな結論になっちゃうのが残念だがなぁ
566:nobodyさん
07/08/25 21:37:02 S/G680iY
POST値に対するvalidataだけなら、既存FWのクラスで十分だよ
>>556の言う「QFほど何から何まできちんとやってくれるものはないと思う」って
具体的になにをさしてるのかわからんわ。JSとか言ってるところ見ると
仔細なチェックまでFWに背負わせようとしてるんじゃないの。そんなの
スクラッチでやったほうが確実だっての。
567:nobodyさん
07/08/25 21:38:40
手書きは不確実です。絶対にミスが出ます。
568:nobodyさん
07/08/25 21:40:44
>>566
スクラッチでやるよりも、
何もしないほうが確実ですよ？
JavaScriptはほぼ自動生成です。
仔細なチェックは当然、phpコードで書きます。
それだけで自動でJavaScriptコードが生成されるのです。
569:nobodyさん
07/08/25 21:43:58
連続で真っ赤になって書かなくてもいいのにw
570:nobodyさん
07/08/25 21:45:52
反論できないなら書かなくていいのにｗｗｗｗ
571:nobodyさん
07/08/25 21:47:01
>>569
二人に即効で反論されたからって泣くなよ。
２ちゃんねる初心者か？ｗ
572:nobodyさん
07/08/25 21:48:56
w多い人ですね
573:nobodyさん
07/08/25 21:50:24
二人の証明すべきだな。>>571は
574:nobodyさん
07/08/25 21:56:04
俺じゃないやつが書き込んだから二人というだけのことですが？
>>569は荒らすのが目的なのか？
違うのなら黙ってろ。
575:565
07/08/25 22:10:37
なんかいきなり荒れたなぁ……
べつに相手を言い負かそうとかどっちが勝ちとか考えずに
フレームワークとかフォーム処理とかの良い実装について語り合えるって程度でいいんだけどー
>>566
FWのクラスでも充分だしQFでも充分なバリデートが出来るって話でしょ。
FWの意義のひとつにはなるけどQFが不要になる理由にはならないよね。
あとQFでJSを自動生成できるのはサーバ側でできるチェックより劣るので
完全にUI利便性（POSTする前にすぐにエラーを見つけられるとかその程度）だけの問題。
576:nobodyさん
07/08/26 00:35:40
使いたいなら使えばいいと思うけど結局メンテしにくいのよQFで書いてると
フォームちょこっと変えたいだけなのに
ViewじゃなくてControllerにあるエレメント設定をいじらないといけないとか
ちょっと入力必須にしたいだけなのにエレメント設定しないといけないとか
でQFでやってるとフォームに関する全ての処理を
QFでやらないといけない感が漂ってきて
FWでMVCに沿ってるはずがだんだんQF主導のコードになっちゃうわけ
RequestもValidationもViewHelperも兼ねてるからそうならざるを得ない
多機能なライブラリが故にそれが仇となってFWに組み込みづらくなる
だからといってそれらの処理をFWによる機能とQFの機能で
中途半端に混ぜて使ってしまうともう最悪のパターンになる
だから、使わない
577:nobodyさん
07/08/26 01:05:13
QFを使うと氏ぬ
578:nobodyさん
07/08/26 01:52:27
いっそQFに合わせたFWというのはどうだろう。
webベースのエディタ画面でフォームを作成すると、
それに合わせたコードが吐き出されて、
ついでにDBのテーブルも作ってくれる。
これで名実共にWeb版VBの名を欲しいままに・・。
579:nobodyさん
07/08/26 02:03:09
フォームからDBスキーマを予想するのは無理ぽ
580:nobodyさん
07/08/26 04:06:26
>>579
マスタ系テーブルだけ先に手動で作らせておいて、
セレクトボックス、チェックボックス、ラジオボタンはそれを使わせる。
連関エンティティが必要になるようなフォームは自動生成からは切り捨てる。
idはサロゲートキー。
text=varchar
textarea=text
581:nobodyさん
07/08/26 04:53:39
すみません、恥を忍んで言いますと、私JSが全く書けないんです。
なので、JS付きのValidateしてくれるQFを見た瞬間！！！これだ！！と。
それだけなんです。JS覚えればQFなんていらないです。
でも覚えられないんです。すみませんでした。
582:nobodyさん
07/08/26 05:09:13
入力チェックのjsなんて難しくねーだろ
HTMLにjsが入るのも気に食わん
583:nobodyさん
07/08/26 05:59:51
JSでチェックするメリットはあんまりないよな
ajaxでやるならともかく
QFみたいなﾀﾞｻﾀﾞｻﾁｪｯｸは素人くさいよ
まだあるっちゃあるけど
584:nobodyさん
07/08/26 07:58:43
>>580
それはフォームからスキーマじゃなくて、スキーマからフォームでしょう？
579と逆なんだけど。
585:nobodyさん
07/08/26 08:56:04
まさかとは思うが、JSのみでValidateしてる人っていないよね。
586:nobodyさん
07/08/26 09:52:19
あくまでUIの快適さをあげるために存在する
追加の機能であるJavaScriptでの検証。
それもサーバー側でのチェックと同じ機能を
二回も書くなんて面倒。
DRYの原則に反する。
自動で生成されたら楽。
587:nobodyさん
07/08/26 10:08:32
自動生成だから使うってのはどうかと思うが。サーバチェックだけでいいし
でなきゃ、「UI」改善のための実装ならajax使うでしょ。
今時html埋め込みの単なるjs使う意味は？
588:nobodyさん
07/08/26 10:15:11
できる限り無駄な通信を避けたい時。
そんなことも想定できないほど脳が腐ってますか？
589:nobodyさん
07/08/26 10:19:05
JSチェックで削減できる通信量がどれだけあるのかって話だよな
貧者の発想という気がする
590:nobodyさん
07/08/26 11:03:26
結局サーバー側でもチェックするんだから
通信量なんか関係ないんじゃね？
591:nobodyさん
07/08/26 11:06:18
JSでチェックしてNGならsubmit止める（＝通信させない）とかじゃね？
592:nobodyさん
07/08/26 11:13:50
>>591
当たり前すぎなんだが、そんなこも知らずに話してたんか。
だから通信が発生するAjaxは論外。
結局、否定しているやつはなんもわかってないじゃねーかｗ
593:nobodyさん
07/08/26 11:19:30
>>589
> JSチェックで削減できる通信量がどれだけあるのかって話だよな
> 貧者の発想という気がする
どうやっても、JavaScriptによるレスポンスの速さを
サーバー通信が必要な方法で超えることはできんよ。
問題は通信量ではなく、すばやい反応。
そこを勘違いしていたお前の負けだ。
594:nobodyさん
07/08/26 11:42:52
なんか「AJAX=新しい=あらゆる最強」みたいな都市伝説を信奉してる人がいる気がする……
郵便番号から住所への変換とかはAJAXで利便性も上がる一例だけど
項目のrequiredチェックなんぞにいちいちAJAX使ったら利便性下がる一方じゃないかな。
httpdの受け口が増えまくるのはサーバ負荷管理的にもおいしくない。
それが問題にならない程度のアクセス数/サーバ数の予算が取れるなら
負荷の点は問題にしなくてもいい場合もあるが。
595:nobodyさん
07/08/26 12:30:21
JSチェック支持派はJSでだっさいalert出したりしてんの？
動的にDOMいじってサーバと通信した場合と同じ画面にするなら
まあありとも思うが
そこまで手間をかけるならもういいわってなるな。
596:nobodyさん
07/08/26 12:35:30
>>594
ajaxで転送量減らすこともできるよ
別にリアルタイム性だけがajaxの利点でもない
597:nobodyさん
07/08/26 13:20:43
>>595
お前言っていることが極端だぞ。
動的にDOMいじってきれいな画面を作る手間をかけるのなら
もういいやと思うんだろ？
そこで普通はもういいやってことでJavaScriptのalertを出すだろ。
１．DOMいじる
２．JavaScriptのalert（コードを別に書く必要は無い）
３．なにもしない
１番がいやだからっていきなり3番の案に飛ぶなよｗ
それに、俺ならalert(msg)の代わりにdocument.getElementById("msg") = msg;に
置き換えるだけだが？ これがそんなに手間がかかることかよｗ
598:nobodyさん
07/08/26 13:23:47
>>596
> ajaxで転送量減らすこともできるよ
転送を伴わないAjaxってJavaScriptと同じことだろｗ
> 別にリアルタイム性だけがajaxの利点でもない
操作性向上に必要なのはリアルタイム性です。
いまはリアルタイム性の高さが（通信をしない）
JavaScriptのエラーチェックの利点だねって話をしているのです。
599:nobodyさん
07/08/26 13:58:16
*'``・* 。
| `*。
,｡∩ * もうどうにでもな～れ
+ (´･ω･`) *｡+ﾟ
`*｡ ヽ、 つ *ﾟ*
`・+｡*・' ﾟ⊃ +ﾟ
☆ ∪~ ｡*ﾟ
`・+｡*・ ﾟ
600:nobodyさん
07/08/26 14:12:18
頑なにJSでのヴァリデートを否定してるヤツは単に書けないだけじゃねーのか。
別に俺は使わないが「利点がわからない」とか言ってる奴は本当に脳が爛れてるとしか思えんｗ
601:nobodyさん
07/08/26 14:38:46
最初の問題設定を改竄しちゃいけねーよ。
FWにQFを乗っけて使う煩瑣さの指摘があって、
それを打ち消すだけのメリットとしてjsエラーチェックの自動生成なるもの
が持ち上げられてるから、突っ込みが入ってるだけだろ。
602:nobodyさん
07/08/26 14:57:50
普通に>>585のあたりからJSのヴァリデートの利点そのものに疑問を抱いてるヤツいるじゃん。
そういう人に対して言ってるんですがｗ
603:nobodyさん
07/08/26 14:59:19
あぁ、ここは卑屈な捕らえ方する人ばっかだからやっぱ気にしなくていいや。
>>600と>>602は気にしないで楽しいお話を続けておくれ
604:nobodyさん
07/08/26 15:08:20
だったらはげしくスレ違い
605:nobodyさん
07/08/26 17:29:57
>>601
ちょっと誤解があるようだ。
おれが>>556で書いたのは
「打ち消すだけのメリットがjsエラーチェックにある」ではなく
「打ち消すほどのメリットではないが今のFWにも実装してほしい機能としてjsエラーチェックなどがある」なので
jsエラーチェックがなきゃﾔﾀﾞﾔﾀﾞ!と言ってるわけじゃない。
で「jsエラーチェックなんてそもそも不要じゃん」という意見が出てきたのだが
まぁそういう仕事もあるかもしれないけど、あれば便利だとおれは思うし、必要になる案件もある。
AJAX云々は完全に話がすれ違ってると思うが。
606:nobodyさん
07/08/26 18:07:32
話は変わるが俺のアイデアを聞いてくれ。
QFの利点はPHPでコードを書くだけでJavaScriptの
エラーチェックに変換してくれる。つまりエラーチェックコードを二度書かなくていいことにあるわけだが、
そのためにはaddRuleメソッドでrequiredを設定するというコードを書く必要がある。
そう、PHPのエラーチェックコードではなく、
フォームに、requiredなどの属性を設定するわけだ。
だから複雑なエラーチェックがやりにくい。
そこでだ、PHPコードそのものでエラーチェックできたら良いとは思わないか？
たとえば、if ( $value == "") {return false;} こういう感じだ。
しかしこのコードをよく見てほしい。なんとそのままでJavaScriptコードとしても通用してしまうのだ！
これを応用すれば、一つのコードでPHPでもJavaScriptでも通用するコードを作れるではないか。
つまり書くのは一度ですむんだ！ ちなみに互換性が無い部分は関数を使用することで対処できる。
607:nobodyさん
07/08/26 21:58:18
>>598
画面を書き換えずにxmlなりjsonなりのデータだけをやりとりすることで
転送量を減らすことができる
それもまたajax。
まあJSチェックをサーバプログラムと別に書くのは基本的にダサい方法だが
十分に抽象化して自動生成するならクリーンにもなりうるな。
書くのは面倒くさそうだが。
608:nobodyさん
07/08/26 22:32:58
> 画面を書き換えずにxmlなりjsonなりのデータだけをサーバーとデータを転送してやりとりすることで
> 転送量を減らすことができる
あふぉか？ｗ
609:nobodyさん
07/08/26 23:08:32
なんか文脈なしに非ajax的js過剰に擁護してんの一人だろ
もういいからどっかへ行けよ。スレ違いすぎる
610:nobodyさん
07/08/26 23:10:51
>>607
xmlやjsonってサーバーと通信するだろ普通。
そりゃサーバーと通信しないで使えないことも無いだろうけどさ、
何のためにxmlやjsonに変換するのかって話。
JavaScriptのオブジェクトそのままでいいじゃんか。
611:nobodyさん
07/08/26 23:23:21
必死です
612:nobodyさん
07/08/26 23:23:47
>>609
AjaxもJavaScriptも同じもんだろ・・・
613:nobodyさん
07/08/26 23:25:08
更に必死です
614:nobodyさん
07/08/26 23:25:37
みなさん。反論できないのがどっちかはいわなくてもわかるよね？
615:nobodyさん
07/08/26 23:28:32
互いに話が食い違ってるように見える
616:nobodyさん
07/08/26 23:30:45
そりゃ、「AjaxとかXMLとかJSONとかとりあえず関係ありそうな言葉を並べてみました。
でも意味はよくわかっていません。なにが間違っているというのですか？」な
素人が混じっているんだから無理ないなｗ
617:nobodyさん
07/08/27 00:07:28
いや、一人でやってるように見える
618:nobodyさん
07/08/27 00:25:28
>>605
じゃあそういうことでいいんじゃね。
馬鹿ひきつれて帰ってくれ
619:nobodyさん
07/08/27 00:34:50
レスを見たくないのなら自分が消えるしか方法はありません。
620:nobodyさん
07/08/27 01:26:01
なーんでそんなに相手を論破しようとがんばっちゃうのかね
621:nobodyさん
07/08/27 02:19:50
正直自前でやった方がPHPもJSもHTMLもすっきりすると思うんだが。
QF使ったソースって見辛くね？
622:nobodyさん
07/08/27 02:37:39
>>610
いやだから転送量を「減らす」って言ってるじゃん…
サーバサイドのvalidateもするんだよ、もちろん。
二人くらいのど素人が何を撃っているかも分からず銃乱射してる感じだな。
623:nobodyさん
07/08/27 02:49:11
通信回数と転送量を一緒にして、区別できていないようだな。
転送量が同じでも、PHPを1回呼ぶのと10回呼ぶのでは、
サーバーの負荷（主にCPU）が異なる。
ajax利用では、転送量よりも通信回数が意識されるところ。
624:nobodyさん
07/08/27 02:57:01
>>623
なんでそんな当たり前のこと言ったん
625:nobodyさん
07/08/27 03:11:56
でもそんなの関係ねぇ！
626:nobodyさん
07/08/27 03:49:30
∩＿＿＿∩
ノ ヽ /⌒)
/⌒) (ﾟ) (ﾟ) |／ ／ はい
/ / ( _●_) ミ／ オッパッピー
.（ ヽ |∪| ／
＼ ヽノ /
＿＿＿ / /
（＿＿＿＿＿ /
＼ ＼
) )
（ ＼
＼＿)
627:nobodyさん
07/08/27 06:53:24
oreoreFW作ってるんだが
クラス名の命名規則からファイルの位置が決まるようにするのと
ﾁﾝﾎﾟﾆｰのように事前にサーチして
クラスファイル位置のインデックスを作っておくの
どっちがベター？
628:nobodyさん
07/08/27 09:01:18
>>623
通信回数を減らしたところで、
サーバーにアクセスしたら
サーバーにアクセスしないよりも、
レスポンスは落ちるんだよ。
そのレスポンスの速さが重要だというのに。
629:nobodyさん
07/08/27 10:26:17
テトリスでも作ってんの？
630:nobodyさん
07/08/27 11:13:56
作っていませんが何の関係があるんですかねぇ？
631:nobodyさん
07/08/27 11:18:52
∩＿＿＿∩
ノ ヽ /⌒)
/⌒) (ﾟ) (ﾟ) |／ ／ はい
/ / ( _●_) ミ／ PHP
.（ ヽ |∪| ／
＼ ヽノ /
＿＿＿ / /
（＿＿＿＿＿ /
＼ ＼
) )
（ ＼
＼＿)
632:nobodyさん
07/08/27 22:54:54
今まで読んできたけど
少なくとも
>>598
> >>596
> > ajaxで転送量減らすこともできるよ
> 転送を伴わないAjaxってJavaScriptと同じことだろｗ
こいつは馬鹿な素人だと言うことはわかった
633:nobodyさん
07/08/27 22:59:33
あと、これもアフォですね
>>623
> 通信回数と転送量を一緒にして、区別できていないようだな。
> 転送量が同じでも、PHPを1回呼ぶのと10回呼ぶのでは、
> サーバーの負荷（主にCPU）が異なる。
> ajax利用では、転送量よりも通信回数が意識されるところ。
多分自分の中のAJAXの利用方法しか思いつかないからこういう発言になっちゃうん
だろうけど
634:nobodyさん
07/08/27 23:49:43
Ajax = Asynchronous JavaScript + XML だ。
JavaScriptの一種に過ぎないんだよ。 よく覚えとけ。
635:nobodyさん
07/08/27 23:56:37
ははーん
ずっと当たり前のことを言うという新手の釣りだな
636:nobodyさん
07/08/27 23:59:39
引用だけして罵倒とか、実のあるレスがほとんどねぇ。
もう2chのレベルは初心者おしえて掲示板と変わらんがな。
それでいて口は悪いんだから最悪というか・・・。
637:nobodyさん
07/08/28 00:01:45
583 名前：nobodyさん[sage] 投稿日：2007/08/26(日) 05:59:51 ID:???
JSでチェックするメリットはあんまりないよな
ajaxでやるならともかく
こいつもあふぉだな。
AJAXで使われている言語はJavaScriptのだってーの。
638:nobodyさん
07/08/28 00:03:55
もう釣りなのか馬鹿なのか分からなくなってきた
混沌としすぎ
639:nobodyさん
07/08/28 00:10:42
ajaxでチェックするってどういう意味だろ？
ajaxならかっこいい画面になる？
否 ajaxだからといってかっこよくなるわけでもないし、
javascriptでもかっこよく作れる。
ajaxならダサい標準のダイアログボックスがでない？
否 ajaxでも基本は標準のダイアログボックスだし
javascriptでも標準のダイアログボックス以外を使える。
たぶん、チェックをクライアントコードじゃなくて、
サーバーに問い合わせてやるといいたいんだろうけどさ、
そんなことしたら、サーバーと通信する分遅くなるじゃん？
640:nobodyさん
07/08/28 00:14:15
サーバーに通信しないとチェックできない項目もある。
メアドが登録済みかどうかとか。
641:nobodyさん
07/08/28 00:23:08
俺が少し整理してみる。
1)クライアントサイドのみのJavaScriptチェック
入力不足や間違いを即座に指摘できる。
2)Ajaxでサーバサイドをも巻き込んだチェック
1.の発展版。サーバサイドでしかチェックできないような項目を即座に指摘できる。
3)サーバサイドチェック
最終チェック。これは必須。
1や2は利用者の操作性をうｐする。うまく作りこめば確認画面は要らないかも。
642:nobodyさん
07/08/28 00:29:17
もうみんな閲覧条件としてJavaScript必須前提なのか。
643:nobodyさん
07/08/28 00:33:01
>>642
両方でチェックするに決まってるじゃん。
QFはサーバー側で書くだけで、自動的にJavaScriptコードを生成してくれる。
644:nobodyさん
07/08/28 00:52:05
何というwhile(1)な流れ
645:nobodyさん
07/08/28 00:56:19
はいはい。もうそのQFのJS自動生成の話いいから。
スレ違いだつーのに。
646:nobodyさん
07/08/28 00:58:15
逃げたｗ
647:nobodyさん
07/08/28 00:59:25
フレームワークがjsの自動生成までカバーするべきか否かにも繋がるので、あながちスレ違いというわけでも。
QFもフレームワークと言えばフレームワークだよね。
フォーム処理に特化した。
648:nobodyさん
07/08/30 17:06:50
symfonyとAkelosを比べた場合お勧めはどっちだろう。
誰か両方使ってみた。な人いる？
649:nobodyさん
07/08/31 01:27:24
>>648
何をどう比べる？
構成そのものは結構派手に違うと思うから、何について知りたいかによるんじゃない？
概念的な比較なのかな？
650:nobodyさん
07/09/01 04:07:45
PHP5で完全なMVC構造を維持してるコードが少ないフレームワークが欲しい
651:nobodyさん
07/09/01 04:22:30
PHP5で完全なMVC構造を維持してるコードがないフレームワークが欲しい
652:nobodyさん
07/09/01 05:18:08
完璧なMVCというものがそもそも存在しなくね？
インターフェイス間でやりとりするんだから少し混じり合うよ
653:nobodyさん
07/09/02 21:01:25
>>649
もう好きなだけ自由に比べてくらさい。
概念的な比較から、
各フレームワークのお勧めポイントとか
654:nobodyさん
07/09/02 21:26:47
さらに、その比較をどこかのwikiにでも書いてくれたら嬉しいかな。
655:nobodyさん
07/09/03 16:16:55
pieceでsubmitボタンじゃなくて、一般ボタンを使用してonClickイベントで
jsからサブミットさせても動かないんだけどなぜ？
656:nobodyさん
07/09/03 18:52:31
PEARやってみたんだけど、
フレームワークも似たようなもん？
ほしいクラスのあるスクリプトをインクルードして
それを使うってな感じでおｋ？
657:nobodyさん
07/09/03 19:31:30
おまえが呼ぶように書くのはライブラリ
呼ばれる部分を書くのがフレームワーク
まあフレームワークは大体ライブラリの側面も含んでるけど
658:nobodyさん
07/09/03 19:45:03
>>656
そんなレベルではまだはやい。フレームワークも知る必要もない。
659:nobodyさん
07/09/03 23:36:39
>>656
いや、もっと簡単。
必要なものは全てそろってる。
まずチュートリアルやってみ。
理解できたら８割習得！
660:656
07/09/05 14:29:14
チュートリアルが何かわからないので0割習得！
661:nobodyさん
07/09/05 16:23:04
>>660
URLﾘﾝｸ(cakephp.jp) どぞ！
662:nobodyさん
07/09/05 22:16:46
フレームワークを変更した人とかいるかな
今使っているフレームワークが変えても動くように設計していたりする?
ビジネスモデルはクラスとか作っておけばいいけど、viewは結構移植が難しいかな
663:nobodyさん
07/09/05 23:09:46
>>662
気持ちはわかるけど、やめておけ。ろくなことにならない。
664:nobodyさん
07/09/06 08:42:32
>>662
できたら公開してね
665:nobodyさん
07/09/06 10:13:24
意味あるのかないのか良く分からん。