のくす牧場
コンテンツ
牧場内検索
カウンタ
総計:126,368,513人
頁
昨日:no data人
頁
今日:人
頁
最近の注目
人気の最安値情報

    元スレ【PHP】フレームワーク CakePHP 17ホール目【v2.4】

    php覧 / PC版 /
    スレッド評価: スレッド評価について
    みんなの評価 :
    タグ : 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。
    ←前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで

    851 = :

    >>848
    エラーがなければ送信ボタン押すってやつ？
    入力項目が多いと重くなりそうだし、汎用性も低いんじゃないか？

    852 = :

    >>846
    指定したレコードだけでなく全てが破壊されるFWは他に見たことないな…

    853 = :

    >>848
    requiredとかありふれた形式チェックくらいは、クライアントでやってもいいんじゃね。
    開発工数ったって、そんなのほとんどないに等しいだろ。

    854 = :

    双方に同じチェック実装するのがなんかだかなあ

    855 = :

    >>854
    俺も思う。

    859 :

    >>854 >>854
    JavaScript でチェックなんかしなくてもサーバサイド一本にすると
    凄く開発効率があがるよ。マジオススメ。

    両方チェックとか馬鹿の極みだろ。

    860 = :

    >>859
    それ、開発効率が上がるって言わねえよ
    単に要件を下げてるだけだ

    861 = 859 :

    >>860
    じゃー、お前はクライアントとサーバサイドで同じ処理をガリガリかいてろ

    863 = :

    サーバサイド一本って、それ普通じゃないの？
    普通というか正当なCakeのバリデーションというか。
    そこから凝るとAjaxを使ったクライアントサイドになるわけで。

    864 = :

    そもそもサーバサイドのバリデーションを省略することがありえないからな

    868 = :

    とりあえず、HTML5だけでやれるものでもやったらいいじゃん。

    869 = :

    クライアントでのバリデーションが要件次第って理解できない奴はそういう仕事をやった事ないだけか、もしくは普段低品質な物を納品してるだけなんじゃね？ほっとけよ

    870 = 859 :

    クライアントでバリデーションを幾ら入れたって
    サーバサイドに入れなくちゃ意味ねーだろ。

    871 = :

    噛み合ってないなあ

    サーバサイドに入れるのは大前提で
    UIの質の向上のためにクライアントサイドにも実装するかどうかってことでしょ？
    入力時にリアルタイムでバリデーションするとかそんな感じの

    その上で実装方法としてAjaxでサーバサイドのバリデーションを使いまわす方法と
    クライアントでJavaScriptで同じバリデーションを書く方法があるって話

    873 = :

    >requiredとかtype属性つけるだけで
    見たところその前提で話してるのは少数派
    簡単なチェックだけクライアントサイドでも実装すればいいという意見はもっともだけど

    他はJSで書かないといけないような
    もっと複雑なチェックも含めて話してるんじゃないのか？

    874 = :

    根本的にクライアント側からのHTTPリクエストなんていくらでも変えられるから
    クライアント側のチェックを信用せずサーバ側の実装が必須ってのは前提としてOKなんだよな？
    これは仮にHTML5に対応しないブラウザがこの世から消滅したところで変わらない

    だからクライアントのバリデーションを実装する主な目的は
    セキュリティやデータの正確さの保証ではなくUI・UXもしくはサーバ負荷の低減
    早い段階で（サーバを煩わせずに）ユーザが正しくない入力に気付くことは必須ではないが有用だってこと


    仕事なら要件次第というのもその通りだろうし
    HTML5の属性で実現できる程度なら常に書いておけというのもわかる


    各自のイメージしている仕様や前提が違うだけだよな

    875 = :

    あとはクライアントサイドならレスポンスが早いというメリットもあるね

    クライアントサイドのバリデーションはなくてもいいけど、あったらうれしい
    そんな感じなのはみんな分かってると思うけど、そうじゃないのかなー？

    876 = :

    >>875
    俺は、あなたと同じ感じ。
    あったら嬉しい♩

    877 = :

    そう、レスポンス
    それが分からない奴はその程度の品質の仕事しかしてないって事

    878 = :

    うわあんあ！プログラム全部作り直してーって思った時どうする？
    我慢して作り続けるか、一から作り直すか。

    879 = :

    >>878
    作ればいいじゃない

    880 = :

    最近日本語が読めない人がレスを延ばしてるのな

    881 = :

    テストケースで、今週の日付を返すメソッドをテストする時どうする？
    テスト側でわざわざ今日の日付を取得してでもやるべきなのかな。

    882 = :

    なんかそれ簡単にするPHPの追加機能なかったっけ

    883 = :

    >>881
    テストケースがあるならやらないとダメなのでは？
    テストケース作った奴に聞け

    884 = :

    >>883
    テストケースを自分で作ってるんだけど、
    テストするためにメソッド追加するのは本末転倒だし。

    885 = :

    モック使うだろ普通

    888 = :

    >>886
    >>886
    ありがとうございます！
    やってみます。

    889 = :

    githubで配布されてる、timecopってライブラリいいよ。コアの時刻系関数を全部上書きされ、モック日付を設定するAPIが追加されるので、今日があたかも昨日かのようにテストできる。結構な規模のシステムで1年くらい使ってるけど、特にハマりどころもなかったよ。

    890 = :

    Rubyのあれの移植か
    ライブラリじゃなくてエクステンションだね

    891 = :

    そうだね。すまん。

    893 :

    無理ちゃうか？

    895 = :

    PHPもフレームワークも関係ありませんよ？
    Windows板に行きましょう

    898 = :

    サービスの内容による。

    少なくとも想定する会員数と画像の枚数、
    会員毎の画像以外のアセットの有無、
    あるなら何がどの程度か、などがないとなんとも言えない

    899 = :

    サブドメイン　http://img.example.com/
    データベースにBLOB型でぶち込む

    と言う手もあるぞよ


    ←前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / php一覧へ
    スレッド評価: スレッド評価について
    みんなの評価 :
    タグ : 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。

    類似してるかもしれないスレッド

    トップメニューへ / →のくす牧場書庫について