テンプレートエンジン。 構造フレーミング
テンプレート構文の標準は、制御構造（ブラケット、パーセンテージ、質問）のフレームとして使用するものであるという印象を受けます 。 これは真実ではありません。 テンプレートのこのレコードまたはそのレコードを囲むシンボルは、データをロジックに関連付けるための単なる方法です。 ここで基準を設定するのは難しいです。 しかし、この設計またはその設計を再現するロジックは事前に合意する必要があります。そうすれば、異なるプログラミング言語でテンプレートを相互に互換性を持たせることができます。
しかし、今日もこれらと同じブラケットについて話します。 変数のシギルを忘れないでください。
テンプレート構築の制限の例はたくさんあります。 角括弧、中括弧、正方形、括弧、および％ 、？などの記号の組み合わせ ...
テンプレートの構造とHTMLタグを明確に区別するには、非山括弧を使用することをお勧めします。 しかし、 HTML :: Templateのような構造には独自の魅力があり、特定のサークルでは高く評価されています。 そのような人々のグループを何らかの形で制限する必要がありますか？ そうは思いません
たとえば、配列のスライスを指定するために、制御構造で角括弧を使用するとよいでしょう。 この場合、 [％...％]と組み合わせて、一部の制御構造（たとえば、配列スライス）は可視性を失います：
句の意味の組み合わせと分離に括弧を使用することに慣れています。 これは最も失敗したオプションの1つになるようです。 さらに、 条件文では確実に複雑な式を作成する必要があり、上記の例と同様の状況が発生します。
注意を払えば、ほとんどのプログラミング言語では、コードブロックはそのような中括弧で強調表示されます。 では、伝統に従って、テンプレートにこのアプローチを採用しないのはなぜですか？ 些細なことのように思えますが、なぜすべての人が長い間そのような結論に至っていないのでしょう。 彼らはやって来ましたが、それぞれ彼のやり方で。 以下の例のように構造を使用することは、まったく普遍的ではないとしましょう
テンプレートの構成を考慮する必要がないときに、テンプレートのテキストに{title}が表示される状況に単純に陥ることがあります。 現在、テンプレートエンジンの実装は、Djangoなど、この問題に対するさまざまなソリューションを提供しています。
しかし、この豊富な括弧とパーセンテージは、特に同じ文字を2回塗りつぶすことが珍しい場合には、熱意を引き起こしません。
議論したり説得したりしないでください。誰かが[％...％]を見ることに慣れているなら、それが悪いと言う必要はありません。 これは、お茶に砂糖を大さじ2杯入れておくと良くありませんが、誰かが良いです。 フレーミング構造に異なるオプションを同時に使用できると仮定します。 主なことは、パーサーで処理した後、テンプレートのアルゴリズムに従うことです。
全体として、変換のためにある種のピボットテーブルが必要であることがわかります。これは、さまざまなデザインで簡単に補完できます。
接頭辞シギルは、すべてのプログラミング言語で使用されるわけではありません。 誰かが彼らに慣れました、誰かのためにそれは野生です。 1つのポイントをマークしましょう。 Perlコードのサンプルは次のとおりです。
道徳：テンプレートで使用したい静的データがあることが多いのですが、毎回テンプレートに送信されるデータを記入するのは無理です。 テンプレートエンジンクラスのインスタンスの受信後（または受信中）に、論理データを1回割り当てるのがはるかに論理的です。 テンプレートでは、たとえば次のようなデータを視覚的に分離すると便利です。
{#name}は反復可能なコメントオブジェクトに属する変数で、変数{$ cfg.domain}は構成から取得されます。 構成変数をsigil $で強調表示し、単純変数をsigil ＃で強調表示しました。 ％ sigilがデータオブジェクト（ハッシュ配列）のsigilとして使用されたことにも注意してください。
同様に、包含呼び出しはサブルーチン呼び出しに関連付けられ、sigil ＆を使用できると想定できます。
多くのプログラミング言語は、 if / else表記、 exprなどの短い表記をサポートしていますか？ true：false 少し改善し、テンプレートで何が起こるかを確認します。
そのような構造はすでに実用性を示しており、実装の例は、前述のperlサーバー部分を備えたJavascriptテンプレートエンジンで見つけることができます。
もちろん、上記の例は万能薬ではありません。 私は、提示された素材のアイデアを伝え、フレーミングキャラクターと、場合によっては展開可能なピボットテーブルによる変数のシギルを選択する柔軟な機会を提供しました。 テンプレートの移植性のために、フレーム文字をあるオプションから別のオプションに変換できるコンバーターを作成する必要もあります。これは、開発者によるこれらの認識を容易にするためだけです。 パーサーはオプションをすべて消化します。
次に、テンプレートデザインを処理する方法を既に検討します。 これらまたはこれらの構造はどのアルゴリズムに変換する必要がありますか？ 標準化する必要があるのは、構造をコードに再現するためのこれらのアルゴリズムです。 そして、すでにそれらの上に、実際のテンプレートエンジンを書くことが可能になります。 しかし、以前は、ここで何が欠けていたのか、何を調整する必要があるのかを知っておくといいでしょうか？
しかし、今日もこれらと同じブラケットについて話します。 変数のシギルを忘れないでください。
テンプレート構築の制限の例はたくさんあります。 角括弧、中括弧、正方形、括弧、および％ 、？などの記号の組み合わせ ...
<...>
テンプレートの構造とHTMLタグを明確に区別するには、非山括弧を使用することをお勧めします。 しかし、 HTML :: Templateのような構造には独自の魅力があり、特定のサークルでは高く評価されています。 そのような人々のグループを何らかの形で制限する必要がありますか？ そうは思いません
[...]
たとえば、配列のスライスを指定するために、制御構造で角括弧を使用するとよいでしょう。 この場合、 [％...％]と組み合わせて、一部の制御構造（たとえば、配列スライス）は可視性を失います：
[% myobj => data.source [3..5] %]
（...）
句の意味の組み合わせと分離に括弧を使用することに慣れています。 これは最も失敗したオプションの1つになるようです。 さらに、 条件文では確実に複雑な式を作成する必要があり、上記の例と同様の状況が発生します。
{...}
注意を払えば、ほとんどのプログラミング言語では、コードブロックはそのような中括弧で強調表示されます。 では、伝統に従って、テンプレートにこのアプローチを採用しないのはなぜですか？ 些細なことのように思えますが、なぜすべての人が長い間そのような結論に至っていないのでしょう。 彼らはやって来ましたが、それぞれ彼のやり方で。 以下の例のように構造を使用することは、まったく普遍的ではないとしましょう
<p>{title}</p> {if expr} <span>true</span> {else} <span>false</span> {endif}
テンプレートの構成を考慮する必要がないときに、テンプレートのテキストに{title}が表示される状況に単純に陥ることがあります。 現在、テンプレートエンジンの実装は、Djangoなど、この問題に対するさまざまなソリューションを提供しています。
{% if expr %} <span>true {{title}}</span> {% else %} <span>false {{theme}}</span> {% endif %}
しかし、この豊富な括弧とパーセンテージは、特に同じ文字を2回塗りつぶすことが珍しい場合には、熱意を引き起こしません。
しかし、フェルトペンはどうですか？
議論したり説得したりしないでください。誰かが[％...％]を見ることに慣れているなら、それが悪いと言う必要はありません。 これは、お茶に砂糖を大さじ2杯入れておくと良くありませんが、誰かが良いです。 フレーミング構造に異なるオプションを同時に使用できると仮定します。 主なことは、パーサーで処理した後、テンプレートのアルゴリズムに従うことです。
全体として、変換のためにある種のピボットテーブルが必要であることがわかります。これは、さまざまなデザインで簡単に補完できます。
変数の印章
接頭辞シギルは、すべてのプログラミング言語で使用されるわけではありません。 誰かが彼らに慣れました、誰かのためにそれは野生です。 1つのポイントをマークしましょう。 Perlコードのサンプルは次のとおりです。
# my %cfg = ( 'host' => "http://host"); # my $tpl = new MyTpl(); # ; my %d1 = ( 'list' => [{},{}], 'cfg' => \%cfg ); # html ... my $html1 = $tpl->get( 'tpl_name1', \%d1 ); # , my %d2 = ( 'comments' => [{},{}], 'cfg' => \%cfg ); # html my $html2 = $tpl->get( 'tpl_name2', \%d2 );
道徳：テンプレートで使用したい静的データがあることが多いのですが、毎回テンプレートに送信されるデータを記入するのは無理です。 テンプレートエンジンクラスのインスタンスの受信後（または受信中）に、論理データを1回割り当てるのがはるかに論理的です。 テンプレートでは、たとえば次のようなデータを視覚的に分離すると便利です。
<ul> {%comments} <li> {#name} {$cfg.domain}</li> {/%comments} </ul>
{#name}は反復可能なコメントオブジェクトに属する変数で、変数{$ cfg.domain}は構成から取得されます。 構成変数をsigil $で強調表示し、単純変数をsigil ＃で強調表示しました。 ％ sigilがデータオブジェクト（ハッシュ配列）のsigilとして使用されたことにも注意してください。
同様に、包含呼び出しはサブルーチン呼び出しに関連付けられ、sigil ＆を使用できると想定できます。
多くのプログラミング言語は、 if / else表記、 exprなどの短い表記をサポートしていますか？ true：false 少し改善し、テンプレートで何が起こるかを確認します。
{? #i > 0} {&listarticles} {|} <span></span> {/?}
そのような構造はすでに実用性を示しており、実装の例は、前述のperlサーバー部分を備えたJavascriptテンプレートエンジンで見つけることができます。
もちろん、上記の例は万能薬ではありません。 私は、提示された素材のアイデアを伝え、フレーミングキャラクターと、場合によっては展開可能なピボットテーブルによる変数のシギルを選択する柔軟な機会を提供しました。 テンプレートの移植性のために、フレーム文字をあるオプションから別のオプションに変換できるコンバーターを作成する必要もあります。これは、開発者によるこれらの認識を容易にするためだけです。 パーサーはオプションをすべて消化します。
次に、テンプレートデザインを処理する方法を既に検討します。 これらまたはこれらの構造はどのアルゴリズムに変換する必要がありますか？ 標準化する必要があるのは、構造をコードに再現するためのこれらのアルゴリズムです。 そして、すでにそれらの上に、実際のテンプレートエンジンを書くことが可能になります。 しかし、以前は、ここで何が欠けていたのか、何を調整する必要があるのかを知っておくといいでしょうか？
All Articles