元スレ【PHP】フレームワークについて語るスレ13【総合】
php覧 / PC版 / みんなの評価 : ○
前へ
451 = :
PHPが書かれたファイルにXMLが書かれてるケースなんてほとんどないだろ
てかHTML5が出たからXMLなんてもはや下痢便以下の存在だろ
そんなもののために便利なショートタグ使わないことが許されるのは小学生まで
452 = :
正直どうでもいい。
453 = :
>PHPが書かれたファイルにXMLが書かれてるケースなんてほとんどないだろ
えっ
455 = :
PHP で RSS や SOAP の動的生成とかしない子がいる
456 = :
>>425
>通信自体は成功しているから200にしておくべき
えー、そうでしょうか。「通信の成功」って、どのことを指してます？
>XMLかJSONかわからないけど、status項目等を追加してシステム独自のエラーコードなりエラーメッセージで判断するのが普通と思われる。
そういう項目を追加したくないので status code を使いたいんですけどだめですか。
>>429
>通信自体は成功しているから200にしておくべき
>
>これは無いだろう
ですよねー。
>>432
>400 Bad Requestじゃね？
最初はそのつもりだったんですけど、仕様書によると、400はHTTP Requestの構文が違っていることを表すものなので、
validation errorを表すのには不適切ではないかとおもいました。（それで今回質問したわけです。）
457 = :
ショートタグがPHPのメリットとか言ってる人は、互換性やPEAR規約を知らないんだろうか。
少なくとも推奨されるべきものでは無い。
458 = :
http://www.studyinghttp.net/status_code#Client_Error
こちらのページを参考にした結果、422 Unprocessable Entity を使うことにしました。
このステータスコードは、たとえば送信されたXMLデータが妥当でなかった場合などに
使われるようなので、validation error のときもこれでいいだろうと思います。
以下引用：
> 422 Unprocessable Entity
>
> | 422 (Unprocessable Entity) ステータスコードは、サーバはリクエストエンティ
> | ティの内容タイプは理解でき (そのため 415 (Unsupported Media Type) ステー
> | タスコードは不適切である)、リクエストエンティティの構文は正しい (従って
> | 400(Bad Request) ステータスコードは不適切である) が、含まれる命令を処理
> | できないという事を意味する。 例えば、XML リクエストボディが
> | well-formed である (すなわち、構文的に正しい) が、意味的に誤った XML 命
> | 令を含む場合、このエラー状態が生じるであろう。
>
>
> ステータスコード 422 は、WebDAV について記述されている RFC 4918 内で定
> 義されています。
>
> リクエストに同封されるエンティティが処理できない場合に、このステータス
> コードが返されます。 例えば、上の文にあるように、エンティティ中の XML
> が妥当{valid} でない場合が考えられます。
すれちがいすみませんでした。
459 = :
>>451
＞ PHPが書かれたファイルにXMLが書かれてるケースなんてほとんどないだろ
確かに
＞ てかHTML5が出たからXMLなんてもはや下痢便以下の存在だろ
HTML5の規格は調べてないから知らないが、どうせXML文書だろ。
XMLとXHTMLの違いも分からないのか？
＞ そんなもののために便利なショートタグ使わないことが許されるのは小学生まで
非推薦のショートタグを使うことが許されるのは素人だけ
460 = :
XML宣言は必須じゃないしね。
ショートタグの何を恐れているのか
理解できない。
461 = :
>>456,458
それも違うと思うが
462 = :
PHPってバージョン4になってから以降、開発者のセンス悪すぎ。ショートタグを止めたと思ったら、gotoを導入するとか。
463 = :
>>460
未対応設定になってるサーバがあったり、
顧客の社内規約で禁止になってたりするからじゃない？
個人的にはオープンソースなスクリプトでショートタグ使ってたら、一気に醒める。
利便性より汎用性。
464 = :
>>462
それ以前からどうしようもないセンスだったと思うが。
465 = :
>>462
finally 実装しないでgotoだもんな。
しかも try/catchより goto の方がコードが綺麗になるとか言っちゃうくらいだし･･･
PHPユーザの質の低さがばればれだよね。
(ネームスペースもgotoもユーザ意見で最終決定したと思われる)
ここもいずれ、goto厨が湧いて「便利なのになんで使わないんだ！」とか言い出すんだろうね。
468 = :
すごく…自演くさいです…
469 = :
?>を書く必要があるような書き方をしたくないのでショートタグなんて絶対使いません
472 = :
ショートタグ否定派はスマーティー派かｗ
通りで・・
473 = :
スマーティー（(笑)）
474 = :
主にコード書く側の人間で率先してショートタグ使おうなんて人はいないだろう
VIEW専門の無知な奴がよく理解もしてないのにショートタグ使って俺玄人だぜ気分に浸って
>>431,433みたいな事とやらかしてしまうんじゃろうて
475 = :
ショートタグに違和感憶えない奴はどう考えてもプログラマには向いていない。
476 = :
>>421
<?=[ENTER] で <?php echo | ?> とか
<?=h[ENTER] で <?php echo htmlspecialchars(|) ?> (パイプがキャレット位置)とか
したらいいじゃん。
478 = :
えっ
479 = :
なんとｗ
481 = :
ここ本当にフレームワークのスレかよｗｗ
Smarty厨は隔離スレに帰れｗｗｗ
482 = :
ミスリードする人間に反応しすぎじゃないかな。
こうやってスレ違いに厳しくなってしまうんだけど、しょうがない部分もあるよね。
483 = :
ショートタグ自体は別に悪では無いが、
非対応環境があるから、フレームワークを作る上では敬遠されている。
バージョンアップや設定ミスで、ショートタグが動かなくなった場合のリスクを考えると、あまり賢い選択では無い気がする。
484 = :
どっちでもいいなそんな事
485 = :
ソースコード公開するなら関係するよな
でもここはフレームワークについて語るスレ13
＿_
, ‐' ´ ｀`‐、 ／￣:三}
. ／,. -─‐- ､. ヽ / ,.＝j
＿,.:_'＿＿＿＿＿_ヽ、 .! .／ _,ﾉ
`‐、{ へ 'ﾞ⌒ `!~ヽ. ! ／{. /
｀! しﾟ （ ﾟj `v‐冫 , '::::::::ヽ､/ そんなことよりフレームワークの話しようぜ！
. {.l '⌒ ﾞ 6',! / :::::::::::::::/ __
. 〈 < ´￣,ﾌ .ﾉｰ'_ , ‐'´::::::::::::::;/ （_ノ)‐-､
. ヽ.、 ` ‐", ‐´‐:ラ ':::::::::::::::: ;∠. ヽ_} ﾞヽ
,.r｀ "´ ／:::::::::::::::::::ィ´ ｀ゝ !、 /
/ / :::::::::::::::: ; '´ /´＼ / r'＼
. i ! ::::::::::::::／ 墨 | .!::::::::／ヽ､.._!ヽ. ヽ､
{ {:::::::::::;:ｲ / ∥ｉ:::::::/:::::::::::::/ ＼
. ヽ ヽ,.ｧ‐'´ /ヽ 二 ,/`ヽ、::::::::: ／
490 = :
cakeってちょっと見たけど
1テーブル1コントローラがキモすぎて吐いたわ
どんな顔してあんなの使ってるのか見てみたいものだね
491 = :
具体的に1テーブル1コントローラの何がきもいと感じてるの？
柔軟性がなさそうできもいとかそういう感じ？
492 = :
コントローラとモデルがくっついてる意味が分からないです・・
コントローラはコントローラ、モデルはモデルだろ・・
493 = :
なるほど。
くっついてると言うよりは単に名前を同じようにすることを推奨してる感じかな。
規約上では例えばuserモデルにはusers_controllerを対応させるように、って仕向けてるけど、
そのくっつき感が嫌ならhogefuga_controllerでuserモデルを使用するってこともできる。
なんかうまく書けないな…ごめんなさい
494 = :
まあなんというか492がcakeを使いこなせてないのは確実。
495 = :
Cakeが、
DB table <-> Model <-> Controller が全て１対１対応になっている
（ように見える）はデフォルトの規約のせい。
実際はどうにでもできるし、また習熟すればModel中心で
開発できるようにもなる。
496 = :
最近のフレームワークは肥大化しすぎてて、
PHPの学習コストの低さを完全に打ち消しちゃってるよね。
進化も早いから新人教育が本当に面倒くさい･･･。
497 = :
>>496
そもそもお前は考え違いをしてる
フレームワークは素人が使うもんじゃなくて
それなりに習熟した奴が工数を減らすために使うんだ
だから学習コストが必要になるのは当たり前
498 = :
そうなの？
工数減らす事より、コーディング品質を上げる為に導入って会社の方が多い気がするけど・・・
規模が大きければ大きいほど、工数の大半はビジネスロジックになるから
フレームワークで減らせる工数なんてたかが知れてない？
逆に無謀なカスタマイズを要求されて、時間と技術を無駄にしている気すらある。
499 = :
フレームワークってのはぶっちゃけテンプレートの集合であって
中身と使い方を理解しなければ使い物にならないんだぞ
500 = :
よくsymfonyの説明で「このフレームワークは大規模案件にも対応できる！」って書かれてるけど、
具体的にどの辺りが大規模向けなの？コントローラとかのディレクトリが階層状態になってるから
ファイルが多くなっても大丈夫、とかだけじゃないよね？
みんなの評価 : ○
php一覧へ類似してるかもしれないスレッド
- 【PHP】フレームワークについて語るスレ10【総合】 (1001) - [98%] - 2008/8/24 19:04 ○
- 【PHP】フレームワークについて語るスレ10【総合】 (1001) - [98%] - 2008/12/23 16:48 ○
- 【PHP】フレームワークについて語るスレ12【総合】 (994) - [98%] - 2009/3/19 13:46 ○
- 【PHP】フレームワーク CakePHP 3ホール目【本命】 (1001) - [59%] - 2008/6/19 7:19 ○
- 【PHP】セッションについて語ろう！【PHP】 (829) - [58%] - 2018/6/27 23:16 ○
- 【PHP】フレームワーク CakePHP 4ホール目【v1.2】 (1001) - [57%] - 2008/12/19 21:06 ○
- 【PHP】フレームワーク CakePHP 6ホール目【v1.2】 (933) - [57%] - 2009/8/19 2:06 ○
- 【PHP】フレームワーク CakePHP 5ホール目【v1.2】 (985) - [57%] - 2009/3/7 4:53 ☆
- 【PHP】フレームワーク CakePHP 7ホール目【v1.2】 (1001) - [57%] - 2010/3/18 1:18 ○
トップメニューへ / →のくす牧場書庫について