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

【PHP】フレームワー� ..

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
＞Wikipedia項目ﾘﾝｸ
好みのものを選んでくれ

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の原則に反する。
自動で生成されたら楽。

次ページ