結論としてStruts2は言うことなしですね。素晴らしく美しいと思います。
PojoでActionクラスが書けるとことか、XMLの使い方とか。疎結合デザインのお手本です。見事。最高のフレームワークの一つでしょう（他をそんなに知らないけど）。
強いて言えば自由度が高すぎることでしょうか。少数精鋭の開発チームなら最適な選択でしょうが、多人数で開発するとなると自由度が高い故にコードの統一感という意味では見劣りするかもしれません。敢えてケチをつけるとすれば。
例えるならSpringが中途半端なアーミーナイフだとすれば、Struts2は切れ味のよい丈夫な万能ナイフといったところでしょうか。Springはいろいろと便利なんだけど機能としてはややシシバリがきつくて息苦しい。Struts2は何にでも応用が効いて切れ味爽快。でも使い方間違えるとケガするぞ、という意味で。苦しいか。
まあSpringにしたってControllerインターフェースをインプリせざるを得ない局面があって、そうなるとほとんど生のServletに近いから、何でもできてしまう＝雑なコードになってしまうという穴もあるんですけどね。
しかしStruts2お見事、というのが総評です。
.
2008年10月10日金曜日
Struts2を試す（６）
日本製のチュートリアルを試しました。（１０ページまでですが・・・）
実践サンプルで学ぶStruts 2 - 生まれ変わった定番フレームワークを徹底解説
よく出来てます。分かり易いし。
2.0ベースなので、2.1では上手く行かないところもありましたが、大した障害ではありません。
■①大量にwarningが出る
jarが足りないのが原因だと思われます。
以下が揃っていれば（私の場合は）止まりました。
commons-collections-3.2.jar
commons-fileupload-1.2.1.jar
commons-logging-1.0.4.jar
freemarker-2.3.12.jar
log4j-1.2.15.jar
ognl-2.6.11.jar
struts2-core-2.1.2.jar
xwork-2.1.1.jar
■②label="ユーザー名" が必要。
さもなければ
致命的: サーブレット jsp のServlet.service()が例外を投げました
java.lang.NullPointerException
at java.text.MessageFormat.applyPattern(Unknown Source)
at java.text.MessageFormat.(Unknown Source)
at com.opensymphony.xwork2.DefaultTextProvider.getText(DefaultTextProvider.java:70)
が出ます。
■③HelloUserが存在しないと起動時に怒られる。（これは正確にはチュートリアルの不備ではありません）
以下のメソッドのみを持つexample.HelloUserクラスを作成する。
HelloUser.jspもテキトーでいいので何かHTMLファイルを作る
以上の変更で10ページまでは上手く行くことを確認しました。
以上。
.
実践サンプルで学ぶStruts 2 - 生まれ変わった定番フレームワークを徹底解説
よく出来てます。分かり易いし。
2.0ベースなので、2.1では上手く行かないところもありましたが、大した障害ではありません。
■①大量にwarningが出る
jarが足りないのが原因だと思われます。
以下が揃っていれば（私の場合は）止まりました。
commons-collections-3.2.jar
commons-fileupload-1.2.1.jar
commons-logging-1.0.4.jar
freemarker-2.3.12.jar
log4j-1.2.15.jar
ognl-2.6.11.jar
struts2-core-2.1.2.jar
xwork-2.1.1.jar
■②label="ユーザー名" が必要。
× <s:textfield key="username" />
○ <s:textfield label="ユーザー名" key="username" />
さもなければ
致命的: サーブレット jsp のServlet.service()が例外を投げました
java.lang.NullPointerException
at java.text.MessageFormat.applyPattern(Unknown Source)
at java.text.MessageFormat.
at com.opensymphony.xwork2.DefaultTextProvider.getText(DefaultTextProvider.java:70)
が出ます。
■③HelloUserが存在しないと起動時に怒られる。（これは正確にはチュートリアルの不備ではありません）
以下のメソッドのみを持つexample.HelloUserクラスを作成する。
public String execute() {
return "success";
}
HelloUser.jspもテキトーでいいので何かHTMLファイルを作る
以上の変更で10ページまでは上手く行くことを確認しました。
以上。
.
2008年10月8日水曜日
Struts2を試す（５）
CRUD Demo Iを動かしてみました。
tutorialの節に入ってはいますが、実際にはほとんど読み物です。
Struts2の単純なアプリを読み解いて勉強するにはよいサンプルだと思います。Struts2の特徴やパワーも分かりやすい。ただサンプルアプリが既に出来上がっていて動かすだけになっているのと、読む量が多いのとで結構ダレます。Struts2自画自賛なところも好みが分かれそう。（面白いけど疲れる・・・）
ソースコードを未完成にしておいて読者に埋めさせる作りの方が断然良かったと思います。
しかし悪口ばっかしたり顔で言ってると、自分が薄っぺらい批評家になってきた気分。
そろそろ自分で０から作ってみなきゃな・・・
.
tutorialの節に入ってはいますが、実際にはほとんど読み物です。
Struts2の単純なアプリを読み解いて勉強するにはよいサンプルだと思います。Struts2の特徴やパワーも分かりやすい。ただサンプルアプリが既に出来上がっていて動かすだけになっているのと、読む量が多いのとで結構ダレます。Struts2自画自賛なところも好みが分かれそう。（面白いけど疲れる・・・）
ソースコードを未完成にしておいて読者に埋めさせる作りの方が断然良かったと思います。
しかし悪口ばっかしたり顔で言ってると、自分が薄っぺらい批評家になってきた気分。
そろそろ自分で０から作ってみなきゃな・・・
.
2008年10月7日火曜日
Struts2を試す（４）
引き続きStruts 2 + Spring 2 + JPA + AJAXを試しました。
まずは感想から。「詰め込みぎ」チュートリアルの一例です。せめてHibernateとの連携だけにして欲しかった。HibernateとSpringを触ったことがない人には何をやってるか分からないと思います。
Strutsのパワーを知るより、他のコンポーネントとどうやって連携させるかという点に主眼を置いたチュートリアルです。とりあえず上手く連携させることができるよ、と。
以下、作業メモです。
このチュートリアルはStruts 2.0をターゲットに書かれており、Struts 2.1で動かすためには修正が必要です。以下で出てくるエラーと併せて記載します。
いきなり"Dependencies"にあるjarで過不足ありそうな感じですが気にせず進めましょう。Spring、Hibernateのライブラリをダウンロード、名前が一致しているライブラリを適当に/WEB-INF/libに突っ込みます（後でjarライブラリのリストを載せておきます）。
ガイド通りコーディングしてTomcatで実行したところ早速以下のエラーが出ました。
Spring周りで以下のjarファイルが足りなかったようです。ClassNotFoundとなったクラスから地道にjarを探しました（そんなに大変でもなかったですが）。
log4j-1.2.15.jar
slf4j-api-1.5.0.jar
slf4j-log4j12-1.5.0.jar
以上をWEB-INF/libに入れ込めばとりあえずwarは起動します。
index.jspにアクセスすると以下のエラー群がでます。
debug属性をはずして対応しました。
FreeMarkerのtemplateを使うためstruts2-dojo-plugin-2.1.2.jarが必要です（地道にjarを展開して探しました）。WEB-INF/libに上記ライブラリを突っ込んで対応。
Troubleshooting guide migrating from Struts 2.0.x to 2.1.x にあるとおり theme="ajax" はobsoleteとのこと。移行ルールは以下の通りです。
（以下の情報は上記ページからそのまま持って来てます）
これでindex.jsp画面からのPersonalデータCRUDが出来る筈です。
以下が最終的にWEB-INF/libに格納されていたライブラリ群です。
antlr-2.7.6.jar
asm-attrs.jar
asm.jar
cglib.jar
commons-collections-3.1.jar
commons-fileupload-1.2.1.jar
commons-logging-api-1.1.jar
dom4j-1.6.1.jar
ejb3-persistence.jar
freemarker-2.3.12.jar
hibernate-annotations.jar
hibernate-commons-annotations.jar
hibernate-entitymanager.jar
hibernate3.jar
javassist.jar
jta.jar
log4j-1.2.15.jar
mysql-connector-java-5.1.6-bin.jar
ognl-2.6.11.jar
slf4j-api-1.5.0.jar
slf4j-log4j12-1.5.0.jar
spring.jar
struts2-core-2.1.2.jar
struts2-dojo-plugin-2.1.2.jar
struts2-spring-plugin-2.1.2.jar
xwork-2.1.1.jar
以上。
.
まずは感想から。「詰め込みぎ」チュートリアルの一例です。せめてHibernateとの連携だけにして欲しかった。HibernateとSpringを触ったことがない人には何をやってるか分からないと思います。
Strutsのパワーを知るより、他のコンポーネントとどうやって連携させるかという点に主眼を置いたチュートリアルです。とりあえず上手く連携させることができるよ、と。
以下、作業メモです。
このチュートリアルはStruts 2.0をターゲットに書かれており、Struts 2.1で動かすためには修正が必要です。以下で出てくるエラーと併せて記載します。
いきなり"Dependencies"にあるjarで過不足ありそうな感じですが気にせず進めましょう。Spring、Hibernateのライブラリをダウンロード、名前が一致しているライブラリを適当に/WEB-INF/libに突っ込みます（後でjarライブラリのリストを載せておきます）。
ガイド通りコーディングしてTomcatで実行したところ早速以下のエラーが出ました。
アプリ起動エラー（ClassNotFound系）
Spring周りで以下のjarファイルが足りなかったようです。ClassNotFoundとなったクラスから地道にjarを探しました（そんなに大変でもなかったですが）。
log4j-1.2.15.jar
slf4j-api-1.5.0.jar
slf4j-log4j12-1.5.0.jar
以上をWEB-INF/libに入れ込めばとりあえずwarは起動します。
index.jspにアクセスすると以下のエラー群がでます。
致命的: サーブレット jsp のServlet.service()が例外を投げました
org.apache.jasper.JasperException: /index.jsp(7,0) TLDによると、タグ head の属性 debug は無効です
debug属性をはずして対応しました。
致命的: error when rendering
java.io.FileNotFoundException: Template /template/ajax/head.ftl not found.
FreeMarkerのtemplateを使うためstruts2-dojo-plugin-2.1.2.jarが必要です（地道にjarを展開して探しました）。WEB-INF/libに上記ライブラリを突っ込んで対応。
FreeMarker template error!
Expression parameters.parseContent is undefined on line 45, column 28 in template/ajax/head.ftl.
The problematic instruction:
----------
==> ${parameters.parseContent?string} [on line 45, column 26 in template/ajax/head.ftl]
----------
Troubleshooting guide migrating from Struts 2.0.x to 2.1.x にあるとおり theme="ajax" はobsoleteとのこと。移行ルールは以下の通りです。
（以下の情報は上記ページからそのまま持って来てます）
追加：<%@ taglib prefix="sx" uri="/struts-dojo-tags" %>
旧：<s:head theme="ajax"/>
新：<sx:head parseContent="true"/>
旧：<s:div id="jobStatus" theme="ajax" href="%{jobStatus}" updateFreq="5000" indicator="indicator">
</s:div>
新：<sx:div id="jobStatus" href="%{#jobStatus}" updateFreq="5000" autoStart="true" indicator="indicator">
</sx:div>
（"s"を"sx"に変更してtheme="ajax"を削除する）
これでindex.jsp画面からのPersonalデータCRUDが出来る筈です。
以下が最終的にWEB-INF/libに格納されていたライブラリ群です。
antlr-2.7.6.jar
asm-attrs.jar
asm.jar
cglib.jar
commons-collections-3.1.jar
commons-fileupload-1.2.1.jar
commons-logging-api-1.1.jar
dom4j-1.6.1.jar
ejb3-persistence.jar
freemarker-2.3.12.jar
hibernate-annotations.jar
hibernate-commons-annotations.jar
hibernate-entitymanager.jar
hibernate3.jar
javassist.jar
jta.jar
log4j-1.2.15.jar
mysql-connector-java-5.1.6-bin.jar
ognl-2.6.11.jar
slf4j-api-1.5.0.jar
slf4j-log4j12-1.5.0.jar
spring.jar
struts2-core-2.1.2.jar
struts2-dojo-plugin-2.1.2.jar
struts2-spring-plugin-2.1.2.jar
xwork-2.1.1.jar
以上。
.
MVCは作っているうちに破綻する（２／２）
次に View という位置付けについて考えてみます。実はこのViewが曲者なのです。
前回の投稿で、ModelやControllerという場所にも表示系ロジックを配置しました。私だって本当はこんなことやりたくない。表示はJSPに任せて、ModelとControllerはロジックに専念させたい。でもそうは行かないのです。
単純な例を上げてみましょう。例えば「10月4日（土曜日）」というデータがあります。このデータを画面に表示したい。JSPには例えば<c:out value="model.date"/>などと書いてある。とすれば、modelビーンのdateフィールドに"10月4日（土曜日）"をセットしてやればよい。JSPは入れ物を準備し、モデルに値をセットしているわけで、これはMVCモデルが美しく機能したと言えるでしょう。
しかし、ここで顧客が一言。「土曜日は背景色を青にしたいな。日曜と祝日は赤だ」。ロジック的には容易な変更です。従って断れない。この要件に対して以下の２つの実装パターンが考えられます。
１．JSP（以下はJSTLの例）で表示ロジックを組み立てる（以下がイメージですが多分この通りに書いても動きません）
２．Beanの中に表示ロジック込みでデータを入れ込む
１の案は恐らく「Viewに表示を任せるという方針に沿っている」というメリットしかありません。このようにずらずら書かれたJSPをメンテする人がかわいそうです。
２はいろんな意味で美しくはありませんが、少なくともメンテナンスはしやすい。UTもできます。
好みはあるでしょうが、私なら２の案を取ります。Viewの役割に固執するのは意味がないと考えるからです。
以上を センセーショナルにまとめると View という考え方自体現実的には破綻しているともいえます。
なぜか。
それはデータの表示方法はデータの意味と密接に関連しており、それはロジックによって制御されるべきだからです。View として独立させてしいまうのはそもそもムリがある。
もちろん単純なロジックであればJSPなりJSTLなり使ってシンプルに表示できるのが望ましい。メンテも容易だし、結果として美しいコードに仕上がります。しかしそんな容易な表示要件は残念ながら少ないでしょう。
最近MVC2という考え方も出てきていて、これはJSP＋Ajaxなどとして表示を制御するロジックをViewに持つ考えのようですが、これも完全な解決策にはなりません。恐らくはView用に最適化されたAjaxフレームワークができるまで・・・
結論として何が言いたいか。あまりMVCだとかMVC2だとかにこだわらず、センスと経験に任せてデザインするのがよい、そういうことです。
（以上）
.
前回の投稿で、ModelやControllerという場所にも表示系ロジックを配置しました。私だって本当はこんなことやりたくない。表示はJSPに任せて、ModelとControllerはロジックに専念させたい。でもそうは行かないのです。
単純な例を上げてみましょう。例えば「10月4日（土曜日）」というデータがあります。このデータを画面に表示したい。JSPには例えば<c:out value="model.date"/>などと書いてある。とすれば、modelビーンのdateフィールドに"10月4日（土曜日）"をセットしてやればよい。JSPは入れ物を準備し、モデルに値をセットしているわけで、これはMVCモデルが美しく機能したと言えるでしょう。
しかし、ここで顧客が一言。「土曜日は背景色を青にしたいな。日曜と祝日は赤だ」。ロジック的には容易な変更です。従って断れない。この要件に対して以下の２つの実装パターンが考えられます。
１．JSP（以下はJSTLの例）で表示ロジックを組み立てる（以下がイメージですが多分この通りに書いても動きません）
<c:choose>
<c:when test="${model.date eq 土曜日}">
<c:out value='<span style="background-color: blue">'/> ... </span>
</c:when>
<c:when test="${model.date eq 日曜日}">
<c:out value='<span style="background-color: red">'/> ... </span>
</c:when>
...（祝日リストはどうするの？当日の表示は？？？面倒くさ！）
</c:choose>
２．Beanの中に表示ロジック込みでデータを入れ込む
Calendar cal = Calendar.getInstance();
cal.setDate(date);
int tmp = cal.get(Calendar.DAY_OF_WEEK);
StringBuffer sb = new StringBuffer();
if (tmp == SATURDAY)
sb.append("<span style="background-color: blue">");
sb.append(date);
sb.append("</span>");
... まあありがち。
１の案は恐らく「Viewに表示を任せるという方針に沿っている」というメリットしかありません。このようにずらずら書かれたJSPをメンテする人がかわいそうです。
２はいろんな意味で美しくはありませんが、少なくともメンテナンスはしやすい。UTもできます。
好みはあるでしょうが、私なら２の案を取ります。Viewの役割に固執するのは意味がないと考えるからです。
以上を センセーショナルにまとめると View という考え方自体現実的には破綻しているともいえます。
なぜか。
それはデータの表示方法はデータの意味と密接に関連しており、それはロジックによって制御されるべきだからです。View として独立させてしいまうのはそもそもムリがある。
もちろん単純なロジックであればJSPなりJSTLなり使ってシンプルに表示できるのが望ましい。メンテも容易だし、結果として美しいコードに仕上がります。しかしそんな容易な表示要件は残念ながら少ないでしょう。
最近MVC2という考え方も出てきていて、これはJSP＋Ajaxなどとして表示を制御するロジックをViewに持つ考えのようですが、これも完全な解決策にはなりません。恐らくはView用に最適化されたAjaxフレームワークができるまで・・・
結論として何が言いたいか。あまりMVCだとかMVC2だとかにこだわらず、センスと経験に任せてデザインするのがよい、そういうことです。
（以上）
.
MVCは作っているうちに破綻する（１／２）
MVCとはアプリケーションの内部のコンポーネントを、Model（データ） View（表示） Controller（ロジック）という３つのレイヤーに分けて考える思想です。例えばJava Webアプリケーションでは Model=JavaBean、View=JSP、Controller=Servlet などと言われたりします。
まあWebアプリを作ったことのある人であれば「こんなに簡単に分けられねーよ」ということを身をもって知っていると思います。実際に作ってみると
▽ Model＝JavaBean + 業務ロジック
▽ View＝JSP＋表示ロジック
▽ Controller＝制御＋業務ロジック
と何となく曖昧に、ロジックとデータと表示が渾然一体になってしまうものです。
もちろん、例えば Actionクラスに一切業務ロジックを持ち込まず「これはコントローラだ」と気合いで分けてしまうことは可能です。しかし、それは単にロジックをファイルに分割したに過ぎない。実際のところアプリケーションは各所にロジックやデータを持つものであり、MVCという区分はあくまで便宜的なものなのです。
つまり、MVCは単なる方針として最初にざっくりと区別しておくだけに留め、それよりもロジックやJavaBeanをキレイに分けてデザインすることに注力した方が結果的にはよい設計になる、ということです。ざっくりと言ってもMとVとCの分類だけではいまいちなので、例えば
▽ Model1（データに近い系）
⇒ DB（DAO）
⇒ JavaBean (※1)
⇒ データ処理系汎用的ユーティリティ（型変換、エンコード／デコード処理など）
(※1) DAOとJavaBeanは分けた方がいいです。
▽ Model2（業務に近い系）
⇒ 業務ロジック
⇒ 業務系汎用ユーティリティ
⇒ 表示制御ロジック ※2
▽ Controller1（フレームワーク系）
⇒ 普通はフレームワークが準備してますね。StrutsのActionクラスとかSpringのControllerとか
▽ Controller2（業務に近い系）
⇒ 業務ロジックに近いController（Validationとか、ロジックによる画面の振り分けとか）
⇒ 表示制御ロジック ※2
(※2)は後述
という感じで区別するのが私の好みです。この分類でパッケージを分けてしまってもよいでしょう。
私見ではデザインの美しさは、JunitによるUTの容易さによって評価され得ると思います。つまりメソッド単位あるいはインターフェース単位で完全に独立しているのが望ましい。あまりMVCにこだわってもしょうがない。どうせMVCという枠組みは曖昧かつゴタゴタになるんだから。
（続く）
.
まあWebアプリを作ったことのある人であれば「こんなに簡単に分けられねーよ」ということを身をもって知っていると思います。実際に作ってみると
▽ Model＝JavaBean + 業務ロジック
▽ View＝JSP＋表示ロジック
▽ Controller＝制御＋業務ロジック
と何となく曖昧に、ロジックとデータと表示が渾然一体になってしまうものです。
もちろん、例えば Actionクラスに一切業務ロジックを持ち込まず「これはコントローラだ」と気合いで分けてしまうことは可能です。しかし、それは単にロジックをファイルに分割したに過ぎない。実際のところアプリケーションは各所にロジックやデータを持つものであり、MVCという区分はあくまで便宜的なものなのです。
つまり、MVCは単なる方針として最初にざっくりと区別しておくだけに留め、それよりもロジックやJavaBeanをキレイに分けてデザインすることに注力した方が結果的にはよい設計になる、ということです。ざっくりと言ってもMとVとCの分類だけではいまいちなので、例えば
▽ Model1（データに近い系）
⇒ DB（DAO）
⇒ JavaBean (※1)
⇒ データ処理系汎用的ユーティリティ（型変換、エンコード／デコード処理など）
(※1) DAOとJavaBeanは分けた方がいいです。
▽ Model2（業務に近い系）
⇒ 業務ロジック
⇒ 業務系汎用ユーティリティ
⇒ 表示制御ロジック ※2
▽ Controller1（フレームワーク系）
⇒ 普通はフレームワークが準備してますね。StrutsのActionクラスとかSpringのControllerとか
▽ Controller2（業務に近い系）
⇒ 業務ロジックに近いController（Validationとか、ロジックによる画面の振り分けとか）
⇒ 表示制御ロジック ※2
(※2)は後述
という感じで区別するのが私の好みです。この分類でパッケージを分けてしまってもよいでしょう。
私見ではデザインの美しさは、JunitによるUTの容易さによって評価され得ると思います。つまりメソッド単位あるいはインターフェース単位で完全に独立しているのが望ましい。あまりMVCにこだわってもしょうがない。どうせMVCという枠組みは曖昧かつゴタゴタになるんだから。
（続く）
.
2008年10月6日月曜日
Struts2を試す（３）
一通りReady, Set, Go!を試しました。
引っ掛かった点は全てblogに書きました。全体的にかなり順調に行った感じがします。
【Ready, Set, Go! 総評】
ぱっと触っただけなので今後変るかもしれませんが、今の所欠点が見当たりません。Spring MVCよりもイケてんじゃないか、というのが印象です。
SpringではXMLの編集、コントローラの作成、Beanの作成を一通り完了しないと画面遷移が作れないところが面倒でしたが、Struts2ではXMLで汎用的な設定をしておけば（下記設定）JSPのガラだけでとりあえずの画面遷移の確認ができます。これは結構便利です。考えられてるな、という気がします。
とりあえずコーディングして、動かして、UTして、という開発手法であれば SpringMVC よりも効率がよいのではないか、と思います。
それに、SpringMVC もそうでしたが、触っていて楽しい。具体的に楽しさとは何かと言えば「こうすればこうなるんだろうな、という予測がビシビシ当たる」それから「よく考えられた設計であることが肌身で感じられる」ことです。フレームワークには非常に重要な要素だと思います。
ただし、柔軟さ、容易さと成果物の複雑さは表裏一体です。言い換えれば、いろいろと柔軟に出来てしまうフレームワークを使うと出来上がったものが複雑になりがちなのです。その点、SpringMVC は適度な窮屈さがあって良いデザインだったと思います。Struts2の便利さが仇にならないか、もう少し見て行こうと思います。
【おまけ】
Localizing Outputで、package.propertiesの日本語版を下記手順で作成しました。（まあ大した手順じゃありません）
dosプロンプトから
などと変換。生成された文字列を"package_ja_JP.properties"に貼り付け（以下のイメージ）
package.propertiesと同じ場所に置く。
以上の手順で問題なく日本語が表示されました。
参考サイト）Javaリソース・プロパティーメモ(Hishidama's Java resource/property Memo)
これは便利）www.Javable.Jp - Tools （プロパティファイルエディタです。面倒くさいnative2ascii変換が不要となります）
引っ掛かった点は全てblogに書きました。全体的にかなり順調に行った感じがします。
【Ready, Set, Go! 総評】
ぱっと触っただけなので今後変るかもしれませんが、今の所欠点が見当たりません。Spring MVCよりもイケてんじゃないか、というのが印象です。
SpringではXMLの編集、コントローラの作成、Beanの作成を一通り完了しないと画面遷移が作れないところが面倒でしたが、Struts2ではXMLで汎用的な設定をしておけば（下記設定）JSPのガラだけでとりあえずの画面遷移の確認ができます。これは結構便利です。考えられてるな、という気がします。
<action name="*">
<result>/{1}.jsp</result>
</action>
とりあえずコーディングして、動かして、UTして、という開発手法であれば SpringMVC よりも効率がよいのではないか、と思います。
それに、SpringMVC もそうでしたが、触っていて楽しい。具体的に楽しさとは何かと言えば「こうすればこうなるんだろうな、という予測がビシビシ当たる」それから「よく考えられた設計であることが肌身で感じられる」ことです。フレームワークには非常に重要な要素だと思います。
ただし、柔軟さ、容易さと成果物の複雑さは表裏一体です。言い換えれば、いろいろと柔軟に出来てしまうフレームワークを使うと出来上がったものが複雑になりがちなのです。その点、SpringMVC は適度な窮屈さがあって良いデザインだったと思います。Struts2の便利さが仇にならないか、もう少し見て行こうと思います。
【おまけ】
Localizing Outputで、package.propertiesの日本語版を下記手順で作成しました。（まあ大した手順じゃありません）
dosプロンプトから
> native2ascii.exe （当然パスが通っているのが前提です）
パスワード
\u30d1\u30b9\u30ef\u30fc\u30c9
ユーザー名
\u30e6\u30fc\u30b6\u30fc\u540d
などと変換。生成された文字列を"package_ja_JP.properties"に貼り付け（以下のイメージ）
requiredstring = $\{getText(fieldName)} \u304c\u5fc5\u8981\u3067\u3059\u3002
password = \u30d1\u30b9\u30ef\u30fc\u30c9
username = \u30e6\u30fc\u30b6\u30fc\u540d
HelloWorld.message = Struts\u306f\u8d77\u52d5\u3057\u3066\u3044\u307e\u3059 ...
Missing.message = \u5de5\u4e8b\u4e2d\u3067\u3059\u3002
package.propertiesと同じ場所に置く。
以上の手順で問題なく日本語が表示されました。
参考サイト）Javaリソース・プロパティーメモ(Hishidama's Java resource/property Memo)
これは便利）www.Javable.Jp - Tools （プロパティファイルエディタです。面倒くさいnative2ascii変換が不要となります）
３０を過ぎてから感じること
今回は本当にどうでもいいような話題です（当人にとっては重要なことですが）。
歳を取るにつれて心身が変ってくることが分かります。３０の半ばとなった今の状況をまとめてみました。
▽ （悪い）秋、冬、春はフケが大量に出るようになりました。
シャンプーしてドライヤーで乾かした直後から一日中、かなりの量が出ます。シャンプーをいいもの（ケミカル合成品ではなく自然石鹸系）に変えても効果なし。恐らく乾燥が原因なのでしょう。頭も痒いです。
乾燥を押さえるため、妻の保湿化粧用品などを試していますが、少しは効果がありそうな感じです。
▽ （悪い）皮膚が痒い
夏と秋に痒さを感じることが増えました。
夏の痒さは格別です。汗かアレルギーかは分かりませんが、そのいずれかだと思っています。
関係があるかどうかは分かりませんが花粉症っぽい症状も出始めました。今の所有効な対策は見えません（というかまだ真剣に対策を考えていません）。
秋は乾燥系の痒さだと思います。体の一部がピリピリして痒い。夏よりはマシです。
▽ （悪い）直近の記憶力の衰え
残念ながら顕著です。何気なく置いたボールペンや書類を忘れて焦って探すことが多くなりました。
△ （良い）
若いときよりもある種の理解力がよくなりました。
－ 本質をつかむ力
悪く言えば大雑把に、よく言えばこまごまとしたことに惑わされずに、問題の構造をすばやく把握する力がついたように思います。経験が蓄積されたのでしょう。
－ 人の気持ちが分かるようになった
歳を取った人が考えることや、昔の偉人が考えたことが理解できるようになりました。
若い人の気持ちも、若いときは若いなりに理解していたのですが、今は別の角度から見られるようになりました。こいつも大変なんだなあ、とか。
幸いまだ大丈夫そうなこと
△ 体力の衰え
数年前から簡単なワークアウト＋柔軟体操を始めたせいだと思います。軽い運動＋本当に軽い柔軟ですが効き目はあるようです。体は大事ですね。
以上です。
歳を取るにつれて心身が変ってくることが分かります。３０の半ばとなった今の状況をまとめてみました。
▽ （悪い）秋、冬、春はフケが大量に出るようになりました。
シャンプーしてドライヤーで乾かした直後から一日中、かなりの量が出ます。シャンプーをいいもの（ケミカル合成品ではなく自然石鹸系）に変えても効果なし。恐らく乾燥が原因なのでしょう。頭も痒いです。
乾燥を押さえるため、妻の保湿化粧用品などを試していますが、少しは効果がありそうな感じです。
▽ （悪い）皮膚が痒い
夏と秋に痒さを感じることが増えました。
夏の痒さは格別です。汗かアレルギーかは分かりませんが、そのいずれかだと思っています。
関係があるかどうかは分かりませんが花粉症っぽい症状も出始めました。今の所有効な対策は見えません（というかまだ真剣に対策を考えていません）。
秋は乾燥系の痒さだと思います。体の一部がピリピリして痒い。夏よりはマシです。
▽ （悪い）直近の記憶力の衰え
残念ながら顕著です。何気なく置いたボールペンや書類を忘れて焦って探すことが多くなりました。
△ （良い）
若いときよりもある種の理解力がよくなりました。
－ 本質をつかむ力
悪く言えば大雑把に、よく言えばこまごまとしたことに惑わされずに、問題の構造をすばやく把握する力がついたように思います。経験が蓄積されたのでしょう。
－ 人の気持ちが分かるようになった
歳を取った人が考えることや、昔の偉人が考えたことが理解できるようになりました。
若い人の気持ちも、若いときは若いなりに理解していたのですが、今は別の角度から見られるようになりました。こいつも大変なんだなあ、とか。
幸いまだ大丈夫そうなこと
△ 体力の衰え
数年前から簡単なワークアウト＋柔軟体操を始めたせいだと思います。軽い運動＋本当に軽い柔軟ですが効き目はあるようです。体は大事ですね。
以上です。
登録:
投稿 (Atom)