はじめに
皆さんはおそらく日常生活でさまざまなテンプレートエンジンを既に聞いているか使用しているでしょう。それらはテンプレートエンジンでもあります。 通常、これらを使用してHTMLコードを生成します。 このプロセスでは、通常、何らかのデータモデルと、このデータを入力するHTMLテンプレートがあります。
以前は、サーバー側でのみHTMLページを生成していましたが、今日ではクライアントで次第にこれを行っています。 需要が提案を生み出し、JavaScriptで動作するテンプレートエンジンがますます多く見られるようになりました。同時に 、サーバー言語を含む多くの言語で実装されたテンプレートエンジンがあります。これについては、この記事で説明します。 このようなテンプレートエンジンの1つの例は口ひげです （実装のリストに注意してください）。この記事の例で使用します。 つまり 記事の口ひげという言葉を「JavaScriptとサーバー言語を備えたテンプレートエンジン」というフレーズに置き換えることができます。
明らかなユースケース
このようなテンプレートエンジンを使用する明らかな例は、もちろん、1つのテンプレートを使用してサーバーとクライアントでHTMLコードを生成する機能です（確かに、多くの人がJavaScriptでHTMLブロックコードを複製する必要があり、多くの人が今でもこれを続けています）。 これに対するニーズは絶えず生じています。人生の例はツイッターです。 twitterを開くと、サーバーは最初のいくつかのツイートをレンダリングし、javascriptを使用して下にスクロールすると、次の部分をロードし、同じテンプレートを使用してクライアントにレンダリングします。 この場合、口ひげは、その純粋な形またはicanhazjsとの組み合わせで完璧です。 ところで、何らかの形のこのアプローチは、ハブとここですでに言及されています 。
あまり明らかではないユースケース
また、あまり詳しくないユースケースもありますので、詳しく説明します。 サイトの実装への古典的なアプローチは、設計、レイアウトの作成、およびレイアウトにデータを入力するサーバーコードの作成であり、口ひげの場所もあります。
レイアウトデザイナーがレイアウトを提供するとき、通常、純粋な形式で使用することはできません。 サーバーコードを入力する必要があります。最終的には、HTML + <サーバープログラミング言語>で満足のいく混乱が生じます。 このアプローチの欠点は、サーバーコードでレイアウトを埋めた瞬間から、特に異なる人がレイアウトとサーバー側を作成する場合、保守が難しくなることです。 レイアウトが送信された更新済みのレイアウトでHTMLファイルを上書きすることはできません。レイアウトによって行われた変更を非常に慎重に制御する必要があります。
実際、組版をサーバーに移動するときに発生する問題は、変更のマージだけではありません。統合が不便だった時代から、それぞれの例を見つけることができると思います。
タイプセッターは、少し違って見える繰り返しブロックを作成する必要があるときや、これらのブロックを使用してレイアウトの一部をコピーアンドペーストする必要があるとき、およびレイアウトを変更するときにすべての場所ですぐに変更するとき、甘い時間を過ごすことがあります。
サーバープログラマーは、レイアウトデザイナーが信念の一部のコンポーネントの状態にスタイルを提供しなかった、またはデータが変更されたときにブロックがレイアウトにハードコーディングされ、ストレッチされないことが突然判明したときに多くの悪い言葉を思い出します。
最後に、レイアウトのテストも非常に不便であり、サーバーパーツが作成されるまでほとんど不可能です。 これに関して、アプリケーションのサーバー側を記述した後、回避できた浅瀬の束が出てきます。そして、レイアウト設計者を蹴ってレイアウトを修正し、サーバープログラマーが変更を加えます。
サーバーとクライアントの両方に1つのテンプレートエンジンがあるため、口ひげのようなテンプレートエンジンの助けを借りて、これらすべてのマイナス面を回避しようとすることができます。 これを行うのは難しくありません。レイアウト設計者は、データをハードコードする代わりにレイアウトで口ひげ構文を使用してから、データをテンプレートに入力できるJavaScriptコードを数行書く必要があります。 わかりやすくするために、小さな例を示します。
<html> <head> <script type="text/javascript" src="mustache.js"></script> <script type="text/javascript" src="jquery.js"></script> <script> var data = { "newsCategory": "IT", "news": [ { "id": 1, "title": "Write once, render anywhere", "preview": "bla bla bla", "date": "01.01.2012" }, { "id": 2, "title": "Mustache in action", "preview": "bla bla bla", "date": "02.02.2012" } ] } $(function(){ $("body").html(Mustache.render($("body").html(), data)); }); </script> </head> <body> <h1>{{newsCategory}}</h1> <ul class="news"> {{#news}} <li> <h2>{{title}}</h2> <p>{{preview}}</p> <a class="readMore" href="/news/{{id}}">...</a> <div>{{date}}</div> </li> {{/news}} </ul> </body> </html>
サーバー側を実装するときに同じテンプレートを使用できることは簡単に推測できます。不要なjavascriptを除外し、サーバー言語（Ruby、Java、PHP、Python、Scalaなど）の口ひげ実装を使用するだけで十分です。完全なリストはこちらです。
このようなテンプレートをテストするのは非常に便利です（繰り返しブロックをコピーして貼り付けて表示するためのさまざまなオプションをテストする必要はありません。データモデルを変更するだけです）。レイアウトデザイナーは、従来のアプローチよりも優れたレイアウトを確実に提供します。実際のデータ。 このようなテンプレートは、サーバー上で既製のまま使用することもでき、レイアウトの更新時に簡単に更新できます。
実際、テンプレートを作成する時点で既製のデータモデルが既にあるという事実は、他の多くの暗黙の利点をもたらします。 インターフェイス設計の段階でも多くの欠点を回避できます。
結論
もちろん、口ひげのようなテンプレートエンジンの出現は、現代の動的サイトの作成を大幅に簡素化し、それらを作成するプロセスをより識字的で便利なものにするはずです。 そして、たとえ1日で誰もがjavascriptで単一ページのクライアントを書き始めたとしても、サーバー上の検索エンジンのページを生成するために口ひげを使用できます。
記事では、このアプローチを使用してサーバーとクライアント上でパーツ（部分、インクルード-必要に応じて）からページを構築する方法については説明しませんでした。多くのニュアンスがあります。