質問
サイト全体をXML / XSLに変換しました。クライアント側XSLTの実行に関する現在の問題をすべて知りたいです。
これは私がすでに知っているものです(実際の経験から):
- クロスドメインXSLファイル(これはセキュリティの問題であり、クロスブラウザではありません)
- disable-output-escaping(これはFFでは機能しません...彼らはそれをセキュリティ上の問題と考えています)
また、ブラウザのサポートについては、これが私が知っているすべてです:
- Opera 9 +
- FF 1.0 +
- SF 2.0 +(これは間違っている可能性があります)
- Chrome
- IE 6.0 +
他の人も役に立ちます:)
編集:
2番目の落とし穴については、xhtmlをxslに渡すことができる適切な回避策があります。実際に変換し、XHTMLが有効なXMLであることを確認し、XMLとしてXMLに配置することで機能します。次に、XSLでxmlをコピーし;)、XHTMLとして出力します。
解決
-
速度:ブラウザは、HTMLをレンダリングする前にXSLT変換を適用する必要があるため、ユーザーはページを表示するのに長い時間待つ必要があります。ブラウザーで使用されるXSLTエンジンは一流ではない場合があります。 Mac OS Xでは、XMLの変換中にブラウザーがフリーズし、<!> quot;ビーチボールの回転<!> quot;カーソル、したがって、ユーザーは画面をパンチし、彼または彼女を傷つける可能性があります。
-
アクセシビリティ:スクリーンリーダーなど、そのセットに含まれないブラウザーについてはどうですか?それらのユーザーはあなたにとって重要ですか?
他のヒント
パフォーマンスの面では、最近のクライアントの大部分にはそれぞれ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はそのために脱落しました。
iは、xslt + xml-<!> gtを使用したプロジェクトで約1年働いています。 html(サーバー側のみ)
私が遭遇した主な欠点:ウェブ開発に傾倒するxslt生成のための良いツールはありません。 htmlのプレビューはありません。検証なし。 結果として生じるxsltは、だれも理解できない完全な混乱でした。それはxsltの設計者のせいではなく、xslt処理モデルの結果です。
xslt / xml / urls間の階層化は、本来よりも複雑になります。コンポーネント指向をプログラムする方法はありません。
多くの場合、複数のxsltファイルが必要でした。これにより、クライアント側で多くのダウンロードが発生しました。そうしないと、プロジェクト全体で大規模なコードの重複が発生します。
iは、これを早期の最適化の一形態と見なします。 <!> quot; normal <!> quotを使用して開始する必要があります。 wicket、jsf、tapestry、gwtなどのWebフレームワーク。後でサーバーのパフォーマンスがCPUにバインドされていることが判明した場合は、アプリケーションの最も頻繁に使用される部分をそのように書き換える必要があります。
otoh、xml api + htmlインターフェースの両方を提供する必要がある場合、それは本当の利点があります。
XSLTファイルはダウンロードする必要がある別のオブジェクトであり、ブラウザーは2つまたは3つのアイテムのみを並行してフェッチします。私の経験では、全体的なパフォーマンス(ダウンロードと生成)が著しく遅くなっています。
また、データの複雑さと冗長性によっては、実際に必要なものよりもはるかに多くダウンロードする場合があります。 HTMLが既にレンダリングされている場合。