フレームワーク開発者ではなく、フレームワーク利用者の視点でSeasar関連のjarファイルに�内包されている便利クラスをピックアップしました。 便利クラスの存在を知って活用することは大切ですが、もっと大切なのは、便利クラスを自作する前に、フレームワークやプラットフォームで似たようなモジュールが存在していないかチェックする習慣だと思います。 他にも便利なクラスやメソッドがあれば、ぜひ、コメント等で教えて下さいませ m(_ _)m 。 ArrayUtil.isEmptyメソッド 用途 配列が空（null）かどうかをチェック jar s2-framework-2.4.xx.jar パッケージ org.seasar.framework.util メソッド static boolean isEmpty(Object[] arrays) ArrayUtil サンプル if (arrays == nul
このエントリーではSeasar 2.4.26 から 導入された S2AbstractService について書かせて頂きます。S2AbstractService を活用することで、タイプセーフを保ちつつも、データアクセスロジック関連のソースコードを大幅に減らす効果が期待できます。 S2JDBC の弱点 S2JDBCを使えば、お手軽かつパワフルにデータアクセス処理が実現できます。しかし、生のS2JDBCを野放し状態に使った場合、プロジェクトの規模が少し大きくなると、ソースコードの重複を生みやすくなる問題に直面します。具体的に、次の１件分のデータ取得処理ですら、コピー＆ペーストされて複数箇所で使用されてしまいます。 Emp emp = jdbcManager.from(Emp.class).id(empId).getSingleResult(); 対処方法は、共通処理を抽出してメソッド化するこ
ここで疑問点があります。この疑問点のため、眠れなくて早く起きてこのエントリを書いています。笑 ・ビジネスロジックをEntityとServiceに書く設計（最近流行のDDDの設計）だと思いますが、Entityのメソッドには、insertとかupdateとかdelete、かつエンティティ独自の振る舞いを持たせるServiceのメソッドには、findAllとかfindByNameとかというものが用意される認識で良いのか？ ・S2Daoを使用していた時は、１画面につき１Dtoを作って、そのDtoを画面表示に使っていました。 S2JDBCを使用すると、関連先のEntityが対象Entityにくっついて検索されるので、Entityを画面表示に使っても良い？ 画面表示用のDtoは不要？ 以下に、自分なり回答をさせて頂きますので、参考までにどうぞ。 まず、Entityのメソッドには、insertとかupd
例えば、アプリケーション全体の構成要素として、簡単な処理が占める割合が８割で、複雑な処理が占める割合を２割あったとします。この場合、次の１〜３のどの方針を採用するだろうか？ [方針１] ８割の簡単な処理にあわせる 生産性重視。ただし、複雑な処理で品質を落としやすい。 [方針２] ２割の複雑な処理にあわせる 品質重視。ただし、簡単な処理の生産性は落ちる。 [方針３] 両方の対処方法を用意して、使い分ける 最適化重視。ただし、厳密な使い分けは難しい。 例えば、Strutsにおいて、見た目まわりの処理を実施する場合はこんな感じになります。 [方針１の実装例] EL式（もしくは、スクリプトレット）を使う。 [方針２の実装例] ロジックはコントローラ側で実施して、結果フラグ等をViewへ渡す。 View上では、結果フラグを使った分岐処理のみに留める。 [方針３の実装例] 例えば、変数が２〜３個で処理
先週末に開催されたSeasar Conference 2008 Spring で 私の登壇に絡むコンテンツをまとめてみました。 メディア掲載記事 ちょろっとだけですが私の名前もITProに掲載されました。 【Seasar Conference】「世界への普及目指す」 ---ひがやすを氏が新フレームワーク「Slim」を発表 http://itpro.nikkeibp.co.jp/article/NEWS/20080524/303949/ SAStrutsはティーアンドエフカンパニーの出羽健一が紹介した。 SAStrutsは2008年1月に正式リリースされたStrutsのラッパーフレームワーク。 すでに数社の大企業が採用を決めているという。 セッション概要・当日の発表資料 以下からダウンロードできます。 StrutsからSAStrutsへ http://event.seasarfoundati
型推論の要素を盛り込んだS2Containerのラッパーを作ってみました。 たとえば、 HttpServletRequest req = SingletonS2Container.getComponent(HttpServletRequest.class); JdbcManager jdbcManager = SingletonS2Container.getComponent(JdbcManager.class); HogeService hogeService = SingletonS2Container.getComponent(HogeService.class); は、次のように書き換えることができます。 HttpServletRequest req = S2.lookup(); JdbcManager jdbcManager = S2.lookup(); HogeService
Google Collection Libraryを軽くいじってみました。 かなり良さげです。 Google Collection Library http://code.google.com/p/google-collections/ Java 7に向けて提案されている型推論と同様のことが できてしまうのが特に嬉しいです。 たとえば、 List<String> listOfStrings = new ArrayList<String>(); List<Map<String, Object>> mapItems = new ArrayList<Map<String, Object>>(); List<List<Map<String, Object>>> mapItemsItems = new ArrayList<List<Map<String, Object>>>(); は、次のように書き
普段私がSAStrutsでアクションのコードを書く際に 気を付けていることをまとめてみました。 原則： 既存コードを修正することなく、機能追加を実現する 画面が追加されても、既存のメソッドに修正が入らず、メソッド追加で対応できること ボタン追加などイベント処理が追加されても、既存のメソッドに修正が入らず、メソッド追加で対応できること 初期化ロジックの無い箇所に後から初期化ロジックを追加する場合でも、クラスのインターフェースは変更しないこと できるだけタイプセーフなコードにすること メソッド・シグネチャにおける属人性を排除する この原則を成し遂げるために、以下のコーディング規約を守る必要があります。 （オリジナルであって公式ではない。） コーディング規約 全てのアクションにindexメソッドを用意する Teedaスタイルで入力系メソッドと出力系メソッドを分離する（※） JSPを単独で使用しな
Eclipseで学ぶはじめてのJava 作者: 木村聡出版社/メーカー: ソフトバンククリエイティブ発売日: 2008/02/14メディア: 大型本購入: 3人 クリック: 425回この商品を含むブログ (28件) を見る Javaの入門書は世の中にたくさんありますが、 ハッキリ言って、この本は一味ちがいます。まさに決定版。 実際に社内での評価も高く、すぐに社内標準のJava教育本になりました。 また、自分が講師を務める研修で、Javaの基本知識を 補いたい人には既にこの本を自信を持って推薦させて頂いています。 （自信を持って推薦できる本に出合えたことは本当に嬉しいことです。 最近SAStrutsにハマってるので、Strutsで自信を持って推薦できる本を探さなければ、、、。） Seasar2のコミッターとしても現場でバリバリやっている著者が、 流行に左右されない、時を経ても現場で役立つ基礎
S2JDBCを使ってエンティティ内にビジネスロジックを定義する リッチドメインモデルの手法は効果的なのだろうか？ 現時点での私の考えはNo。 「S2JDBCのようなレイジーロードをサポートしていないO/Rマッパーで リッチドメインモデルを実現するのは実務的ではない。」のではないか と思っています。 理由は『エンティティに定義したビジネスロジックは、 （主に関連をたどるような）データアクセスのロジックに強く依存する』ことに起因しています。 レイジーロードがある場合は、データアクセスのロジックを 透過的に扱うのでここで言う依存の問題は実質的に該当しません。 しかし、レイジーロードが無いアーキテクチャでは「ビジネスロジック」を 持つエンティティが「データアクセスのロジック」を持つアクションに 依存することなり、結果的にエンティティを呼ぶアクションとエンティティが 実質的に相互依存してしまいます。
「足の裏以外が１点でもリングに接した状態＝グラウンドポジション」と明文化。その上で、立った選手のグラウンドポジション選手の頭部、顔面への蹴りや踏みつけは禁止（ひざ蹴りは可）などと決まった。 ルールが明確になるのはとても良いこと。 素朴な疑問なのだが、一応スタンディングポジションである うんこ座りで構えて、相手が顔面を蹴ろうとした瞬間に地面にサッと手を付けて、 グランドポジションに移行した場合は、相手は反則になるのだろうか？（笑） まさに「忍法身代わりの術」。 SASturtsのアクションは、自分自身のプロパティにアクションフォームが 存在しなければ、自分自身がアクションフォームとして振舞うようです。 ＞ Thanks id:jflute さん なるほど。だから、アクションに定義したプロパティが JSPから参照できる訳ですね。 実際には、SASturtsのS2ActionMapping.ja
SAStrutsは、いざとなったらJSPのスクリプトレットでゴリゴリやれてしまうのが、１つのメリットだと思う。 ただ、JSPのスクリプトレットは、ソースコードのメンテナンス性を悪化させやすいので、極力避けたいところ。 とはいえ、taglibやFunctionで対応するのが困難なケースに遭遇するとそうも言ってられない。いざJSPのスクリプトレットを記述する場合は、少しでもスマートな方法で記述したいので、そのやり方を検討してみました。 具体的には、SAStrutsのチュートリアルにある EmployeeActionのempItemsプロパティ（List型）に対してtaglibを使わずに Employee#name プロパティの一覧を表示する場合は以下のようなコードになります。 <% for (Employee e : getComponent(EmployeeAction.class).emp
SAStrutsとStrutsはアクションのコンポーネントの スコープが異なっているので注意しなければならない。 アクションのスコープの違い Struts singleton SAStruts request 生Strutsのアクションが持つフィールド 複数のスレッド間で共有される一方、 冗長化構成のマシン間では共有されない。 このようなクセがあるために、使用を避ける、 もしくは、慎重に使う必要がありました。 （使用禁止にしていたプロジェクトも多いと思われる） SAStrutsのアクションのフィールド 他のスレッドに影響を及ぼさないrequestスコープなので、 気軽にどんどん使用することができる。 ちなみに、アクションのフィールドをpublicフィールドとして 宣言しておくと、次のようにJSP側のEL式で簡単に呼び出すことができる。 HogeAction.java package tut
以前、WEB+DB PRESS vol. 41 にて特集２『つらいJavaからたのしいJavaへ Seasar2 サクサク開発 実践カリキュラム』を執筆させて頂きました。 (http://gihyo.jp/magazine/wdpress/archive/2007/vol41) この記事では、プレゼンテーション層にTeeda、データアクセス層にDBFluteというフレームワーク使ってサンプルアプリケーションを作成しました。 今回は、前回と同じ外部仕様、同じデータベースによる サンプルアプリケーションのSAStruts + S2JDBC版を作ってみました。 ただし、現時点では「正常系が動作した」というレベルの完成度です。 前回のサンプルアプリケーションと比較して、以下のような未実装な機能が 多く存在するので注意が必要です。 一部の日付書式 バリデーション 二度押し防止 戻るボタン対策 共通レ
・JavaScriptの技法：高度な関数の活用 http://builder.japan.zdnet.com/news/story/0,3800079086,20364532,00.htm 「今風のJavaScriptは、何だか良く分からないなぁ」なんて思っていたら、 いい記事を見つけることができた。軽くまとめながら理解を深めてみる。 JavaScriptで関数を定義する方法 3種類の方法で関数を定義できる。 function文を用いた定義 function add(x,y) { return x + y;} Function()コンストラクタを用いた定義 var add = new Function('x','y','return x + y;'); functionリテラルによる定義 var add = function(x,y) {return x + y;}; JavaScript
コーディングの際に、知っておくべき情報や注意してる点など、 やっていること・やるべきことを自分なりにまとめてみました。 ただし、（おそらく永遠の）ベータ版です！ クラス名、メソッド名、変数名などの名前付けにこだわる。 変数名へのこだわりの無さが「バグの温床」になることを理解する。 名前と内容は一致しなければならない。 名前から内容が容易に推測できるものでなければならない。 １つの対象に別々の変数名を付けない。（変数名の一貫性）特に、チームメンバー間でズレやすいので気をつける。 チーム内で変数の命名相談を繰り返すことで、命名センスの均一化に繋がる。 コーディングスタイルは無数にある。重要なのは、自分のスタイルを貫くことではなく、１つの決めたスタイルに合わせることである。 NullPointerExceptionがでないかどうかに神経を使う パラメータ引数がnull だったら、戻り値がnull
『本番環境のJDKのバージョンは1.4にも関わらず、 1.5でコンパイルしたクラスファイルをアップしてしまってトラぶったのは、 どこのどいつだ〜い。 あたしだよっ！』（にしおかすみこ 風） という訳で二度と同じ過ちを繰り返さないように確認手順をメモしておく。 (1) 調べたいクラスファイルに対してjavapコマンドを実行する > javap -v <クラス名>※ ".java" の拡張子は不要 例： > javap -v HogeService※ 前提： カレントディレクトリに HogeService.java が存在する (2) コマンドの実行結果を調べる コマンドの出力結果の major version: XX という行の XX をチェックする。 java のバージョンとバージョン番号との対応は以下の通り。 1.1 = 45.3 1.2 = 46.0 1.3 = 47.0 1.4 =
http://sourceforge.net/projects/ttl 先日、jfluteさんから教えて頂いたとっても便利なEclipseプラグイン。 Package Explorer や Navigator から右クリックして簡単に ファイルエクスプローラやコマンドプロンプトを開くことができる。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く