フレームワークは数あれどデザイナーの作るHTMLにコードを埋めるテンプレートフレームワークは失格だよね。Strruts,JSP,XSL、Velocity、みんな使えない。

どれもこれも開発工程を考えてないし、手戻りのことが考えられていない。HTML→XSLなんかに変換してしまった日には、デザイン修正があったらどうすんの？大規模修正があったら、これ一つに1人日費やすのは選択ミス以外の何物でもない。とにかく、for eachとif文をデザインコードに埋め込むコードは最悪ね。とにかく、こういうのはHTMLタグに重きをおかないエンジニアonlyの発想でしかない。

また、変換入れると、マスターデザインのデータが２つになることを意味しているわけ。ここで修正ミス、デザインの不一致が起きうる。XSL使ってみたら、実際起きてるし。

そもそもモノ作りとは、何かの状態遷移をもたらすことで発生するビジネスであるならば、その変換工程の数は少ないほど儲かるはずだ。

MTやxoopsなどのテンプレートをDreamWeaverで編集することでたどり着いたのは、やはりダミーでも文字が入ってるほうが良い。つまり、完成品のデザインHTMLはそのままテンプレートとして、シームレスに使えるべし！

WOタグとか、jspのカスタムタグも違うんだ。単純に　[div id="なにがし"]にょろにょろ[/div]の中身を置換してくれるテンプレートエンジンが欲しいなと思ってたら、既に考える人は沢山いて、jakartaのTapestryお前じゃないか！と。

とりあえず、以下、自分用ブックマーク
Tapestry本家
Tapestryについて
Tapestryを使おう
Tapestryについて語ろうよ！

以下、すごく重要なことなんだけど、わからない人が恐れおののく方法でテンプレートを作ってはいけない。HTMLそのまんまで拡張子がｊspになってるだけで、みんな怖がるのが人の心理ってもの。別にこれを修行が足りないとは必ずしも思わない。デザイナーに対する期待値の問題だけど、僕はデザイナーはHTML + 簡単なJavaScriptまで。複雑なJavaScript以降は開発者の仕事だと思っている。JavaScriptをナメるなよ。

blognaviで見つけた、先端技術情報センターさんの知識の営業が知識流通によると、知識の流通には、

>・相手を安心させなければならない
>・重要なのは、プロセスをコントロールすること。買い手をコントロールしてはいけない

が必要だということ。

これは、まさにITが実現すべきことを表しているし、ソフトウエアプロダクトの究極の本質だよね。
使えないプロダクトが出ては消えていくのは、ここんところの訴求がうまく行ってないからに他ならないだろうし、受託だと運用に押し付けちゃうことで妥協してるだけだし。

アップルが潰れないのは、ここの訴求のプロフェッショナルだから。OS9みたいな、現代のOSとして品質的に明らかにカスなOSが長らく支持されるのが、ここのところであり、上記の引用と組み合わせ、何がソフトウエアの本質か？を改めて思い知らされる。

もちろん、こういうのは本題の開発工程のフレームワークにも当てはまるべき。

ただ、Tapestry、今欲しい機能までは達してないんだよなぁ。僕が欲しいのは、テンプレートエンジンなので単純にservletやStrutsの置き換えだけでは困るんだ。
かと言って発展途上のコードを改造しても、後々良いことないし。

いろんな意味で悩まされる。でも、同じ事を考えてる人いるんだなぁってことで安心したよ。なんか激しい落とし穴があって、尊敬する先人方は、みんな回避せざるを得なかったのかな？とか不安に思ってたので。