ほとんどのテンプレート エンジンは、デザイナーやフロント エンド開発者にとって使いにくく、プログラマーはそれらを維持する負担を負うことになると思います。
また、デザイナーが html モックアップを更新した後にテンプレートを頻繁に更新することは悪夢です。テンプレートが元の html と互換性がなくなるためです。
私は非常に長い間この問題を抱えていましたが、最近アイデアがありましたが、何かを再発明していないのか、それとももっと良いものが存在するのかわかりません。
それで、この問題のより良い解決策を見つけたかどうか、また見つけた場合はどれを見つけましたか?
コンテンツをプレゼンテーションから完全に分離するように切り替えたので、振り返ることはありませんでした。その理由は次のとおりです。
ビジネスロジックが非常に明確になります。HTMLタグとプレゼンテーションロジックが混在していない場合、コードのスペースは1/2になり、保守にかかる時間は1/2未満になります。コードとプレゼンテーションの間のリンクを維持する負担は、テキストファイルまたはWikiノートとしても、プレゼンテーション層に提示/必要なすべての変数と値をリストする、2つの間の正式なインターフェイスを指定することで軽減できます。
デザイナーの変更からテンプレートを頻繁に更新するということは、プレゼンテーション層をメニューブロック、ページレイアウトブロック、コンテンツブロックなどのさまざまな「ブロック」に細分化する必要があることを意味します。ほとんどのページでは、コンテンツブロックのみが異なります。CSSやその他の最新のWeb技術を使用して適切に分割および実装すると、デザインを適切に変更しても、プレゼンテーションコードへの影響は最小限に抑えられます。
CMSはこのプロセスをさらに自動化し、一貫性とサポートの容易さの両方の観点から、5〜10ページのサイトでさえCMSと手書きのHTMLを使用することでメリットを得ることができるようになりました。
コードのセキュリティ-SmartyはPHPではないため、設計者はサイトに対する信頼度を低くすることができます（DoSと同じ効果でプレゼンテーションを混乱させることはできますが、基盤をあまり混乱させることはできません。とにかくそれらを台無しにしないでください）; セキュリティをそれほど気にしない場合、PHPTalなどはほぼ「ネイティブ」の速度で実行されます。
私の実用的なソリューションに関しては、2つの推奨事項があります。
プロジェクト全体のフォルダー構造と命名規則を作成し、それに固執します。あなたのビジネスロジックファイルの名前が与えられれば、私はあなたにプレゼンテーションファイルが何であるかをあなたに言うことができるはずです、そしてその逆も同様です。
ビジネスロジックとプレゼンテーションの間に明示的なインターフェイス仕様（ここでも、テキストファイルまたはWikiエントリだけが本当に必要です）を用意します。どの変数が利用可能で、どのように（プログラマー）/（デザイナー）フォーマットされるべきかを知ることで、1年後にページを維持しなければならないときに両方が非常に満足します。
はい。ただし、可能な限りネイティブ HTML に近い場合に限ります。
Dreamweaver のテンプレート (エディターを無視) は、基本的に HTML コメントでプレーンな古い HTML (POH™) ページをマークアップするため、基本的にこれをうまく実現します。