その名のとおりJavaBeansの為のValidationの仕様であるJSR303ですが、近頃でもないですがHibernateはもちろん、その他SpringやOvalなどの周辺フレームワークの対応が進んでずいぶん使いやすくなってきました。 ところでアプリケーション作っててValidationの仕組みって毎回悩みませんか?私がJavaでWebアプリケーションつくりはじめた頃なんかだとStruts1.xが全盛期でvalidation.xml、validation-rule.xmlとか使って書いてましたが(今考えれば二度とやりたくないですねw)、今でも毎回どのチェックをどのレイヤ(アプリケーションレイヤ?ドメインレイヤ?)に持たせるかとか、データストアに問い合わせしないといけないValidationって画面の入力だけでチェックできるのとどう管理しようかなとか、色々と悩むこともしばしばです。最近D
Spring Batchでは当初、妥当性チェックにSpring Modulesを使用するのを基本にしていました。
Hibernate Validator allows to express and validate application constraints. The default metadata source are annotations, with the ability to override and extend through the use of XML. It is not tied to a specific application tier or programming model and is available for both server and client application programming. But a simple example says more than 1000 words: public class Car { @NotNull pri
こんにちは中川です。 先日、AngularJS 1.3 がリリースされましたね。 動作速度の改善や、メモリ消費量の削減などパフォーマンス面での改善もうれしいところですが、 機能的にはフォーム関連の機能強化が特にうれしく感じましたので、紹介したいと思います。 ■ ngModel.$validators https://docs.angularjs.org/api/ng/type/ngModel.NgModelController ngModel.$validators を使うと、独自のバリデーション関数を簡単に定義することができるようになりました。 以下の例のように、入力値を引数で受け取り、返り値で真偽値を返す関数を$validatorsオブジェクトに定義します。 $validatorsのキー(ここではvalidCharacters)が、エラーメッセージ表示時などの参照用に利用できます。 n
ngMessages is a new feature in AngularJS 1.3 for rending error messages in forms Forms in AngularJS are a delight to work with since they naturally work off of the basics of how forms work in HTML. The ngModel directive peacefully works with form controls and the state of a form can easily be examined using the name of the form and the name of each input control. But what about displaying error me
「そんなん簡単やろ」と思いますよね。 たとえば、「UITextField 文字数制限」でググれば山のようにブログ記事やらコードが出てくるし、Stack Overflow に載ってるコードのコピペ一発で解決しそうに思えませんか? 実は文字数制限をつけたテキストフィールドはそんなに簡単な話ではないのです。 shouldChangeCharactersInRange:replacementString: は使えない子 今回はこれに尽きます。 UITextField や UITextView のデリゲートで呼ばれる textField:shouldChangeCharactersInRange:replacementString: やtextView:shouldChangeCharactersInRange:replacementString: は使ってはいけません。 より正確に言うと、使うとき
これまで Ajax で二重ポストをしないようにするには、 DOM を操作して disable にして押せなくしたり、できないものは HTTP リクエストする前に変数に状態を持たせてレスポンスがきたらその状態をクリアしたりするといったものがありましたが、リクエストを出す処理ごとに二重ポストを防止するコードを入れなければいけないことが多く面倒でした。 もう少しスマートなやり方ないかな、と調べていたところ丁度使用している AngularJS でよい感じに解決しているブログを見つけましたので紹介します。 http://blog.codebrag.com/post/57412530001/preventing-duplicated-requests-in-angularjs AngularJS は HTTP リクエスト後に結果が返ってきてないものを $http.pendingRequests に登録
Smart constructors This is an introduction to a programming idiom for placing extra constraints on the construction of values by using smart constructors. Sometimes you need guarantees about the values in your program beyond what can be accomplished with the usual type system checks. Smart constructors can be used for this purpose. Consider the following problem: we want to be able to specify a da
How to Correctly Detect Credit Card TypeAvoid common mistakes when implementing card type detection. Most card type detection tutorials and libraries use regular expressions without references, often omitting or incorrectly detecting card types. This guide explains the card type detection process, cites sources, and analyzes the detection algorithm and user interface of Creditcard.js, a more usabl
GPLv3: free as in freedom documented on the ShellCheck Wiki available on GitHub (as is this website) already packaged for your distro or package manager supported as an integrated linter in major editors available in CodeClimate, Codacy and CodeFactor to auto-check your GitHub repo written in Haskell, if you're into that sort of thing.
Haskell for Web Developers This blog post is somewhat dated and may not reflect changes to the ecosystem since 2013. The perpetual myth persists that Haskell cannot be used for “real world applications”. Normally real world is usually left undefined in such a discussion, but can often be taken to mean that Haskell is not suited for database and web development work. Haskell has a rich library ecos
▼ [雑] メールアドレスのバリデーション崩壊のお知らせ、もしくは、全てが UTF-8 になる JANOG31 のページをつらつら見てたら気になるセッションがあった。 「メールアドレスの国際化(JANOG25からの変更点)」というものだ。(多用されているかはともかく)Web で使われるドメイン名では国際化が進んでいたけど、メールアドレスに関してはほとんど進んでいなかった印象だったのに、どうも RFC での標準化がほぼ完了したらしい。 セッションページからダウンロードできる「IETF 85 報告 DNS, 国際化関連」という資料を見てみたら、次のような記述があった。 ほとんどすべてのメールヘッダにUTF-8を許可 – メールアドレス部 <ローカルパート@ドメイン名> – Display-name, (コメント), SubjectヘッダにもUTF-8 (従来はMIME) 資料には具体例も記載さ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く