前回に引き続き、Validator。今回は、自前のカスタムValidatorを作るときどうするかっていう、備忘録です。 もし、あるDBの項目で重複を許したくない場合（ユニークチェックですね）を例として取り上げます。 環境はTeeda + DBFluteを想定し、EMPテーブルのidという項目の重複がある場合にエラーとなる場合です。 まずは、javax.faces.validator.Validatorインターフェースを継承したMyEmpDuplicateValidatorクラスを作成します。場所はDoltengであらかじめ作成されているvalidatorというディレクトリに置きました。 MyEmpDuplicateValidator.java [java] package...

Teedaを利用していて、フォームの入力チェックで正規表現を使いたい場合、 Pageクラスで [java] public class TestPage { @RegularExpression(pattern = “[0-9a-zA-Z]+”) public String title; ～ } [/java] アノテーションを利用する場合はこのように書く。 （例は英数字のみのチェック） そして、HTMLは [html] [/html] と書いておけば、そこにエラー文言が表示される。すごく直感的、簡単でわかりやすい！ でも、エラー文言は 値(タイトル)は正規表現([0-9a-zA-Z]+)にマッチしません。 これがデフォルト。 気持ちはわかるが、これデフォルトで使う人いないっしょ！ あと、話はそれるが、DynamicPropertyの話。 htmlの属性値を変更できる機能だが、id属性の値を変更できない。。これなんとかしてほしいなあ。 そもそもTeeda...

TeedaのHTML上でリンク（aタグのhref属性）を書き換えるにはどうする？ 答えは、Dynamic Propertyを利用する。 view [html] 外部リンク [/html] Pageクラス [java] private String url; //Dynamic Propertyを使って、urlを書き換え public String getUrlHref(){ return this.url; } [/java] Dynamic Propertyは、先頭にget...

現在、Teeda + DBFluteな環境で、Webアプリを製作中なわけですが、DBを更新する処理とかのバッチ作成する時って、どこにソースを配置すべきなんでしょう。 考えた末、、Webアプリと混在する環境に置く事に。 javaのソースディレクトリにbatchっていうのを作って、そこにmain関数を書いてしまう。 そして、ソースはこんな感じで。 [java] import...

Javaで各種WebのAPIにRESTするのに一番簡単な方法は？ いろんな手段がありえるが、今回は「Restlet」を取り上げてみる。 Restlet自体はAPIを提供する側のサーバ機能を利用することが多いようですが、今回はあえてクライアントとして利用します。 まずは、Restletのライブラリをダウンロードする。 Restlet...

JavaでRSSフィードを取得する手段は？ commonsのHttpClientライブラリで取得してDom操作とか、、そんなめんどくさそうな感じがいやだったので、いろいろと探してみると、ありました！その名も「ROME」 このROMEは、RSSやAtomフィードなどのいろんなバージョンのRSSを統一なインターフェースで取得できるライブラリである、ということでさっそく使ってみました。 まずは、公式サイトから「ROME」、「ROME...

最近家でもりもりとプログラムを作成していて、サーバー側の実装はお気に入りのSeasar2 Teedaを利用しているのですが、どうも納得のいかん部分があるので書いておきます。 １．URLを操作しにくい。 Webアプリケーションを作成する上でURLのつけ方にはこだわりを持ちたいものですが、URLの操作がしにくい。/view/サブアプリケーション名/○○.htmlみたいな形にしかできない。diconの書き換えをすればできるかもですが、この辺は作成する側に任せてほしい。ApacheのRewriteなどで対応できそうではあるが。 ２．GETメソッドって使える？ 基本はPRGパターン（POST-REDIRECT-GET）になっていて、スコープの状態を保存して画面遷移するみたいですが、たとえば、検索などでURLにパラメーターを残したい場合に対応できない。これももう少し調べるとできるのかもだが、まだよくわかってません。 ３．HTMLのチェックが厳格すぎる。 これを言ってしまえば、フレームワーク使うなって話だけど、結局HTMLってプログラマー以外の人も触るものだし、なんとかならんかなとも思ったりする。 業務系のWebアプリとか、フォーム系の処理なんかは、すごくマッチするフレームワークだと思うけど、例えば簡単な携帯サイトや検索アプリなんかは作りにくいなあと感じます。 まだ不勉強でこんなことを言ってますが、初心者が陥りやすいミスとか気づいたこととかあれば、またこのブログに載せていきます。

Seasar2のmini eventに行ってきました。 場所は萌えの町アキバ！ しばらくぶりに行ったけど、だいぶ変わったな～ コスプレのおねえちゃんはともかくとして、、 中央通りのビルが軒並み建設中でいままでのような活気がなく感じた。 まさに再開発の途中って感じ。 まあアキバの話は置いておいて、 自分も実践してるGTDのツール（tugboat.GTD）の話と まさに勉強中のSeasar2の話が聞けるということで行ってみました。 Seasar関連のイベントは初めてで、生ひがさんを見たのも初めて！ 自分にとっては、かなり参考になったので、 ひがさんの話を思い出しながら（メモ帳を忘れてしまったのでうろ覚えですが） 簡単に感想＆まとめを書いてみます。 まずWebアプリケーションにおけるレイヤモデルの問題点。 プレゼンテーション層、サービス層、ドメイン層、データアクセス層、リソース… 各々の層をインターフェースを用いて疎結合するという方法は、 各層の役割が明確化して、修正による影響が低いというところがあげられるが、 どの層にクラスを持っていくべきか迷う場合がある。 またインターフェースやクラスが大量に作成されることになり クラスの管理、テストの面においても煩雑になってしまう。 自分も以前のJ2JSFを利用したときに体験したので確かに、 何もロジックのないクラスを作ったりすることの無駄はあるなーと感じていたので かなり同感できました。 teedaの1ページ1クラス、1ユースケースに1サービスクラスという構造。 共通機能はサービスクラスに置き、継承を利用する。 これならどこにロジックをおくべきなのかは明らか。 ユースケースの粒度については、メニューの1機能が1ユースケースと考える。 異なるユースケース間の共通機能は委譲モデルを利用して 共通ユースケースを作成して実現する。 なるほど。またこのような考え方は、複数人開発をイメージしていて、 1ユースケースが一人で作成して、重複しないように考えられているそうです。 私の周りでjava関連のフレームワークを利用していない人は、 クラスの管理や考え方が煩雑で複雑なイメージを持っている方が多いですが、 teedaならシンプルに考えられそうな気がしてきました。 これはぜひteeda試さないと！ tugboat.GTDの資料はharaさんのブログにありました。 ひがさんのブログ

WebインターフェースをAjaxを利用し、サーバサイドのプログラムは Javaで実装したい場合、さまざまなスキルセットが必要となる。 思いついた部分だけであげてみると JavaScript DHTMLとCSS JSONもしくはXML アプリケーションサーバ （Tomcatなど） JavaServlet/JSP、Webフレームワークの知識 Eclipseなどの開発ツール（複雑なフレームワークを利用する場合は必須であろう） XMLパーサやXSLTなどのXML解析技術 と盛りだくさんだ。また、非同期通信する際のWebインターフェース設計は いままでのページ単位の設計とは違う視点が必要になる。   ...