1冊買っておくか,と思い,本屋でいろいろ立ち読みした結果,これが一番よさそうだったので購入。Webでいくらでも入手できるから構わないでしょう。各項目の説明も非常に詳しく,これから何かと役にたってくれそうです。お値段もそれなりにしますが...。Tapestryを勉強してみた。http://jakarta.apache.org/tapestry/まずはググることから始めてみたが日本語リソース少ねー。解説記事は数えるほどで後は個人の日記ページばかり。そんなこと言ったらこのページも日記なのでえらそうなこと言えないけど。EclipseのプラグインであるSpindleをインストール。Tapestryがやってきた(前編)http://www.duo.co.jp/column/35tapestry_java00.htmlこの辺のページを参考にしながらデモを一通り動かしてみました。基本的な考え方はロジックとビューを完全分離できます。HTMLファイルで作成することができます。HTMLファイルなのでデザイナーも安心して作業できます。画面デザインをデザイナーに委託するほどおしゃれなサイトを作った経験がないので,この辺,完全分業できるとどれくらいうれしくなるのかはピンとこなかったりしますが。id属性で指定します。tapestryが理解できるようにしておきます。*.pageファイル(XML形式)です。*.htmlと一対一対応します。*.javaに好きなようにロジックを実装していきます。*.java内で指定します。XMLファイルなどの外部ファイルではありません。JSFなどと違うところです。GUIアプリケーションのあるべき設計により近づいていると思うので,筋は悪くなさそうです(←えらそう)。日本語リソースが少ないのが難ですが。S2Daoも試してみました。S2DAOhttp://muimi.com/j/aop/seasar/s2dao/も参考にしながらやってみましたが,動きませんねえ...。NullPointerExceptionが返ってきます。S2Daoで出ているので何が悪いのかもさっぱりわかりません。JavaBeansでおこなう。S2Daoのルールに従ってつけてもらうことで実現します。外出しのファイルとして管理できるのでうれしい。O/Rマッピングではマッピングの方法を何でやるかがポイントなんですかね。一般的に考えると,記述すべき内容はソースコード内で完結できればそれに越したことはないはず。設定ファイルが必要なのはパラメータの中には外部から与えたほうが便利な場合,あるいはそうじゃないと使い物にならない場合が存在するためです。マッピングルールは本来,コード内で処理すべきなんでしょうか,それとも外部から制御すべきものなんでしょうか。DBスキーマに変更があった場合は,それに関連する処理コードに手を入れないといけない可能性が高いように思いますので,あまりこのメリットは享受できないかもしれません。なると,あるべき論からいくと,O/Rマッピングはソースコード内でおこなうのがいいんでしょうね。ネーミングルールで縛るのが最適解かどうなのかはわかりませんが。Hibernateを動かしてみることにしました。O/Rマッピングhttp://www.atmarkit.co.jp/fjava/rensai3/ormap01/ormap01.htmlを参考にしてぽちぽちとやってみました。3.0.5ということでそれでやってみたところ,構成ファイルやパッケージ名やら色々変わっていますね。hibernate3.jarだけパスを通しておいて,コンパイルして「そんなのない!」と怒られたクラスが含まれるライブラリを順番にパスに加えていったところ,なんとか動くようになりました。XMLファイル(*.hbm.xml)でおこなう。setter/getter)も作成する必要がある。HQL(SQLに似たクエリ言語)でおこなう。SQLは使えない?(不明。わからない)という感じでしょうか。fumi1件のコメントhttp://www.jaxmag.com/itr/online_artikel/psecom,id,648,nodeid,147.html要旨を簡単にまとめてみます。多少意訳や誇張も含んでいますので正確なところは原文をあたって下さい。Actionクラスを用意するとよい。Actionクラスを継承するという方法。Actionクラスになります。DispatchActionを使おうオンラインショッピングアプリケーションを考えたとき,カートの商品の追加,削除,更新といった機能が必要になります。excute()メソッドで実装することになりますが,それってなんかいやです。Actionクラスにまとめて管理したいです,というときに使うクラス。2回クリックしてしまって,2重注文になってしまった,というような悲しい状況を回避するための方法。サーバ側とクライアント側のトークンの比較をおこないます。2度目のクリックではクライアント側のトークンは変化していないけどサーバ側のトークンが変化しているので,そこで処理の振り分けができます。isTokenValid()です。1つのままではそこがボトルネックになってしまい何もうれしくありません。struts-config.xmlの書き方のお話。ActionFormにまとめます。すべてのフィールドを同時に使うことはないかもしれないけどそれでもいいです。メンテナンスの容易性が最優先。Actionに書くのは冗長です。Actionクラスに実装しないActionはそういうことをする場所ではないです。モデル層に委譲したほうがいいです。Actionクラスではインスタンス変数やクラス変数は使わない複数スレッドから予期しないタイミングで更新されるのを避けるためです。Strutsによってデータをやりとりするために使います。モデル層と混同しちゃだめです。