Smartyは2番目のバージョンでしたが、コメントでは、3番目のバージョンには違いがあり、しばしば重要であることが事実です。
まず第一に、私はTwigをSmarty構文に微調整しようとしました。 完全ではありませんが、これを行うことができます。 このように：
$loader = new Twig_Loader_Filesystem('/templates'); $twig = new Twig_Environment($loader,array('charset'=>' utf -8','cache'=>'/templ_c','auto_reload'=>true)); $escaper = new Twig_Extension_Escaper(true); $twig->addExtension($escaper); $lexer = new Twig_Lexer($twig, array( 'tag_comment' => array('{*', '*}'), 'tag_block' => array('{', '}'), 'tag_variable' => array('{$', '}'), )); $twig->setLexer($lexer);
初期化時に、配列でtag_comment、tag_block、およびtag_valiableを宣言します。 Smartyで変数を表示できるようになりました。 移行は十分に便利ですが、今ではこれを行わない方が良いと理解しています。 構文は異種になります。
それでも、何かを混乱させないために、私はしばらくの間、いくつかのことに慣れ、ドキュメントをのぞかなければなりませんでした。 たとえば、配列の横断
{for category in category_tree} {$category.name} {endfor}
代わりに
{foreach from=$category_tree item=category} {$category.name} {/foreach}
Twigでは、変数のタグの再定義にもかかわらず、変数名の前にドル記号が表示されないことに注意してください。 Smartyからの移行でない場合は、より便利です。
ブロックは{/ if}ではなく{endif}で閉じられます。 最初は混乱しています。
または、たとえば、テンプレートエンジンで処理する必要のないブロック。
{literal} {/ literal}の代わりに{raw} {endraw}。
これらはすべて、移行に伴うマイナーな調整と適応です。 ほとんどの場合、これは構文が似ているという事実によってさらに複雑になります。
Smartyでの作業に慣れていますか？
最初はパターン構造です。 パターンは帽子、本体、地下室に押しつぶされました。 また、サイドブロックや他のブロックも際立っていました。 さらに、この全体がシーケンスのメインテンプレートに接続されました。 今、私はこれがまったくクールではないことを理解しています。 継承は素晴らしいです！ 多くの場合、サイトページは同じ原則に基づいて構築されていますが、組織にはいくつかの種類のページがあります。 多くの場合、見出し/地下はどこでも同じですが、左/右メニューが左または右にジャンプするか、ページの一部にまったく表示されない場合があります。 Smartyでは、条件を作成して目的のテンプレートを接続し、その中の別のテンプレートを接続します。 小枝は違います。 ここでは、OOPと同様に、テンプレートは相互に継承され、テンプレートの一部を再定義できます。 これは素晴らしいです。 動きは実際には他の方向です-メインテンプレートから娘テンプレートへではなく、最終テンプレートを表示することにより、親の親からルートへと続きます。
メインテンプレートをヘッダー/地下室で構築し、サイドブロックを作成することもできます。その後、それから下位レベルの他のテンプレートを継承します。 彼らは簡単にサイドブロックを再定義します。 たとえば、メインテンプレートから左メニューのテンプレートと右メニューのテンプレートを継承できます。 より高いもの、誰から継承されたものは、より高い者のビジネスです。 そして、必要な作業に応じて、右メニューのテンプレートまたは左メニューのテンプレートのいずれかから最終テンプレートを継承します。 そして、心を変えて、左側のメニューテンプレートからではなく、右側のメニューテンプレートからテンプレートを継承できます。 このようなシンプルさ、透明性、柔軟性は私をとても幸せにします。 劇的な変更でも簡単です。 コードのビット。
メインの親テンプレート。
main.tpl
<!doctype html> <head> <title>{block html_title} {endblock}</title> </head> <html> <div class=”header”> </div> <div class=”body”> {block content} . {* , .*} {endblock} </div> <div class=”footer”></div> </html>
次に、メニューなしでページを作成します。
left_menu.tpl
{extends "main.tpl "} {block html_title} {endblock} {* *} {block content} . . {endblock}
そして今、メニューテンプレートは左側にあります。
left_menu.tpl
{extends "main.tpl "} {block content} <div class=”left_menu”> {* - *} {for category in category_tree} <a href=”?{$category.id}”>{$category.name}</a> {endfor} </div> <div class=”content”> {block page_content} {* , content, . *} . {endblock} </div> {endblock}
そして終了ページ
{extends "left_menu.tpl "} {block html_title} {endblock} {endblock} {block page_content} . , , . {endblock}
その結果、最終的なテンプレートは、接続、条件、その他すべてで混雑しません。 テンプレートの継承元を言うだけで、本質的にのみです。
Smartyを使用するとき、すべての変数をテンプレートに転送してそこに出力する必要があり、すべての処理はコードに含まれていたという事実に慣れています。 多くの場合、テンプレートエンジンの前に書式設定さえ行わなければならず、その結果、ミッシュマッシュが発生しました。 Twigでは、通常、ジェスチャーなしでテンプレートから実行ロジックを制御できます。 出力がフィールドの名前ではなく、メソッドの名前である場合、この場所にメソッドによって返される値が表示されます。 つまり ある種のカウント値を表示する必要がある場合、事前にカウントする必要はありません。これは出力で直接行われます。
// class User { public function free_space() { // - , . Return $result; } } : {$user.free_space}
そしてそれだけです。 事前に考える必要はありません。すべてがうまくいき、すぐに解決します。 不快な瞬間は、クラスフィールドがプライベートの場合、getterがクラスに記述されていても、twigはそれを出力しません。
3番目は、独自の拡張機能を記述することです。 多くの場合、テンプレートエンジンに実装されていない機能が必要です。 小枝の拡張は非常に簡単です。 たとえば、出力を印刷する必要があります。 選択的に。
class My_Twig_Extension extends Twig_Extension { // . public function getFilters() { return array( 'typograph => new Twig_Filter_Method($this, 'typograph') ); } public function typograph($text) { return $typograph->parse($text); // . } }
そして、初期化段階で接続します。
$twig->addExtension(new My_Twig_Extension());
これで、処理する必要のある変数のテンプレートは、修飾子{$ page.content | typograph}を追加するだけで、それで値が処理されます。 テンプレートエンジンに値を渡して処理する前に、まずすべての値を並べ替える必要はありません。 テンプレートエンジンは引き続きアレイをバイパスして終了します。これは2回ではなく1回行われます。 拡張機能を作成してから、必要な機能を追加することができます。
Twigの後、私は本当にSmartyに目を向けたくありません。 それはあまりにも簡単で論理的であるため、すべてが彼と一緒になります。