2011-01-14 4 views
9

Sitecoreを学んでいるうちに、Web上のSitecoreサンプルコードの大部分が.NETではなくXSLにあることがわかりました。C#ではなくSitecoreでXSLを使用する利点は何ですか?

私は.NET開発者として慣れてきたプロセスよりもXSLを選択する利点はありますか?

XSLを使用すると処理速度が向上しますか?

構文に慣れたら、実際にXSLは簡単ですか?

+0

この種の質問(「YではなくXのアドベンチャー」)は主観的で議論の的です。 –

+0

@Alejandro私はもう一度それを見ていることに同意します。質問の変更に関する考えは?そうでない場合は、@ James Walfordの回答を受け入れる予定です – JoshBaltzell

答えて

7

:-)言われて、私はすべての私のサイトコアの開発をはるかに上回る95%のための.NETを使用することを

私自身は、私はあまりにも私の2セントを追加します:

を私もそこにあることを見つけます外部の "ライブラリ"やXSLTで使用できるC#のメソッドを開発することで克服する必要があるXSLTの多くの制限事項

私はAsp.Netを簡単に使用しています。しかし、私はXSLTよりもAsp.Netの方がはるかに優れています。

しかし、XSLTは、いくつかの良いものがあります。

  • 良いが、単純なコンテンツを持つ
  • 良い現在のコンテキスト項目から取得フィールドがなど
  • リサイクルするための解決策を強制するものではありません/
  • を再構築
  • 通常はうまくいかない、つまり失敗します。ページはまだ動作しますが、失敗したXSLTは、それが

私が最初にサイトコアで作業を開始し、私の会社は、XSLTのかなりを使用失敗したと言うが、それには限界がありますのために、私たちはゆっくりと、離れているから行ってきましたここのほとんどの人がAsp.Net/C#にもっと精通しているからです。

3

既存のチームスキルセット、XSL才能の利用可能性、またはXSLが学ぶのが簡単で安価であるとの信念のため、XSLを好む人もいます。

Sitecoreでは、ASP.NETベースのサブレイアウトは実際にはXSLレンダリングよりもはるかに優れています。それがあなたが快適であれば、それに行きなさい。自分でXSLレンダリングを作成したことはありません。

3

XSLTは強力な言語です。 ASP.NETのような言語よりも主な利点は、さまざまな異なるページや共通の共有要素やその他の可変構造を持つさまざまなソースドキュメント構造でロジックを再利用およびカスタマイズしたいときです。これを達成するために、ルールベースの処理モデルを使用します。このモデルでは、最初の遭遇時に把握するのがかなり難しい人がいます。それを学ぶことは、時間の経過とともに恩恵を受ける投資ですが、最初は気にすることができます。

パフォーマンスに関しては、仕事には十分に速くないサイトに出くわしたことはありません。それにはかなりストレスの多いサービスも含まれています。人々がパフォーマンス上の問題を抱えている場合、通常は処理パイプラインの他の部分にあることが判明しています(または単にコーディングが悪いため)。

+0

Sitecoreを具体的に参照すると、Sitecoreの実装方法によってXSLTのパフォーマンスが低下することがあります。 XML構造は非常に汎用的なものであり、名前ではなくノード値をテストすることを意味します。ノードの深さもまた問題の可能性があり、再帰的な検索は高価になります。 Sitecoreの実装では、プロセッサを選択することはできませんが、それをカスタマイズすることはそれほど難しくありません。最後に、C#のいくつかのXSLT拡張にも依存していますが、これには独自の欠点があります。 –

+0

続き... Sitecoreで見たことから、.NETは通常、最も基本的な単純なタスク以外の何かを行うプレゼンテーションコンポーネントを追加する効率的な方法です。また、ほとんどのXSLT開発者にとっては直感的な方法であるSitecore XSLTのベストプラクティス(For eachを使用するなど)もあります。 –

3

SitecoreのXSLTと.Netコンポーネントの選択は、主に味とスキルの1つです。 SitecoreのXSLTにはいくつかの欠点があります。最も単純なレンダリングや、コンテンツツリー構造をサイトメニューとして複製するなど、最も使いやすいと思われる場所では、.NETコンポーネントによってパフォーマンスが向上する傾向があります。実際には最大のパフォーマンスヒットを起こす傾向があります。適切な状況では、XSLTは信じられないほど強力なツールであり、学ぶだけの価値がありますが、私はSitecoreでそれを大いに活用するための説得力のある議論をまだ見ていません。また、XSLTプログラミングの標準パターンのいくつかがSitecoreで最も効率的ではないことにも注意してください。

3

私が考えることができる唯一の真のメリットは、XSLTのレンダリングを単独で展開する方が簡単なことです。たとえば、 "ニューススポット"のレンダリングを更新していて、この変更をテスト/プロダクションにすぐに配備したいとします。これは、.xslファイル自体をアップロードする単純なケースです。

.NET開発を使用して(そしてWebアプリケーションプロジェクトモデルに耐えられる)、コードベースを展開すると、進行中の作業を含め、影響を受けるアセンブリにすべての変更が暗黙的に展開されます。

これを管理する方法はもちろんあります。ソースコードの分岐/マージなど - これは、ソリューションの複雑さの追加層です。

3

"ソフトウェア設計とコーディングの主な目的は複雑さを克服することです。多くのプログラミング慣行の背景にあるのは、プログラムの複雑さを軽減することです。 -Steve McConnell(1993)

このガイドでは、C#でXSLTを使用する場合を説明します。

関連する問題