XML / XSLTテクノロジーのリハビリテーション

こんにちは、Habr。 少し前に、CMSに、その時点ですでに存在していた独自のテンプレートエンジン、およびXSLTを実装しました。 XSLTには、開発者、スタジオ所有者、さらにはWebサイト所有者にとっても大きな利点があります。 しかし、私たちのパートナーの反応は反対意見に分かれました：長い間これを期待していて、その機会に喜んでいた人もいれば、XSLTの使用が伴うと言われる生産性の低さを理由に、XSLTの関連性に疑問を呈する人もいました。

新しいものには常に支持者と反対者がいて、彼らの時間が判断することは明らかです。 したがって、当時の宗教戦争XSLT vs tplまたはSmartyを解き放つことはあまり意味がありませんでした。 しかし、ロシアのCMS市場のリーダーの1人がen望の持てる強さで書いており、XSLTの大衆技術としての破産について書いており、特定のタスクのコンテキストでのみ検討する準備ができていることがわかりました。 そして、これは、XSLTに関して初心者の開発者の心に悪影響を及ぼします。







一方、最近のヨーロッパ最大のIT展示会CeBIT は 、ほとんどの主要な西部CMS（ボックス型プラットフォームと内部プラットフォームの両方）が単一の統一標準としてXML / XSLTを使用していることを示しました。 それでも、新しいテクノロジーの実装速度という点でロシアのIT市場は、西欧のIT市場にやや遅れています。 この背景に反して、XSLTが全世界で使用している間にXSLTが吸うという事実について話すことは、完全に有用で正確ではありません。



したがって、Habréに登録した私は、不当に気分を害するXSLTのリハビリテーションの試みから始めます。 私の意見では、CMS市場参加者の責任は、正確に現代の技術を促進し、独自の技術的旗艦になることです。 そして、たとえ自分でうまくいかなかったり、好きではなかったとしても、彼らを信用しないでください。 すでにXSLTについて知っている人や読むことさえできません。 この記事は、まだ主題に含まれていない、または疑わしい人向けです。 同意しない人-ホリバーを手配しないでください。 誰もが自分の意見を表明する権利を持っています。

XSLTテンプレートエンジン、Smartyおよび内部tplボックス化CMS。

XSLTの技術的利点はすべて、XSLTに規定されている基本概念（ビジネスロジックとプレゼンテーションロジックの完全な分離）に基づいています。 プレゼンテーションモデルとビジネスロジックモデルを混在させることは、プログラマの大罪です。 そして、非常に低い資格を持つ人だけがこれに同意しません。 同時に、例えば、非常に人気のあるSmartyテンプレートエンジンは、プレゼンテーションレベルでテンプレートにビジネスロジックを実装できるだけでなく、開発者をこれにプッシュし、即座の問題の迅速な解決策を誘います。 これにより、テンプレートとスクリプト間のリンクの非構造化チェーンがその後になり、雪だるま式に成長し、最終的に制御不能になります。 その結果、たとえば、テンプレートで使用されている1つのメソッドを変更すると、テンプレート全体が「フォール」します。



拡張タスクは、プロジェクトを最初に主導した開発者にとっても、「すべてをゼロから書く」ことに匹敵します。 このプロジェクトを別の開発者に移すことが不可能になるという事実は言うまでもありません。 したがって、複雑で特に非標準の実装では、作成されたプロジェクトが開発者から不可侵になるため、疎外可能なCMSを使用する利点はSmartyの使用によって部分的に相殺されます。 ほとんどの場合、開発者を変えることは、非常に「ゼロから書き直す」ことを意味します。逆説的に言えば、この場合、「他の人」のコードを学ぶのに必要な労力よりも有益です。 明らかに、この決定は最適ではなく、かなり大量の財政的注入の別のバッチを必要とします。



したがって、このようなテンプレートエンジンを使用して作成された深刻なプロジェクトの所有コストが低いことは言えません。 もちろん、プロジェクトが小規模の場合、開発者の変更は予想されないか、すぐに作成して忘れる必要があります。Smartyの方が適しています。



また、SmartyがCMSで使用されている場合、「愚か者から」の不安に注意することはできません。Smartyを「使用する」低レベルの侵入者は、データベースクエリをテンプレートに簡単に直接記述し、システム全体を停止できます。



CMSのネイティブtpl-templateエンジンの重要な特徴は、その個性です。 ほとんどの場合、特定のCMSごとに作成されます。 個々のテンプレートエンジンには、実装者による予備調査が必要であり、これにより開発コストが増加します。



その結果、実際には、Smartyはシンプルで使い慣れているが、あまり柔軟性がなく、拡張可能ではなく、開発者から少し疎外されており、潜在的に安全でないことを示しています。 これらの欠陥は、ビジネスロジックとデータ表示モデルの混乱を常に伴います。 そして、この観点から、Smartyやそれに類するものはXSLTテクノロジーのアンチテーゼであり、実際にはこれらすべての欠点を排除するために作成されました。

XSLTの10個の引数

技術の信頼性



1）XSLTは、W3Cでサポートされている長年確立された業界標準です。 プロの開発者の大規模なチームによって開発されています。 技術は、質の高いサポートのために絶えず改善および更新されています。 XSLTは世界中で長い間レイアウト標準として認識されており、ロシアではYandexやMy Circleなどの大規模プロジェクトで使用されています。

安全性



2）ビジネスロジックとデータプレゼンテーションモデルが厳密に分離されているため、レイアウト設計者は、テンプレートのみにアクセスできる場合、システム全体を「殺す」ことができます。



柔軟性



3）XSLTを使用すると、すでに実行した作業の結果を再利用できます。 XSLTで作成されたレイアウトがビジネスロジックとその開発の機能をサポートしなくなると、自由にスケーラブルになり、他のプロジェクトに転送されます。



4）通常の操作では、テンプレートを1回だけ作成し、プロジェクト間で使用するだけで十分です。 実践の例：パートナースタジオが、さまざまな自動車ブランドの自動車販売店の3つのサイトを開発する注文を受けました。 最初のサイトを作成するのに約2か月かかり、新しい改善を考慮して2番目のサイトは1か月で開発され、3番目のサイトは2週間で作成されました。 テクノロジー自体がすでに作成されているという事実により、サイトは「装飾」（つまり、デザインを変更）することしかできません。 問題が解決したら、次に新しい機能を導入しても、2〜3倍の時間がかかりません。

可用性、わかりやすさ、低開発コスト



5）HTMLとCSSにのみ精通しているタイプセッターである私たちの経験によれば、XSLTプロジェクトのゼロからの開発時間は平均して約1か月半です。 さらに、XSLTを他のプロジェクトタスクとは別に研究する場合、1週間半で習得できます。 比較のために、同じレイアウトデザイナーは特定のCMSのtpl-templateエンジンを週平均で習得でき、プロジェクトの作業中に習得すると同じ月がかかります。 ただし、XSLTレイアウトデザイナーは1回だけ学習する必要があり、個々のtpl-templateエンジンは個別のスタディを取得します。 したがって、XSLTで最初のプロジェクトを開発した後、実装段階での節約について話すことができます。



疎外



6）XSLTレイアウト設計者は、他の誰かのXSLTテンプレートを再設計できます。 このテクノロジーは標準であり、開発者間の移行は問題ではありません。これにより、プロジェクトの疎外性とプロジェクトの所有コストの大幅な節約が保証されます。



拡張性



7）XSLTテンプレートの編集には、Smarty上にある場合にテンプレートで使用できるビジネスロジックおよび関係構造の分析への干渉は含まれません。 したがって、たとえば、ビジネスロジックを変更しても、他のテンプレートが崩壊することはありません。 すべての通信は構造化され、変更可能であるため、これにより、一貫した拡張の可能性がすでに確立されています。 このアプローチによる拡張性は、労働集約性を大幅に軽減し、再びプロジェクトの所有コストが削減されます。



顧客の現在の要件を考えると、さらなる開発と拡張を必要としないプロジェクトを想像することは非常に困難です。 XSLTは現在、プロジェクトの開発を予見し、将来の機会を提供できる最高の標準です。



8）XML + XSLTで解決されたいくつかのタスクは、XSLTがなければ少なくとも簡単ではなく効率的であるように見えます。



たとえば、XSLTを使用すると、分散サービス（特に、Web 2.0マッシュアップのコンテキストで一般的）を構築したり、それを使用してクラスターシステムを構築したりできます（もちろん、これはCMSには適用されません）。 XML形式に基づく他のリソースとのコンテンツの交換により、自分のサイトで他の人のサービスを使用できます。 さらに、このサードパーティのサービスが「ダウン」した場合、サイトには何も起こりません。データはしばらくの間キャッシュから取得され、サイトの残りのヘルス全体でこのサービスが表示されなくなる可能性があります。 上記のSmartyアプローチは、開発された非構造化接続のおかげで、サードパーティサービスと共にサイト全体もダウンするという事実に大きく貢献する可能性があります。



ネイティブXMLサポート



9）プロジェクトで頻繁に使用する必要がある豊富なXMLデータは、私たちの現実です。 XSLTテンプレートエンジンはネイティブXMLパーサーであり、他のすべてのソリューションは自転車です。



パフォーマンスと速度



10）一部の開発者がXSLTを非難する「欠点」の1つは、ビジネスロジックの問題を解決できないことです。 もっと馬鹿げた声明を想像するのは難しい。 この意味で、XSLTにデータベースをオーバーレイして高速動作を要求することは、通常のテレビのスピーカーで5.1互換ディスクを再生してドルビーサラウンドを要求するのと同じくらいばかげています。 定義により、XSLTはこれを行うべきではなく、プレゼンテーションを実装するためだけに作成されました。 ただし、ビジネスロジックは、ページを表示するために必要なデータを準備する必要があります。 そして彼女がそれらを準備すれば、ページに表示されるもの（ほとんどの場合、10-50製品）を送信するだけでよいため、XSLTの速度について質問することはできません。 万個の製品をXMLに完全にデータベース変換してからXSLT変換を適用すると、パフォーマンス結果は非常に悲しくなります。 同時に、XSLTのベースであるビジネスロジックとプレゼンテーションを分離するという概念は完全に強姦されます。 セルゲイ・リジコフが説明したアプローチで、生産性とスピードの驚異を見せないことは驚くことではありません。

XSLTの欠点について。

残念ながら、理想的な人/製品/技術はありません。 XSLTも例外ではありません。



XSLTでテンプレートをデバッグすると、テンプレートに間違いがあった場合、開発者がそれを見つけて削除するために多大な努力が必要になる場合があります。 さらに、閉じられていないタグでさえ、テンプレート全体の動作不能につながります。 したがって、XSLTでは、開発者が特定の注意、正確性、および細部への注意を払う必要があります。



ロシアでのXSLTの大量使用に関する別の制限は、HTMLタイプセッターと比較して、XSLTタイプセッターの賃金が大幅に高いと多くの人が言っています。 これは部分的には事実ですが、多くの点で状況は人為的に強制されています。 かつて、ディーバのレイアウトは、XSLTが多くの人に思われるほどエキゾチックでした。 しかし、これは、テーブルレイアウトに対する実際の利点のために、彼女が広まるのを止めませんでした。 そして、素晴らしいレイアウトのスペシャリストの不足はすぐに市場を埋めました。 したがって、XSLTコーダーの登場は時間の問題であり、XSLTが他の既存のテンプレートエンジンよりも明らかに優れている点です。

結論

初心者の開発者にとっては、多くの場合、tplテンプレートを扱う方が簡単です。 しかし、プロジェクトの開発の特定の段階で、XSLTの使用は技術的および経済的な観点から正当化されます。 したがって、開発者にtplとXSLTの間の選択肢を提供する必要があります。 しかし、開発者自身は、進歩が避けられず、XSLTの大量配布が時間の問題であることを理解する必要があります。 全世界がこの道を進んでおり、無視すべきではありません。 したがって、開発者がXSLTを使い始めるのが早ければ早いほど、将来多くのお金を稼ぐことができます。