もう好みの問題だな

それだとApacheに別の設定を加えないと行けないじゃん。

俺も好みだと思うよ。けど、記号が少ない分、見た目が良いぐらいしかメリットないじゃん。後はどこまで効果があるか分からないSEO対策か。
開発効率落としてまでやる事じゃないと思うけど、それがこだわりだって言われれば、そりゃ勝手ではあると思う。

>>902
.htaccessで済む。まぁ許可されていればの話しだが。

> 画面とURLのマッピング表を参照しなければ、クエリストリングが取り出せなくなるのは、開発性の低下。

フレームワーク使っているのなら、わざわざクエリストリングを直接弄るようなことはないだろうに。
>>901に同意。俺は/区切りの方がスッキリする。

意味のない区切り出なければ/で区切るのが自分の中での最適解

画像のサムネイルをキャッシュする場合は/区切りだとフェイクできるな
画像加工済みであれば、ファイルが存在するからそれを返して
まだであれば、加工して保存後それを返すって感じで

mod_rewriteだって、.htaccessで出来るだろ。
例えばhttp://example.com/news/2008/12/18だって、年月日の順で引数が渡されることを把握してなければいけない。
こんなのすごくくだらない。
func(2008,12,18)ってプロトタイプよりfunc(array(year=>2008,mon=>12,day=>18))の方がメンテナンス性の高いプロトタイプだよ。

symfonyだと名前を付けられるよ
順番変更になってもルーティング弄れば全部反映されるし
ただパフォーマンス的にコストがちょっとかかるけど

>>907
いや、>>904では、「mod_rewrite必須。でなければ、Apache別設定必要」という意見に答えたまで。

> こんなのすごくくだらない。

だからくだらないかどうかは好みの問題でいいんじゃね。
メンテナンス性も大事なのはわかるが、糖衣構文と同じで慣れもあるし。

>>896

うーん。。そういうのが>>877が言ってる
プログラマ的視点ってことじゃないかなぁ。。

URLは場所やリソースを表すって意味じゃ
階層的にで表現できるものは/区切りがキレイな感じがする。

year=2008&month=12&day=18
ならまだしも
month=12&year=2008&day=18
って、なんか気持ち悪くない？

RESTにちょっと興味あるからかも知れんけどｗ

ようやくrestという単語が

ここでクエリクエリ言ってる人はrestを一通り勉強した上で言っているのかどうか気になる

一昔前の感覚から抜けきれないプログラマさんとしか思えない

>>910
それはRESTと全く関係ないでしょう

>>911
RESTだからpathinfoってのは違うよ。
RESTだってquerystringで基本処理することは問題ない。

なにか、910も911もRESTをちゃんと勉強してから、有意義なコメントを求む。

以下、RESTバスワード問題についてに議論が移ります。
てか、本当に話題なんでもいいのなｗ

ZFって速いん？
低機能だから速そうではあるけど

RESTfulにするなら、階層構造を使うべきところは階層を、
そうでないところはクエリ文字列をつかうべきだよね。

なんかお前ら、どっちかしか使わないみたいな二元論にハマってないか？
使い分けてナンボでしょこういうのは。

http://.../news/08/12/18?query=money

なんて分かりやすいじゃないか。

大体、
・ステートレス
・PUT、DELETEを使え
って時点で、RESTfulにこだわってたらWEB APIは作れても普通のWEBアプリは無理だろ。
大体、RESTって認証はどうするんだ？ステートレスってぶっちゃけGET以外は非現実的じゃないの？
参考にするのはいいが、どうせRESTfulにはならないんだし、URLも違う視点でいいよね。

http://sourceforge.jp/magazine/08/12/08/0347234
最適化したブートストラップファイル「Yiilite」を利用時、1秒当たり最大427のクエリを処理できるという。

サーバのスペックも書かずにこの数字って
何か意味あんのか？？？

>>916
REST的概念にしたがってコードを書くことをRESTfulって言わないの？
RoRとかRESTful謳ってるけど？
>>917
select 1;

>>919
scaffoldはそうなってんじゃね？
Ruby詳しくないから深く突っ込めないけど。

CRUDと混同してたorz

>>910
海外じゃじゃ12/18/2008って日付表記もメジャーだよ。12や18が何を意味するのか、コードの中を見ないと判断つかない。

でもURLでその順で表記することはまずありえないよなｗ
2008年のなかの12月のなかの18日～みたいに書かないと階層化になんないし

yiiってpdoベースだけど、pdoって何かバグあったよね？

ないよ

あったよ

なんだっけ

ほら、あれだ

タグ理解ｗｗｗ

pdo 不具合 に一致する日本語のページ 約 8,080

何この糞ライブラリ

ここは呆け老人の巣か？ｗ

てのはいいとして、>>930
GoogleかYahooか知らんが、

　PDO 不具合 (7,850) / PDO (346,000) ・・・ 2.27%
　PEAR DB 不具合 (9,470) / PEAR DB (115,000) ・・・ 8.23%
　PEAR MDB2 不具合 (3,440) / PEAR MDB2 (45,000) ・・・ 7.64%
　
　JDBC 不具合 (39,700) / JDBC (161,000) ・・・ 24.65%
　ODBC 不具合 (37,400) / ODBC (411,000) ・・・ 9.10%

　（上記全てGoogle 日本語ページ）

むしろ優秀じゃね？そうでなくても、ただ単に普及率や話題性が数字で出てるだけじゃねーかと。
JDBCがなんか笑えるけどなｗｗ

まぁ、不具合の話題にPDOその他の話題が含まれてる、みたいな
全く関係ないヤツが殆どなんだけどな

まぁ確かに不具合もあるだろうよ。
今度PHPとSQL Serverなんだが、PDO_DBLIBの完成度とか微妙そうだ。
今からgkbrだ。

クエリて基本的にＰＯＳＴで飛ばしたときのパラメータデータと認識してるのだが。。。
ＧＥＴで飛ばした場合はクエリとはいわない

何その思い込み

これはまた斬新な説だな

俺の場合はソケットプログラミング的発想だからな

なんだか俺の間違いくさいからクエリの話はもう終わりにしよう

>>938
そもそもそれの事をクエリと呼ぶのが間違い。
ちゃんとクエリ文字列とかクエリストリングと言いなちゃい。

アクセス解析の効率はURL決定に影響しないのじゃろか

確かに、クエリパラメータが順不同になる様な状態なら、アクセス解析の効率は落ちそうだねえ。
でもそれが設計にそれほどの影響を与えるかどうかは・・・正直そこまで気にしてらんねｗとか

順不同だと効率が落ちる？頭イカれてるのですか

Apacheのログ解析みたいな処理の場合、頭から順にパス区切りでページが特定できる方が、
効率よさそうな気はするが。
list.php?q=hoge&page=2&cate=3とかなってるより、
list/cate/3?page=2&q=hoge の方が楽そうだなーとかは感じる。
実際はどうかわからんけどな。

気がする（笑）

symfony以外のカスFWってエラー時のスタックトレース画面がショボいよねｗ

>>943
気がするではなく自明だろとか書くと、仮に大嘘でもそのまま飲み込む奴は出てくるんだけどな
書き方としてはその方が2ch向きかな

>>946
それは>945見たい書き込みのことか？

アクセス解析くらい自作しろよ。効率化とかしょぼい解析つかってるのかな

>>948
車輪の再発明

自作(笑)