サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
iPhone 16
hayassh.hatenadiary.org
Wicket1.5はすでにリリースされているのですが、JavaEE6(正確にはServlet3.0)で導入された機能にはまだデフォルトでは対応していません。*1 しかしWicket1.5を使っている人の中には「web.xmlなんか書きたくねー!」とか「どうせやるなら最新のJavaEE環境でしょ」と言う人ももしかしたらいるかもしれない。そんな人にうってつけなのがWicket-stuffの1モジュールであるwicket-servlet3です。こいつを使えばweb.xmlなしで快適なWicket生活を送れること間違いなし! ということで使い方です(maven前提) まずはpom.xmlにwicket-stuffのrepositoryの追加をします。 <repositories> <repository> <id>wicketstuff-core-releases</id> <url>https:
前回はテストメソッド実行用Statementクラスを直接拡張しましたが、今回は@Ruleアノテーションを使った拡張方法のエントリーを書いてみます。 JUnit4.7以降のバージョンには@RuleというアノテーションとMethodRuleというインターフェースが用意されています。 (11/2 追記:4.9以降はMethodRuleが非推奨になっています。MethodRuleの替わりにTestRuleというのが出来ているので4.9以降を使用する場合はTestRuleを使うようにしましょう。インターフェースのシグネチャが多少違いますが、やってることは同じです。) JUnit4.7以降はMethodRuleの代表的な実装としてExpectedExceptionがあります。こやつはテストケース内での例外をテストしてくれるやつですが4.6までだと @Test(expected=IllegalArgum
面白いライブラリを見つけたのでメモ。 lombokというライブラリで、こいつが何をするかというとアノテーションを付けるとアクセサ(getter,setter)やhashCode、equalsやtoStringがバイナリレベルで自動生成される(ソースコード上には現れない)というもの。Stream系のclose処理も自動でやってくれちゃう優れもの! Project Lombok Java の冗長性を排除する手軽な方法 NetBeansでlombokを使う - Sacrificed & Exploited 環境に関してですが、NetBeans7+Mavenの場合はlombokの依存性をpomに追加するだけで簡単に使えるようになりました。 pom.xml <dependencies> <dependency> <groupId>org.projectlombok</groupId> <artifa
以前に書いたJUnit4の拡張方法に関してコメントにて質問があったので4.5以降のバージョンを書いておきます。せっかくコメント頂いたのに全然気づかずに無視したみたいな形になって申し訳ありませんm(_ _)m まず、やりたいことの前提として「テストクラス内において特定のテストケースのみで事前処理や共通チェックを行いたい」と言った場合に、どこらへんを拡張すればよいかを以前書きました。しかし、JUnit4.5からはJUnit4ClassRunnerは非推奨になり4.8.2時点ではクラスも削除されています。なので4.8.2ベースでエントリーし直しをしてみます。 まず、独自のアノテーションを作成します。 @Retention(RetentionPolicy.RUNTIME) @Target(ElementType.METHOD) public @interface MyAnnotation { }
JPAで*1エンティティー間の多対一のリレーションを表現する@ManyToOneですが、こやつの振る舞いがベンダー間でちょっと違うようなのでメモしておきます。 振る舞いの違い どう違うのかというと、参照先のエンティティが物理的に存在しなければ取得時にEntityNotFoundExceptionをthrowするかどうか。 例えば下記のテーブルとデータがあるとします。 EMPLOYEEテーブル EMPLOYEE_ID NAME 1 Hoge 2 Foo 3 Bar EXPENSEテーブル EXPENSE_ID AMOUNT EMPLOYEE_ID 1 130 1 2 930 2 3 2,340 4 EXPENSEテーブルのEMPLOYEE_IDとEMPLOYEEテーブルのEMPLOYEE_IDとの間には論理的な参照が存在します(物理的な制約(参照整合性制約)があるわけではありません)。また、
WicketでJQueryをWicketっぽく使いたい! そんな人にうってつけのライブラリーがwiQueryです。 まだまだ使い始めて間もないのですが「おぉ、こいつはSUGEEE!」って感じなのでエントリー書いていこうかなと思います。 wiQueryとは WicketでJQueryと言えばWickeXtというライブラリーがありましたが、どうやらそいつが前身のようです(統合された??。詳しい経緯は不明です、ゴメンなさい・・)。以前にWickeXtを使った時はJQueryの機能を使うためにJavaのソースコード上にて文字列のJavaScriptソースコードを結構書いてて「う〜ん、UIはかっこいいけどちょっとWicketっぽくないなぁ〜」って感じだったのですがwiQueryは上手くJQueryをラップしたJavaのクラスが沢山用意されていてWicketに慣れている人なら違和感無く使える感じです。
今までJPA2.0のCriteriaを試してみた感想とかそこらへんを書いていこうと思います。 結論から言うとCriteriaはJavaによるプログラミングを追求しているって感じじゃないのかなと*1。 ANDやORの使い方について この感想を書くにはGoogle Collections Libraryで提供されているとあるAPIの事を取り上げねばならないのでまずはそちらについて。 Google Collections Libraryにはいろんな機能があるのですが今回関係するのはPredicate、Predicates、Iterablesといったクラスです。これらを使うとJavaでクロージャーを使う感じでListの絞り込みとか出来るようになります*2。ちなみにこのやり方はNext Generation Java Programing Styleの3番目に紹介されているやり方です。例えば下記はE
ドメインモデリング能力を鍛える - じゅんいち☆かとうの技術日誌 ドメインモデルに対する日米の温度差 | Ouobpo 上記の素晴らしいエントリーを読んで個人的に思ったことをつらつら書いてみようかなと。 個人的に日本でドメインモデルが主流にならない理由の1つとしてアジャイル開発プロセス(XP、スクラム、リーン等)の普及度合が低いというのも大きな理由の1つなのではと最近よく感じています。なぜならMartin Fowler、Kent Beck、Eric EvansやDavid Tomasらは彼らが執筆した本の中でインクリメンタルであり進化的な設計を推奨し、テストケースとリファクタリングを行うことで洗練されたクラス設計が出来上がると述べています。そして、それらの工程(テスト、リファクタリング、進化的設計等)はアジャイル開発ではほぼ必須と言っていいプラクティスです。 対してウォーターフォール開発で
JavaSE5から導入されたGeneric(型パラメータ)の機能とJPAを使えば各Entity(DBのテーブル)に対するDaoを作成する必要がなくなります。 まずEntityクラスのインターフェースを作成します。 public interface IEntity extends Serializable{ } この段階ではマーカーインターフェースの役割ですが、次回以降機能拡張する場合にこれが役に立ちます。 次はGenericなDaoのインターフェースを作成します。 public interface IGenericDao<E extends IEntity,PK extends Serializable> { E findByPrimaryKey(PK primaryKey); void persist(E entity); void merge(E entity); void remov
wicketstuff-annotationを使えば「きれいなURL」とか「NiceURL」とか言われる部分の設定をアノテーションで指定することが出来るようになります。自分は最近までURLの綺麗さとかはあまり気にしないプロジェクトばかりやってたのですが、最近使い始めたのでメモ。 ・wicketstuff-annotationのサイト Mavenを使っている場合、pom.xmlにrepositoryとdependencyの要素を追加。 <repositories> <repository> <id>wicket-snaps</id> <url>http://wicketstuff.org/maven/repository</url> <snapshots> <enabled>true</enabled> </snapshots> <releases> <enabled>true</enabl
Wicketの認証機能に関して便利なクラス等が提供されている「wicket-auth-roles」。自分の今までの知識を整理するためにもエントリーを書いていこうかなと思います。 Wicketの認証機能に関して今までいろいろ参考にさせてもらったサイト、ブログ。勝手ながら一方的お礼を言わせてもらいますw。ありがとう御座いましたm(_ _)m Fuckin’ 殴り書き http://rio1218.blog26.fc2.com/ NAGASEYASUHiTO ’POCHi’ Hatena あと、もちろんこちらも オープンソース徹底活用WicketによるWebアプリケーション開発 個人的にwicket-auth-rolesを使用することで得られるメリットはなんといっても アノテーションを使用した制御が可能 他にはすでに認証用のIAuthorizationStrategyがあったり、そのクラス等をす
AjaxFallbackDefaultDataTableを詳しく調べてみようと思いWicketのソースを眺めてたら見たことないタグを発見。 <wicket:enclosure> こいつは何者なのかと思い調べるとhttp://cwiki.apache.org/WICKET/wickets-xhtml-tags.htmlに載ってました。 どうやら上記タグにて囲った部分に関してまるごと表示、非表示の制御ができる模様。 例えば下記のようなPageクラスとHtmlを作成するとします。 <html> <head> </head> <body> <h1>Hogeページです。</h1> <wicket:enclosure> <h2>サブタイトルです。</h2> <span wicket:id="data"></span> </wicket:enclosure> </body> </html> public
Wicketのバージョンは1.3.5。Selenium IDEのバージョンは1.0b2 Selenium IDEを使用してWicketのModalWindowをテストするときに必要になる事をメモ。 1.ModalWindowを表示させる用のコマンドを記述する そのまんまですね。これは『自動記録』の機能を使ったほうが早いでしょうか。 直接記述する場合は下記のような感じでOKだと思います。 『コマンド』は「click」(ModalWindowはAjaxになるのでclickAndWaitではなくclickのみで) 『対象』はそれぞれ環境にあった対象にします。XPathを指定してもいいですし、link=(リンクの文字列)とかでもOK 例:ModalWindowを表示させるLinkがfooである場合 コマンド 対象 click link=foo 2.ModalWindowの表示完了を待つためのコマン
前回のエントリーでSuper Dev Mode(以下SDM)の実行の仕方を書きましたが、SDMで開発する際のデバッグの方法としてソースマップを使うことができます。 ソースマップとは? ソースマップとは最終的にJavaScriptにコンパイルして使う言語(CoffeScript、TypeScript等)をブラウザ上でデバッグしやすくする技術で、サーバー側にてCoffeeScript等の言語と実際のJavaScriptの紐付け情報をJSON形式でブラウザにダウンロードさせて、ブラウザ側でCoffeeScriptやTypeScript等のソースにブレークポイントをはってデバッグ出来るようにする技術です。通常、JavaScriptにコンパイルする言語はブラウザ側にてJavaScriptをデバッグしたとしても元々のコンパイル前のソースとは違う形になっているためデバッグがしづらいと言った問題がありまし
このページを最初にブックマークしてみませんか?
『ひたすらプログラミング日記』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く