JSFでエラーのある項目の背景色を変える - じゃばらの手記
さて今回はJSFで「エラーのある項目の背景色を変える」をやってみます。 Strutsにある機能だし、これくらい簡単にできるだろう、と思ってたら・・・けっこうめんどくさいことになっています。 基本的なアイデア 標準で提供されているh:inputTextを使って試してみます。 本来エラー項目の見た目を変えるにはclass属性を指定するんでしょうけど、ここではコード量を減らすためにstyleでいきます。 バッキングビーン（とはもう言わないのかな？）のメソッドで入力値が妥当かどうかを判定して、style属性値を変えればいいでしょう。 XHTMLは以下のように記述しました。 <h:inputText id="value" value="#{hogePage.value}" style="#{hogePage.valueStyle}" required="true" /> style属性値でバッキング
私のBeanValidationの使い方(Java EE Advent Calendar 2013) — 裏紙
このエントリは Java EE Advent Calendar 2013 の3日目です。 昨日は @matsumana さんのご担当で JAX-RS + mustache - @matsumana の技術メモ でした。 今回はBeanValidationの自分なりの使い方をご紹介します。 その前に BeanValidationてなんや？という方は JSR 349 の仕様を読むと良いでしょう。 200ページ超えてますが半分以上コードっぽいのでそんなにしんどくないんじゃないかと思わなくもないけどどうでしょうか？ もしくは「BeanValidation しんさん」でググると良いですよ。 本題 BeanValidationではフィールドやgetterに@NotNullとか@Sizeとかアノテーションをモリモリ付けてバリデーションするわけですが、調子に乗ってるとすぐアノテーション地獄になってキツいの
InfoQ: JavaEE 6のBean Validationがエンティティ バリデーションのメタデータモデルとAPIを提供
あなたにとって重要なトピックや同僚の最新情報を入手しましょう最新の洞察とトレンドに関する最新情報を即座に受け取りましょう。 継続的な学習のために、無料のリソースに手軽にアクセスしましょうミニブック、トランスクリプト付き動画、およびトレーニング教材。 記事を保存して、いつでも読むことができます記事をブックマークして、準備ができたらいつでも読めます。
2008-04-17
1html = 1Page、ユースケース=ディレクトリ という分かりやすいTeedaのページ駆動開発をSAStrutsで挑戦してみました。 SASturtsの場合は、1html = 1Pageではなく、1JSP = 1Actionですね。 今回は、pageという名前のユースケースを想定してみました。 作成したモジュールは次のとおりです。 exercise.action.page.FromAction.java exercise.action.page.ToAction.java exercise.action.page.AbstractPageAction.java webapp/page/from.jsp webapp/page/to.jsp AbstractPageAction.java は pageユースケースのための FromActionとFromActionの共通親クラスです。
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
コードリーディングメモ バリデータ編 - wyukawa's diary
struts-config.xml <plug-in className="org.seasar.struts.validator.S2ValidatorPlugIn"> <set-property property="pathnames" value="/WEB-INF/validator-rules.xml"/> </plug-in> S2ValidatorPlugIn#initResources() resources = new S2ValidatorResources(streamArray); まず上記のようにS2ValidatorPlugInでS2ValidatorResourcesをnewしセットする。 このresourcesはapplicationにsetAttributeされる。 その後ActionCustomizer#setupValidatorでアノテーション（例：
JSR303 Bean Validation initial draft released - よねのはてな
花見日和の今日この頃、花見にもいけずにj-waveを聞きながら仕事しているちょっとキモ目のよねむらです。 さて、Bean Validationのinitial draftがリリースされました。 JSR 303はJava Beanオブジェクト用のValidation機構、メタデータモデルを実現する目的で発足。 このAPIを使用することで、Java Beanのプロパティの検証条件をアノテーションで設定し、実行時に統一的な方法でそれを検証できるようになります。 draftからのexampleをいくつか。直感的に分かるかと思います。 Chapter3 Constraint declaration and validation process @zipCodeCityCoherenceChecker public class Address { @NotNull @Length(max=30) pr
出羽ブログ ～はてな版～ - [Teeda]２つの入力値が異なっている時にバリデータエラーにする方法
例えば、「メールアドレス(email)」と「確認用メールアドレス(emailConfirm)」を入力してもらって２つの入力値が異なっている場合に、バリデータでエラーにするにはどうすればよいか？ 以下のような感じでTEqualValidatorを使えば良い。注意点として、HTMLの出現位置が後の方のプロパティにアノテーションを仕掛ける必要があります。（1.0.10時点ではTigerアノテーションは存在しないので、定数アノテーションを使う。） public static final String emailConfirm_TEqualValidator ="targetId=email"; private String email; private String emailConfirm; /* アクセッサメソッドは省略 */ PS. 今日はこれが上手く動作せずに多くの時間を費やされてしまいま
2007-08-08
メモ程度にサンプルを書いておく。 HTML側 <span id="allMessages" /> Pageクラス側 FacesMessageUtil.addErrorMessage("E0000001"); Object[] args = {"XXX", "YYY"}; FacesMessageUtil.addErrorMessage("hogehoge", args); プロパティファイル（appMessages_ja.properties）側 E0000001=検索結果がありません。 hogehoge={0}は{1}である！ ※ appMessages_ja.properties は Doltengが自動生成してくれています。 ブラウザの出力 * 検索結果がありません。 * XXXはYYYである！ Teeda Coreのteeda-core-1.0.x.jar を解凍すると javax
バリデータのアイデア - 谷本 心 in せろ部屋
以前、 http://d.hatena.ne.jp/cero-t/20070622/1182530354 で書いてたバリデータを実現するためのアイデア。 こんな感じで記述します。 <input type="text" id="year" m:label="年" m:value="#{xxxDto.year}" /> <input type="text" id="month" m:label="月" m:value="#{xxxDto.month}" /> <input type="text" id="day" m:label="日" m:value="#{xxxDto.day}" /> <span m:inject="s:validator2" m:binding="#{dateValidator}" m:targetId="year,month,day" m:eventId="doXxx
複数フィールドバリデーションは、ラベルをバリデータが持った方が良い - 谷本 心 in せろ部屋
最近、複数フィールドバリデーションを、実案件でモリモリ使っています。 具体的には、複数フィールドに分かれた「年」「月」「日」に対して 全部入力されなかったらスルー どれか入力したら、他が一つでも入力されていないエラー 全部入力されたら、存在する日付かどうかを確認する という感じです。 そんな事をやっていると、タイトルの件に気付きました。 例えば、こんなバリデーションです。 生年月日 <input type="text" id="year" m:label="年" m:value="#{xxxDto.year}"> <span m:inject="s:validator" m:binding="#{multiFieldDateValidator}" m:groupId="birtyday"/> </input> <input type="text" id="month" m:label="月
おおたに6号機の春なりかけ。 - [Teeda]Validator/Converterをまとめる
そういえばいつか書こう書こうと思ってましたが、 Teedaでは、ValidatorやConverterをまとめて記述することが出来ます。 これは特に定数アノテーションしか使えない場合に威力を発揮します。 定数アノテーションは若干面倒だし、タイプミスする可能性もあるので。 サンプル実装を下記に示します。 まずはValidatorChainを継承して、Validatorを作ります。 （クラス名を本当はXxxValidatorChainにしたいのですが、 たぶんS2のValidatorのデフォルトの規約上見つけられない気がするのでXxxValidatorとします） public class AddInputPageValidator extends ValidatorChain { private TRequiredValidator requiredValidator; private TLe
![おおたに6号機の春なりかけ。 - [Teeda]Validator/Converterをまとめる](https://cdn-ak-scissors.b.st-hatena.com/image/square/8912040fa35b10a97b5484595c5d5e88b24949ba/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F17680117127031179480%2F17680117127031261190%2F1555336136)
DynamicValidator
DynamicPropertyのように、動的にValidatorを変えたい場合のために DynamicValidatorを実装しました。 対象のコンポーネントのid+Validatorのgetterで Validatorを動的に置き換えて使うことが出来ます。 その際アノテーションで指定したValidatorは無視されます。 サンプルコードは下記のようになります。 public class DynamicValidatorPage { // これらは動的なValidatorが定義されている場合、無視される public static final String aaa_TRequiredValidator = null; public static final String aaa_TLengthValidator = "minimum = 1"; public static final St
【コラム】Java API、使ってますか? (8) アノテーションでバリデーション - JSR 303: Bean Validator | エンタープライズ | マイコミジャーナル
JSR 303: Bean Validator 既報の通り、ついにエンタープライズJavaの次期バージョンであるJava EE 6の仕様策定がJSR 313としてスタートした。本連載でも時期を見てJSR 313やそこに含まれるコンポーネントJSRの詳細を取り上げていく予定だが、エンタープライズ分野に携わる開発者はjcp.orgなどで公表される情報に目を光らせておくといいだろう。 さて、今回もJava SE 7に導入が予定されているAPIを紹介する。Java SE 7への導入が検討されているAPIにはアノテーションを活用したものも少なくない。本来ならば複雑な設定を必要とするような機能も、アノテーションを利用することで容易に利用できるようになるため、この流れは必然と言えるかもしれない。今回はそんなアノテーションを活用したAPIのひとつである「JSR 303: Bean Validator」を取
ドコモのRFC違反アドレスを通すCommons EmailValidator拡張
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
Explore Online Latest Jobs
As comprehensive our website, constructed by best professionals with Academic Writing, Assignment Writing, Dissertation Writing, Personal Statement, Thesis Writing, Finance writing, HR Writing and HR Manuals, Technical writing, Article writing background. We are confident to our contributions with organization/company would prove to be lasting. We Confident, experienced and drive could enable to
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
