サイト全体を XML/XSL に変換しました。クライアント側 XSLT の実行に関する現在の問題をすべて知りたいです。
これが私がすでに知っているものです（直接の経験から）：
また、ブラウザのサポートに関しては、これが私が知っているすべてです：
他の人も役に立ちます:)
編集：
2 番目の落とし穴については、xhtml を xsl に渡すことができる適切な回避策があります。XHTML が有効な XML であることを実際に変換して確認し、それを XML として XML に配置することによって機能します。次に、XSL で xml をコピーし、それを XHTML として出力します。
速度：ブラウザーはHTMLをレンダリングする前にXSLT変換を適用する必要があるため、ユーザーはページが表示されるまでさらに長く待つ必要があります。ブラウザで使用されるXSLTエンジンは、一流ではない可能性があります。Mac OS Xでは、XMLの変換中にブラウザがフリーズし、「スピニングビーチボール」カーソルが発生する可能性があります。そのため、ユーザーは画面をパンチして怪我をする可能性があります。
アクセシビリティ：スクリーンリーダーなど、そのセットに含まれていないブラウザについてはどうですか？それらのユーザーはあなたにとって重要ですか？
パフォーマンスの面では... 最近のクライアントの大半はそれぞれ 2 つの CPU と 2 GB の RAM を搭載しており、ほとんどのサーバーには搭載されていないことを考慮してください... 2 つの CPU + クライアントごとに 2 GB を搭載しています。したがって、XSLT 変換をオフロードすることでスケーラビリティが向上し、CSS + XSLT + JS をキャッシュすることで全体的なトラフィックが削減されることは確かに論理的です。
過去に XSLT を使用して SVG を含む XHTML を生成しようとしたことがあり、壮大な失敗がありました。最大のページは単純に大きすぎ (インデックスに 3,000 以上のエントリ)、IE は DOM を使用して XSLT 変換を行うため、ゴミ箱に移動し始めます。xerces-j (サーバー上、同じ開発ボックス上) で行われた同じ変換は、約 1000 倍高速でした。
ブラウザモンキーがプログラムを手に入れる時が来ました;-)
興味深い議論。上げてくれてありがとう。
乾杯。キース。
パラメータを xsltfiles に渡すと、クロスブラウジングを維持するのが難しいことがわかりました。私は現在FFとIEをサポートしていますが、Chromeはそれが原因で落ちました..
xslt+xml-> html を使用するプロジェクトで約 1 年間働いています (ただし、サーバー側のみ)。
私が遭遇した主な欠点は、Web 開発に傾倒する xslt 生成用の優れたツールがないことです。html のプレビューはありません。検証なし。結果として得られた xslt は、誰も理解できない完全な混乱でした。これは xslt 設計者のせいではなく、xslt 処理モデルに起因するものです。
xslt/xml/urls 間の階層化は、必要以上に複雑になります。コンポーネント指向でプログラミングする方法はありません。
多くの場合、複数の xslt ファイルが必要でした。これにより、クライアント側で多くのダウンロードが発生します。そうしないと、プロジェクト全体で大量のコードの重複が発生します。
私はこれを初期の最適化の一形態と考えています。wicket、jsf、tapestry、gwt などの「通常の」Web フレームワークを使用して開始する必要があります。後で、サーバーのパフォーマンスが CPU バウンドであることが判明した場合は、アプリケーションの最も頻繁に使用される部分をそのように書き直すことを検討するかもしれません。
おっと、xml api と html インターフェースの両方を提供する必要がある場合は、本当の利点があります。
XSLT ファイルは、ダウンロードする必要がある別のオブジェクトであり、ブラウザーは 2 つまたは 3 つの項目のみを並行してフェッチします。私の経験では、全体的なパフォーマンス (ダウンロードと生成) が著しく遅くなります。
また、データの複雑さと冗長性によっては、必要以上にダウンロードしている可能性があります。HTML が既にレンダリングされている場合。