uu59のメモ | メアドの妥当性をチェックしたいなら確認メールを送れ文字列だけ見て判断するな
PHP(>=5.2)でメールアドレスとURLのチェックに正規表現を使うな - メモリーの誰得なプログラミング日記 filter_varというのがあるみたいですが、これも結局は正規表現でチェックしています。速度差はそれほど期待できなさそうですし100倍くらい違ったところでそんなに頻繁に行う処理でもないだろうからどうでもいいと思います。標準で用意されてるので責任をなすりつけたい場合には便利かもしれません。 PHPのテストがどれだけ信用できるのかわかりませんが、しょせん文字列としてのチェックに過ぎないのでa@b.cとかvalid@email.addressとか、アプリ側ではエラーにしたいであろう文字列も妥当なメールアドレスとして通過します。 「aaaa」みたいに明らかにメアドじゃない文字列を弾くなど、渡されてきたメアドに確認メールを送る前の簡易チェックとして使おうにもドットが連結したメアドが実際
ネストした子のバリデーション - 出羽ブログ
ネストした子Dtoのバリデーションはやってくれない？ とりあえず検証メソッドかな。 私も以前に確認したのですが、 アノテーションによるネストした子Dtoのバリデーションは、 複雑なことは対応しないという方針に基づいて、 やってくれないのが仕様です。 あと、私も以前にネストしたDto（スコープはセッションでした）に バインドする方法を試みたのですが、以下の理由でやめました。 検証メソッドはアノテーションに比べて面倒 Dtoが持つプロパティの型がStringかbooleanになってしまうためロジックで扱いづらい チェックボックスを受ける時にハマりやすい アクションフォームのリセットメソッドに相当するものがなくて困ります。 Dtoがセッションで検索条件を保持した場合にブラウザの戻るボタンでクライアントとサーバーの状態がズレて挙動がおかしくなって悩む 自分が選択した代替手段としては、 一度アクショ
SAStrutsで独自の検証用アノテーションを作成する - i-takehiroの日記
SAStrutsで既に@Requiredなどいくつかの検証用アノテーションが利用できます。 そこで、それらとは別に独自の検証用アノテーションを作成しようと思ったのですが、 私の探し方が悪いのかSAStrutsのドキュメントなどには記述が見つかりませんでした。 仕方が無いので、SAStrutsのソースコードを追いながら、作成してみたいと思います。 SAStrutsのドキュメント内に記述がありました。以下のリンクの最後のほうを参照です。 id:higayasuo さん、ありがとうございます。 http://sastruts.seasar.org/featureReference.html#Validator 検証用アノテーションクラスを作成する 今回は、郵便番号を検証するアノテーションを作成します。 @Maskを利用すれば実現できますが、まあサンプルということで… Zip.java packa
SAStrutsでクライアントサイドバリデーション - ひがやすを技術ブログ
SAStrutsでクライアントサイドバリデーションは次のようにして行ないます。 今回は、最初のサブミットボタンを押すと、aaaのみが必須チェックがかかり、次のボタンを押すとbbbのみが必須チェックがかかるサンプルで説明します。 ClientValidatorAction.javaのソースコードは次のようになります。 ClientValidatorAction.java package tutorial.action; import org.seasar.struts.annotation.Execute; import org.seasar.struts.annotation.Required; public class ClientValidatorAction { @Required(target = "submit") public String aaa; @Required(tar
Validateの例 - 愚鈍人
seasarのSuper Agile Struts - Feature Referenceを参考に 新しいアクションの追加で作成した exsample1に、Validateの機能を追加してみる。 メッセージリソースも修正するので、ついでにJSPページの表示項目名もメッセージリソースから取得するよう修正した。 入力ページの修正 入力ページindex.jspをsrc/main/webapp/WEB-INF/view/exsample3にコピーし<html:errors>タグを追加する。 <%@page pageEncoding="UTF-8"%> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> <title>exsample3入力フォーム</title> </head> <b
SAStrutsの検証アノテーションと検証メソッドを同時に行うにはstopOnValidationErrorをfalseにする - shun_kokuboの日記
最近、javaの素人のくせにSAStruts+S2JDBCという構成でサイトを作っています。 SAStrutsはStruts経験を生かせる、という部分が長所の一つだと思うのですが、僕はStrutsの経験もありません。ですのでそもそものStrutsから勉強していく、という感じです。色々壁にぶつかりながら粛々とやってるところ。 今日ハマったのは、バリデーション部分。 検証アノテーションでは対応できないような検証には、検証メソッドを作成するとリファレンスに書いてあったので作ってみたのですが、バリデーションメソッドの実行が、検証アノテーションをパスしてからでないと実行されない。検証アノテーションと検証メソッドは同時に実行したいんですよね。 この場合は、ExecuteアノテーションstopOnValidationError属性を指定し、falseにする必要があるようです。リファレンスに載ってました。
独自のバリデータ（Validator）を作ってみる - コンピュータクワガタ
SAStrutsでは独自バリデータも作れます。 生Strutsで作っていたものがある場合には、それを流用することもできます。 今回は、あまりいいネタもなかったので、特定の数の倍数でないとエラーになるバリデータを作ってみました。 アノテーションを作る まずは、アノテーションから作ります。 アノテーションから作るのは、ここでバリデータの仕様がだいたい決まるからです。 package sample.annotation; import java.lang.annotation.ElementType; import java.lang.annotation.Retention; import java.lang.annotation.RetentionPolicy; import java.lang.annotation.Target; import org.seasar.struts.anno
SAStruts + JSONIC でバリデーションエラーをJSONで返す ： json,sastruts,seasar | メモリークラフト
JSONのリクエストのパラメータをSAStrutsのバリデータで検証してNGだったらエラーメッセージ用のJSONオブジェクトを返す必要があったので、やってみました。 まず、検証メソッド /** * JSON検証メソッドのサンプル * 検証せずにいきなりエラーを返す * メッセージのキーがJSONオブジェクトのキーになる * @return エラーメッセージ */ public ActionMessages validateFind() { ActionMessages errors = new ActionMessages(); errors.add("test", new ActionMessage("msg", "こら！")); return errors; } 普通の設定だとJSONが受け取れないので、JSON用のエラーアクションを用意します。これはActionクラスの親クラスに実装
SAStruts + JSONIC でバリデーションエラーをJSONで返す(バリデータ編) ： json,sastruts,seasar | メモリークラフト
前回の記事は検証メソッドをつかったものでしたが、今回はアノテーションを使ったバリデータによる検証でのやり方をやってみました。 @Execute(validator = false) public String jsonError() throws IOException{ HttpServletRequest request = RequestUtil.getRequest(); HttpSession session = request.getSession(); Object msgRequest = request.getAttribute(Globals.ERROR_KEY); Object msgSession = session.getAttribute(Globals.ERROR_KEY); ResourceBundle resource = ResourceBundle.g
[php]ctype関数でバリデート | うえちょこ＠ぼろぐ
PHP: Ctype 関数 – Manual 最近のフレームワークは独自にバリデート機構を持っているので昔ほどバリデートに気を使うことも少なくなりましたが、自前でバリデートすることもまだあるでしょう。一般的には、正規表現のpreg_match()やis_numeric()、is_int()などがよく使われるのですが、ctype系の関数は知らない人も居るかもしれません。 ctype関数は、C言語のctype.hという標準ライブラリに由来があります。 ctype 関数は、正規表現よりもつねに好ましく、さらに str_* および is_* のような いくつかの等価な関数よりも好ましいことに注意してください。 これは、ctype 関数がネーティブな C ライブラリを使用しており、処理が著しく 高速であるためです。PHP: Ctype 導入 – Manual とあるように、文字の種別をチェックする場
![[php]ctype関数でバリデート | うえちょこ＠ぼろぐ](https://cdn-ak-scissors.b.st-hatena.com/image/square/8d71ff5111e05619a10d29bb40d7aebaa75c8fbc/height=288;version=1;width=512/https%3A%2F%2Fs0.wp.com%2Fi%2Fblank.jpg)
どんなフォームにも使えるjQueryのフォームバリデーション exValidation :: 5509
jquery.validation.jsというフォームバリデーションプラグインを公開していますが、使える場面が割と限定されてしまうような作りだったので、より幅広く使えるようにexValidationという名前で新しいjQueryプラグインとして作り直しました。伴って仕様や使い方が異なる部分も多いので、ドキュメントとして書いておきます。ただし前半のバリデーションルール周りは同じエンジンを使ってるので、ほぼ同じです。ちなみにすごい長いです。。 ルールを割り当てる際のclass名がhogeからchkhogeに代わりました。アップデートして使う場合は注意してください。 サンプル1: エラーを右上に表示 サンプル2: エラーを下に表示 トピックス ダウンロード 使い方 1. JSファイルを読み込む 2. 基本バリデーションルール 3. select, checkbox、radio、複数項目の場合 4
tokuhirom blog
Blog Search when-present<#else>when-missing. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? ---- ---- FTL stack trace ("~" means nesting-related): - Failed at: ${entry.path} [in template "__entry.ftlh" at line 3, column 25] - Reached through: #include "__entry.ftlh" [in template "entry.ftlh" at
ctype_digit関数の罠 - hnwの日記
PHPにはctype_digitやctype_lowerなど、ctype_XXXXという関数が多数あります。本記事の話題はこれらctype関数の挙動と注意点についてです。 ctype関数のマニュアルには下記のような記述があります。 これは、256 より小さな整数が指定された場合、指定した範囲 (数値は 0x30-0x39) に収まっているかどうかを調べるために、そのアスキー値を使用することを意味します。数値が -128 および -1 (境界を含む) の間の場合、256 が追加され、その数字に関してチェックが行われます。 文字列引数を指定してコールした場合、これらの関数は、その文字列の全ての文字を調べ、その文字列の全ての文字が要求された基準に一致する場合にのみ TRUE を返します。空の文字列でコールした場合は、 PHP 5.1 より前のバージョンでは常に結果は TRUE となり、一方 5.
フォームの入力を確認するData::FormValidatorとFormValidator::Simple : blog.nomadscafe.jp
フォームの入力を確認するData::FormValidatorとFormValidator::Simple フォームから送信されたデータのチェックをするモジュールはCPANに二つあります。Data::FormValidatorと加藤さんのFormValidator::Simpleがそれ。いままでガリガリと書いていた部分をこれを用いて楽ができないかと試し中。 メールアドレスとパスワードを入れるような以下の登録画面があって、 <form> メールアドレス:<input name="mail" type="text" id="mail" size="20" /><br /> パスワード:<input name="password" type="password" id="password" size="20" /><br /> もう一度パスワード:<input name="password_co
ValidationとVerification - 谷本 心 in せろ部屋
こないだのドン引き最終回でもチラっと出た、これ。 ValidationとVerification。 言葉的には「妥当性の確認」と「検証」なんだけど、 ここでは「画面入力のチェック」と「サービスの引数チェック」って事にしておく。 図にするとこんな感じ。 Webアプリケーションのセキュリティでウダウダ言ってる問題って 実は、この2種類に分ければ、随分と上手く整理できそうなんですよね。 ときに、 フレームワーク使って開発してると、バリデーションの責務が増えがち。 だって、バリデータとロジックの双方でチェックなんてしたくないから。 だから複数フィールドバリデータとか、無理してキモい事やったり バリデータからDBにアクセスしたり、おいおい、それ何てLogic？ みたいな状況になる。 逆に、バリデータはソコソコに、ロジックできっちりチェックすると 決めてるプロジェクトも多いと思うんだけど、 そんな場合
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
SAStrutsのバリデーションメッセージ順序 - newta(にゅーた)の日記