現在のプロジェクトでは、XMLとXSL変換を使用してHTMLを生成するか、HTMLテンプレートを直接使用するかを決定する必要があります。なぜXSL変換を選択するのですか？
私はXSLアプローチの議論に興味があります。さまざまなレイアウトをサポートする必要がある場合、XSLソリューションには多くの利点がありますが、1つのターゲットレイアウトのみをサポートする必要がある場合は、なぜそれを選択するのでしょうか？
編集：ここではJavaについて説明しています。
XSLを使用すると、アプリケーションの将来性が保証されます。つまり、レイアウトを変えてテンプレートを追加することを将来決定すれば、その利点を生かすことができます。私の現在のプロジェクトでは、（XMLTypeまたはCLOBで）使用されるXMLを保存し、他のアプリケーションがデータおよびXSLテンプレートにアクセスしてWebサービス経由でドキュメントを生成できるようにします。これは、XML/XSLの使用を決定したために実装が簡単だったオリジナルのデザインを考えた後です。
HTMLとは対照的に、どのような方法でもテンプレートの解析と処理が必要な場合は、多くのXMLツールが利用できます。 XMLのためにツールとライブラリを使用する利点を得るには、XMLを選択する必要があります。
しかし、XHTMLは、現代のWebブラウザで正しく処理されている通常のHTMLでありながら、XMLツールやライブラリを完全にサポートしているので、あなたのニーズに合ったものかもしれません。後の処理を後で行う必要がある場合でも、XSLTをXHTMLデータに適用できます。
ウェブフロントエンドにXML/XSLTを使用しないでください。私はこのようなプロジェクトに参加していて、恐ろしいことです。多くの場合、オブジェクトやそれに類するものからXMLを生成する必要がありますが、これは意味をなさないものです。もう一つのポイントは、そこに多くの良いHTMLエディタが無料であることですが、私はXSLTには何も見つかりませんでした。複雑なXSLTを編集するのは楽しいことではありません。 HTMLテンプレートと共通のテンプレートエンジンを使うことをお勧めします。
JAXB、およびJAX-RS、XSLを統合したJavaフレームワーク[ReXSL]（http://www.rexsl.com）の口コミを書いて興味がある可能性がありXMLの編集でまた、Visual Studio 2008はXML/XSLT（デバッグを含む）に最適です！ –
SingStarで作業しているときに、
XSLTは、他のドキュメントタイプ（つまりpdf）でも出力を生成できるという利点があり、現在はpdf出力が非常に一般的です。 XML/XSLTはビューからデータを分離します。
+1ありがとうございます。 PDFのFOPは良い例です。 –
すべての正直なところ、非XMLを生成することはできますが、めったに行われません。おそらくPDFを除いて。 私はそれをPDF以外の重要な要素とは考えていません。 私はまた、ソースデータ自体が自然にxmlでない場合は、データ/ビューの別々のものが全体として大変だとは思わない。そうであれば、すでに分離がある可能性があります（プレゼンテーション用の入力データ - >テンプレート） – StaxMan
あなたのデータが既にXMLの場合、XSLのアプローチがどのように役立つかを見ています。
しかし、通常そうではありません。それはデータベースのどこかにあり、その場で生成する必要があります。
このソースからXMLを作成し、そのXMLからHTMLを作成できるようにすることは、私の意見では役に立たない。私は（X）のHTMLテンプレートに固執します。
完全に個人的なレベルでは、XSLはすべてのXMLのアイデア全体の子です。それに直面すると、XMLはすべてのソリューションのための良いデータフォーマットではありません。 –
私は絶対に同意します - ソースデータがxmlであれば、xsltは意味があります。そうでなければ、ほとんど意味がないでしょう。 – StaxMan
その後、XSLTを経由してXHTMLに変換されたXML層はまた、あなたがXML層に簡単にWebサービスを記述することができ、meens持つ、アプリケーションによっては - あなたの顧客があなたのサイトのデータを消費することができます...
XMLを変換リンク（正確な構文を忘れてしまった...）でブラウザーに送ると、XSLTファイルも同じままで、必要な帯域幅は少なくなります。元のXMLを渡すだけです）
私はクライアントで変身する可能性について言及しています。 –
XSLTは関数型プログラミング言語であり、どのテンプレートシステムと同様に豊富なフロントエンドを作成することができます。しかし、あなたとあなたのチームは狂気にならないはずはありません。
両方のオプションは、オブジェクトを論理形式で表現形式に変換する機会を提供します。XSLTは、より多くのXMLを作成するのに最適です。これは、XHTMLを作成するのに最適な候補だと信じさせるかもしれません。ただし、XHTMLを作成することは主な目標ではありません。のユーザーエクスペリエンスを作成することはです。 メディアには関心がありません。
XSLTの2つの重大な欠点は、構文に関係します。テンプレートとそれに含まれるテンプレート、それらのテンプレートに含まれるテンプレートはすべて巨大で冗長です。第2に、多くの関数型プログラミングを行う必要があります。経験の少ないエンジニアは、単純なforループの代わりに累積関数パラメータを持つ再帰型テンプレートに遭遇すると、混乱し恐れがあります。
論理的に構築された有効なXMLエンティティを変換することの美しさに魅了されている場合は、代わりに代わりに型変換可能なテンプレートシステムを検討してください。 Google XML Pagesをチェックし、論理的に組織化されたタイプセーフなテンプレートを作成してください。これは将来のエンジニアが簡単に取り上げて拡張することができます。
リンクされたGoogle XMLページは、2015年8月24日以降のGoogleコードの読み取り専用ページに基づいて、まだベータ0.2になっています。 – surfmuggle
これまでXSLTを行っていたとき、私たちの製品を拡張することができました。出力は変わらず、プレゼンテーション層だけを変更する必要がありました。これにより、UIを「カスタマイズ」したいクライアントがあったときに、XSLTファイルを置き換えるだけで済むので、柔軟性が大幅に向上しました。こうした種類の変更をたくさんする必要があることがわかったら、XSLTがあなたの答えかもしれません。
ただし、前述のように、XSLTの構文と機能プログラミングの考え方によって、効果的にテンプレートを作成することが困難になる可能性があります。私たちは、私たちが学んだ技を守りたいと思っていました。私たちがすでに知っていたこと以外のクライアント要求を受けたときは、誰もそのボランティアをしたくありませんでした。通常、誰かが最終的にどのようにタスクを実行するかを把握し、「トリックオブバッグ」は大きくなっていますが、新しいことを理解することはしばしば非常に面倒です。
UIの変更が予想されない場合、または少なくともそれほど多くない場合、XSLTは余計な努力をする価値はないかもしれません。
私たちはコンテンツ管理システムでHTMLを生成するためにXSLTを使用しています。うまく動作します。
いくつかのヒント：1つの大きなヘアリーXMLからすべてのページを一度に生成しようとしないと、あなたは狂ってしまうでしょう。埋め込まれたマーカー（例えば、<！ - MENU->、<！ - CONTENT->）を持つHTMLテンプレート（スタイル、デコレーション、基本マークアップを含むプレーンテキスト/ htmlファイル）を使用し、マーカーをxslt-transformation適切なデータの
私はあなたが本当に1つのレイアウトしか持たないなら、あなたは本当にxsltが必要なのか疑問に思っています。
私はあなたのデータの出所を調べる必要があると思います。 Boris Callensが以前に述べたように、データベースから取り出す場合は、最初にXMLに変換してから変換を適用する必要があります。データソースがRSSなどである場合、XSLTは当然の選択です。
XPATHとXSLTは高い学習曲線を持ち、機能プログラミングはあなたの腕を掴むのに大変なことがあります。タイムクランチでは、これは正しい選択ではないかもしれません。
フロントエンドの作業JSONは軽量のペイロードを持ち、jQueryやその他のJavascriptライブラリで容易にサポートされています。 jQueryライブラリは開発者がはるかにアクセスしやすく、フレームワークによる生産性の時間は、XSLT、組み込みのJavascriptタグ、ひどい構文、それに付随する他のすべての細目よりはるかに少ないため、JSONをデータプロトコルと見なすことができますフロントエンドのXML/XPATH/XSLT
私は以前のプロジェクト、金融ウェブサイトでXML & XSLTを使用しました、そして、それは私たちのためにうまく働いたが、：私たちは、私たちが持っていた出力の数を変化させ 複数の顧客を、持っていた
:-)あまりにもハードではなかったですサイトはすべて同じXMLに基づいていますが、異なるHTML出力が必要です。
ポイント1 + 3はテンプレートシステムによって容易に満足されます –
これは本当です。しかし、当時はあまり多くはなかった。 –
簡単にしてください。それは、人がますます高く評価されるという原則です。
VelocityまたはFreemarkerは信じられないほど柔軟で多用途です。あなたのコードベースは明確で分かりやすく、Xモンスターよりもずっと速く動くでしょう。
約5年前にエンタープライズ製品のXML/XSLT駆動UIを作成しました。我々はまだそれを使用している、と私は今、私の経験を振り返ると、多くの長所と短所を見ることができます：
長所：、
短所HTMLについてスマートです新しいプログラマ - そして、より少ない人がXSLTをよく知っている。
（あなたがXMLデータを渡すために含むか、またはより高速な方法を使用することを開始し、具体的として）あなたのツールがあなたをサポートすることで、Y。私は今戻って考えると、私の評決は共通のテンプレート言語に固執することでしょう。かつてXML/XSLTを選択したときに大きな問題になったのは、主要なテンプレートエンジンのより新しい、より成熟したリビジョンによって解決されました。ほとんどのテンプレートエンジンでうまく行かないものである.xsltファイルを継承する機能は、依然として大きなメリットをもたらします。しかし、最終的には、例を提供する多くの開発者を抱えることの価値は、はるかに大きいです（ASP.NETの回答とStackOverflowのXSLTの回答を比較してください）。
希望に役立ちます！
XML + XSLTは本当にクールです。将来、多くのタイプのターゲット・フォーマットを出力することができます。 しかし、XMLに埋め込まれたHTMLを認識していません。 Firefox XSLTは "disable-output-escaping"をサポートしていません。 Bugzillaを参照してください。
私はXSLTを使用して大幅な開発を行いました。これは、2つの異なるサイトで非常に成功し、完全に失敗しました。
結論の前にいくつかの考え：
私は、誰もがXSLTは、はるかに強力なテンプレート解析エンジンよりも、それは関数型言語だと主張するだろうとは思いません。
ほとんどの手続き型言語ほど広く採用されているわけではありませんが、それは実際のプロジェクトで使用されている現実の言語ですが、XSLTの知識を持って人を雇うことができます。
XSLTも今のところ実装が成熟していますが、これは（Velocityのような）長時間実行されているテンプレートエンジンのケースだと確信していますが、新しいエンジンの方が堅牢性が低い可能性があります。
あなたが決めたテンプレート言語は、XSLTとしてもよく書かれているとは思えません。マイケル・ケイ・プログラマーのリファレンス・シリーズを参照して、素晴らしい参考書の作成方法の例を確認してください。
ツールのサポートは一般的に非常に良いです...予算がある場合は、 XMLSpyとスタイラススタジオは、私にとってこれまでずっと便利でした。
XSLTはハードだけでなく、もっと重要なことに、異なるものです。ほとんどの人は、コンピュータ科学の卒業生が正式に機能プログラミングを習得したわけではありません。プログラマの大部分は、XSLTを手続き型スタイルで記述します。このスタイルは言語の力を利用せず、メンテナンスの頭痛を与えます。
XSLT変換が遅くなり、大量のメモリが必要になる可能性があります。大規模なXML入力があるスタイルシートを使用していると問題が発生することがあります。
は、あなたがXSLTにコミットしていますか？あなたは、XSLTに深い社内専門知識を持っていますか？あなたはいくつかを用意する準備ができていますか？
あなたのデータはXMLですか？それはXMLで理にかなっていますか？社内の誰かが十分に構造化されていることを確認するのに十分なデータを愛し、常に適切なスキーマがある人はいますか？
これらの質問に対する答えが「はい」で、複雑なレンダリングプロセスを必要とする複雑なデータがない限り、XSLTの使用は検討しません。特にチームに経験がない場合は特にそうです。悪いXSLTは、悪いテンプレートよりはるかに悪いです。
しかし、今日のテンプレートエンジンの多くを使用することは不可能な、維持可能な方法で複雑なデータをレンダリングすることができます。
あなたは実際に、私はVimは本当に良い見つける – yegor256