<?xml version="1.0" encoding="Shift_JIS" ?>

<document>

 <properties>
  <title>Case Study: XMLC vs. Velocity</title>
  <author email="geirm@apache.org">Velocity Documentation Team</author>
  <translator>熊坂祐二</translator>
  <original>casestudy2</original>
 </properties>

<body>

<section name="事例研究: XMLC vs. Velocity">

<p>
少し前に、XMLC と Velocity についての質問が Jakarta Tomcat メーリングリスト
でされました。それに対する、Bojan Smojver &lt; bojan@binarix.com&gt; 
の興味深い回答を彼の許可のもとこの Velocity サイトで提示しています。
</p>

<source><![CDATA[

私は、XMLC のチュートリアルでこれを見つけました：

------------------
XMLC は、Hypertext Markup Language（HTML）または拡張可能な
マークアップ言語(XML)で書かれる文書をとる Java ベースのコンパイラで、
忠実にドキュメントを再現する Java クラスを作成します。
結果として発生する Java クラスが、実行時に動的な内容を
文書フレームワークに挿入するために使うことができます。
XMLC は、したがって、Java からダイナミックな HTML や XML
文書をつくる素晴らしい方法です。
------------------


これは私には、とても JSP のように聞こえます。そして、
それは誰かが Velocity を使う理由 #1 です。

私が Web 作業のために Velocity を使うけれども、
Velocity は一般的なテンプレート・エンジンです、
それは本当に後の内容を気にかけません。
そして、それは素晴らしいです！

私は、私のドキュメントを XML から XHTML に準備するために
XSLT を使います(ごめんジョン、Anakia に別の調査を与えると約束します:-)、
XHTML（cocoon 以外の様に、これは実行された時間にされません）と
Velocity に XML から私の文書を準備することはあまりそれにかき乱されません
（あなたには『&&』があることができないという事実を除いて（VTL、そして）
2、3のトリックを適用することのない XSLT で）私が
Ant の素晴らしい置き換えテクニック...を通してそれを克服しました

とにかく、XMLC への最初の短所はコード生成の苦労につきます。
そして、Velocity はとてもきれいにそれを避けます。

http://xmlc.enhydra.org/project/aboutProject/index.html

第二は、ここで描かれる完全なソリューションを設計する実際のプロセスです：
http://xmlc.enhydra.org/project/aboutProject/index.html


デザイナーは、まずページを設計してそれから、エンジニアがロジックを置く?
これは、私に非常に悪く聞こえます。
それとは反対ではなく、デザイナーが彼らの機能を選ぶことができる
『レゴでいっぱいの箱』が、あるはずです。
エンジニアが単純なプロジェクトに関係していなければならないならば、
第一にすべてをすることはエンジニアを雇用することに戻ります。
そして、なぜ、あなたはそのような場合 JSP や ECS さえ使わないのでしょうか？
あなたは、再び Java で乱雑になります...。
XMLC サイクルはあまりに長くいだけでまったく意味をなしません−
デザイナーが（誤ってまたは故意に）ページで id を台無しにしたら
何が起こりますか？ エンジニアのコードの全ては、使えなくなります。
さて、それはプレゼンテーションと機能の間の素晴らしい分離です！

第二の欠点。

Velocity で上記を取り扱う方法を示したのは、私の「製品ライン」からの例です。
私は、全ての問合せフォームを取り扱う2、3のクラスがあります：
1つのクラスはフォームとストアからフィールドを取り扱い、データベースにそれら、
他のものはフィールドを選んで、それらを指定のe-メール・アドレスにメールします。
これらのクラスは bean であって、私がこれまでに使う（ GPL を認可ですが、私が
書いたのでたくさんのバグが含まれます)ひとつの servlet からロードされます。
そして、それは全ての Velocity ページを取り扱います：
331行には、コメントも含まれます。
JSP と同じように、Beans は、scope と全てがあります。

一度、最初にフォームが作成され、デバッグされた架空の Web デザイナーが
私の「製品ライン」で、既存の Velocity ページを以前のプロジェクトからコピーして
フィールドを変更(名前、数、その他いろいろ)して、他のコンテンツにします。
いったん、サイトにページを置けばそれだけです。これで動作します。
エンジニアとこのことについ離す必要もありません。これが XMLC よりも
すごく良い点です。

私は、XMLC、JSP と servlets が直面している最も大きい問題は、
哲学上の本質により多くあると考えます:
文書はデータであり、コードではありません。そして、
Velocity は正確にそのように扱います。
なぜ、あなたがテキストとしてブラウザに送りたいとき、
あなたの HTML を Java クラスに変えるのでしょうか？


My 2 cents. Velocity rocks!

Bojan

]]></source>

</section>

</body>
</document>
