<?= $var ?>は、しばらく非推奨になっています。<?php echo $var ?>(例: symphony、Yii、Kohana ){$var}{$var}何も表示されずに表示される (理由<..>)<>一部のキーボード レイアウトで同じキーを使用している場合はタイピングが少なくなります)これらすべての点で、すべてのフレームワークが非常に長い PHP 構文を使用しているように見えるのはなぜでしょうか? Smartyのようなテンプレート エンジンを使用しないことの利点はありますか (わずかなオーバーヘッドを除く)?
PHP に関する問題は、それがすでにテンプレート言語であるということです。
Smarty は、優れているだけでなく、オーバーヘッドが追加されています。それを使用する正当な理由がない場合、なぜ使用するのでしょうか? バックエンド フレームワークを使用する人は、既に PHP に精通している開発者であるため、その上で学習するために新しい構文を備えたテンプレート エンジンを使用させる理由はありません。
ほとんどのフレームワークは十分に柔軟であるため、テンプレート エンジンを追加する作業はあまり必要ありません。Smarty を使用せざるを得ないフレームワークが構築された場合、フレームワーク自体の柔軟性が低下するため、あまり人気がなくなります。
「長い構文」に関しては、セキュリティ上の問題がある非推奨の構文に頭を悩ませるフレームワークはありません。フレームワークを使用するかどうかは、フレームワークのユーザーに任せることができますが (最近はそうすべきではありません)、短いタグを中心にコア フレームワークを構築すると、移植性が低下します。
<?php print $foo; ?>「超長い構文」と呼ぶかどうかはわかりません。
実際には、標準のデフォルトは通常有効ですが、短いタグはサーバー上で常に有効になっているわけではありません。その道を行く方が安全です。
Smarty のようなテンプレート エンジンは、不要な処理レイヤーを追加します。それらはほとんどブロートウェアです。それらは通常、シンタックス シュガーに相当する追加処理を追加しすぎます。完全な PHP タグが利用可能な場合にテンプレート エンジンを使用することは、束縛を身に着けているようなものです。通常の PHP で同じことを達成するためには、独自のクセのある別の言語になります。
私の経験では、非プログラマーがテンプレート エンジンを完全に、または簡単に利用しているのを見たことはほとんどありません。次の 2 つの例を見てください。
スマート:
<select>
{foreach from=$k item=v}
<option value="{$v.value|escape:'html'}">{$v.label|escape:'html'}</option>
{/foreach}
</select>
PHP:
<select>
<?php foreach ($k as $v) { ?>
<option value="<?php echo htmlentities($v['value']); ?>"><?php echo htmlentities($v['label']); ?></option>
<?php } ?>
</select>
さて、Smarty の構文は少しすっきりしているかもしれませんが、正直なところ、プログラマー以外の誰でも、どちらのコード セットでも快適に作業できるでしょうか? テンプレート エンジンは、大きな利点を提供することなく、処理/ロジックのレイヤーを追加します。
テンプレート エンジンについて、Symfony フレームワークの Fabien Potencier 氏は次のように述べています。
PHP がテンプレート エンジンだといまだに考えられているのはなぜですか? 案の定、PHP はテンプレート言語として誕生しましたが、近年のようには進化しませんでした。PHP がまだテンプレート言語であると思われる場合は、PHP をテンプレート言語として強化した PHP 言語の最近の変更点を 1 つだけ教えていただけますか? 一つも思いつきません。
彼はまた、テンプレート言語に求めている機能についても説明しています。
- 簡潔
- テンプレート指向の構文
- 再利用性
- 安全
- サンドボックスモード
彼のお気に入りのテンプレート言語であるTwigを際立たせるいくつかの機能:
- ネイティブ テンプレートの継承 (テンプレートはクラスとしてコンパイルされます)。
- 確実な自動自動エスケープ (すべてがコンパイル中に行われるため、関連する実行時のオーバーヘッドはありません)。
- 非常に安全なサンドボックス モード (テンプレートで使用できるタグ、フィルター、およびメソッドをホワイト リストに登録します)。
- 優れた拡張性: 独自のタグとフィルターを拡張機能としてバンドルすることで、コア機能も含めてすべてをオーバーライドします。ただし、コンパイル前に AST (Abstract Syntax Tree) を操作することもできます。この可能性を活用することで、アプリケーションを対象とした独自の DSL (ドメイン固有言語) を作成することもできます。
記事のコメントで彼は、「おそらく Symfony 2 の一部になるでしょう。しかし、まずコミュニティからのフィードバックが必要です。」
記事全体を読んで、テンプレート システムを支持する彼の主張全体を理解してください。
いくつかの理由があります:
もっと：
サポートされていないサーバーにコードを移動する必要がある場合 (および有効にできない場合) は、PITA であるため、お勧めしません。あなたが言うように、多くの共有ホストはショートタグをサポートしていますが、「たくさん」がすべてではありません. スクリプトを共有する場合は、完全な構文を使用することをお勧めします。
私はそれに賛成だ
私は読みやすさを理由としてまったく買わない。ほとんどの本格的な開発者は、構文を強調表示するオプションを利用できます。
もっと
短い開始タグは非推奨ではなく、PHP6 でも削除されません。
リンクされた記事には、トピックに関する多くの有用な情報も含まれています。
Rasmus Lerdorf の引用(3 番目のリンク):
私が見た議論のほとんどは、基本的に
<?悪であり、存在すらすべきではないと言っていますが、それは現在の問題ではありません. それは存在し、私たちはそれを削除していません。したがって、ここでの唯一の本当の引数は、これらのタグをオンザフライで有効または無効にできるコードによって導入された WTF 要因です。それは私が見た唯一の有効な議論です。PHP コードが xmllint で検証できるかどうか、および<?有効な xml であるかどうか (明らかにそうではない) は、まったく問題外です。<?を使用する場合、XML に準拠していないことは誰もが知っています。そして、大多数の場合、それで問題ありません。[…]私の見解では、人々はテンプレートを望んでいます。私はこの概念が嫌いで、常にそのことを強く主張してきましたが、人々はよりシンプルなテンプレート タグを求めています。ファイルを解析し、リクエストごとに PHP コードを生成して
{blah}、<?php blah() ?>. 人々がシンタックス シュガーのために桁違いのパフォーマンス ヒットを受け入れるという事実は、私には不可解ですが、そこにあるすべてのテンプレート システムを見てください。もちろん、信頼できないテンプレート作成者のために機能セットを制限するなど、テンプレートを使用する理由は他にもあることは承知しています。これらの人々に切り替えること<?blah()?>は、私の本のパフォーマンスと正気の勝利です. はい、完全な勝利ではありませんが、それでも勝利です。
個人的には、テンプレート システムを避けるようにしています。なぜなら、通常の PHP 構文は、すぐに使える PHP の機能を再発明するテンプレート言語として使用する方がはるかに簡単だからです。ViewHelpers の追加により、どのデザイナーも通常の構文を使用するのにそれほど苦労する必要はありません。実際、私は常に、Web デザイナーにとって( Smartyのような) テンプレート エンジンの方が簡単であるという議論をかなり軽視しているのを見つけました。冗長な PHP 構文は美的には魅力的ではないかもしれませんが、半脳なら誰でも習得できます。
テンプレートを数文字短くするために Smarty ほど巨大なライブラリを含めたくないからです。
他の回答に加えて、Smarty (および同様のテンプレート エンジン) を問題にするものがいくつかあります。
1 つ目は、テンプレートに JavaScript を配置する場合、テンプレート内の一部の文字をエスケープする必要があることです。JavaScript が PHP によって動的に作成された場合、状況はさらに悪化します。そのコードの可読性は大幅に低下します。
2 つ目の最も重要な点は、まともな OO フレームワークで作業している場合、Smarty はコードの機能を大幅に低下させるということです。PHP をテンプレート エンジンとして使用する場合、テンプレート内で $this を使用して、テンプレートを解析するコントローラーのメソッドを呼び出すことができます。それだけでなく、コントローラーが継承したすべてのメソッドにアクセスできます。smarty を使用すると、 $this がコントローラーを参照しなくなるため、この機能全体が失われます。基本的に、テンプレートからフレームワーク全体にアクセスする代わりに、Smarty の限られた機能にしかアクセスできません。