1

Rails 3 アプリでいくつかのフォーム ビューを作成していますが、フロント エンドとバックエンドで DRY の方法でフォームを検証するために他の人が何をしているのか疑問に思っています。

もちろん、Rails バリデーションなしでバックエンドでのバリデーションを回避する方法はないようです。それを知っていると、フロントエンドで同じバリデーションを書くことはあまり DRY ではないようです。2 か所でバリデーションを書くことについての他のスレッドを読んだことがありますが、それを行う本当に正当な理由がない限り、私はむしろそうしたくありません。

レールの魔法を知っていれば、フロントエンドとバックエンドの両方を DRY で検証するシンプルで簡単な方法があるかもしれませんが、私はまだそれを発見していません。おそらく検証の宝石ですか？

したがって、User モデルでバリデータ メソッドを呼び出すフロント エンドで ajax を使用するとよいと考えています。たとえば、クライアント エンドのユーザー名フィールドは、jquery キーの押下をリッスンし、フィールドの内容を「checkuser」(またはそのようなもの) というユーザー コントローラー メソッドに送信します。モデルごとに 5 つ以上のフィールドがあることを考えると、コントローラーに多くの余分なフィールド チェック メソッドが必要になる可能性があります...あまりにも醜いですか?

このようにすることについて知っておくべき注意事項はありますか？JavaScript を無効にしているユーザーについて本当に心配する必要がありますか?

4

1 に答える 1

1

ASP.NET のバックグラウンドから来て、この質問に答えます。ですので、多少の誤差はご容赦ください。

ASP.NET には、要するに次のような DataAnnotation の概念があります。検証されたすべてのクラスに対して、「Required」や「MinLength(8)」などの属性に関してメタデータが指定されます。これにより、DRY 検証が提供されます。クライアントではこれらは jquery 関数に自動的にマップされ、サーバーではランタイムによって使用されます。

ちなみに、ほとんどの場合、両側の検証は必須です。これにより、過剰なサーバー負荷 (クライアント側で検証する場合) を防ぎ、データベースへの不正なデータ挿入 (サーバー側で検証する場合) を防ぐことができるからです。

簡単なグーグル検索の後、このso postに記載されているように、レールにも同様のアプローチが存在するようです。

于 2012-04-16T07:14:29.190 に答える