etpl-wrap_html/css_WEB-ITnose の生成-htmlチュートリアル-php.cn

今週、etpl ノードラッパーを npm に送信し、対応する github アドレス: https://github.com/wslx520/etpl-wrap

なぜ etpl が存在するのか-wrap?

etpl は私が使用した非常に強力なテンプレートエンジンで、必要な機能がすべて備わっています。

etplはnode環境でも使えますが、使い方が想像と違いました。

これは私が koa を学ぶことから始まりました。私が学んだ koa2 には、テンプレートファイルをレンダリングする機能にアクセスするために使用される koa-views ミドルウェアがあります。ただし、当然ながら etpl と併用することはできません。

以前の Express にも同じことが当てはまりました。エンジンが Express と連携したい場合は、追加の設定が必要であり、おそらくソースコードで何らかの特別な作業を行う必要があります。

これは非常に厄介だと思いますが、Web フレームワークはテンプレートエンジンと大きく関係していますか?それらは互いに独立すべきではないでしょうか?

たとえば、koa は koa-views を使用し、テンプレートエンジンに接続されているため、テンプレートをレンダリングするときに

ctx.body = ctx.render('index', data) を使用できます。 )

は次のような構文を使用してレンダリングされます。しかし、完全に独立したテンプレートエンジンがあれば、このように使用できるのではないかと考えました。 :

ctx.body = etpl.render(‘index’,data)

この使用法では、テンプレートエンジンは Web フレームワークとは何の関係もありません。同じ構文を Express でも使用できます:

res.end(etpl.render(‘index’,data))

これはより良い状態ではないでしょうか?テンプレートエンジンを Web フレームワークに挿入する必要があるのはなぜですか?

etpl は Node では異なります

Node もサーバー環境です。テンプレートファイルがある場合、それは通常ファイルです。しかし、etpl にはファイルを直接レンダリングする機能がありません。

etpl を使用して Node でテンプレートファイルをレンダリングする場合、通常のプロセスに従って、最初にファイルの内容を読み取り、それを文字列に変換し、それを etpl.compile に渡す必要があります。次にレンダリングします。

しかし、これはあまりにも愚かで、受け入れることができません。

そこで、node.js で etpl を便利に使用するために、このようなラッパーを書きたいと思います。

パッケージ化の原則

ラッパーには原則があります: 変更できない原文ソースコード。つまり、etpl 自体には何もできません。そうしないと、将来 etpl をアップグレードすることが困難になります。

etplのソースコードをざっと見てみましたが、複雑で時間も限られているので読むのは現実的ではありません（実はよく理解していません）

当初は、レンダリング時に、対応するテンプレートファイルがコンパイルされていない場合は動的に読み取り、コンパイルしてからレンダリングし、コンパイル結果をキャッシュすることを計画していました (コンパイルを繰り返すコストを回避するため)。

しかし、これは少し難しく、etpl ソースコードを変更する必要があるかもしれません。

後で私は自分を慰め、Web サイトのテンプレートファイルの合計は 10M を超えてはいけないと言いました。小規模な場合ですが、アクセスして etpl.compile を呼び出した瞬間からすべてのテンプレートファイルを順番に読み込んでいきました。それらをコンパイルしておけば、今後 etpl.render を使用するときに「コンパイルされているかどうか」を心配する必要はありません。

これにより、サーバーの起動時に追加の消費が確実に発生しますが、許容できるはずです。

target

etpl は、さまざまな「モジュール」のコンパイルを容易にするために target を使用します。たとえば、新しいテンプレートファイルindex.html を作成し、将来 etpl.render('index',data) を実行したい場合、index.html の最初の文は次のようなターゲットステートメントである必要があります。 !– target:index –>

しかし、サーバー側ではそれぞれの異なるファイルが異なるモジュールであるため、これはサーバー側にとって明らかに不合理です。

ラッパーは次のような処理を行います:

テンプレートファイルの最初の文がターゲットステートメントではない場合、現在のテンプレートファイルの名前がターゲット名として使用されます。

また、テンプレートファイルの最初の文でターゲットを宣言する必要がある場合、ターゲット名はテンプレートファイルと一致している必要がありますname

それはまだ当てはまりますターゲットを書かない方が費用対効果が高いです

さらに、ブラウザ側では、ユーザーは同じ名前のターゲット名の問題を回避する必要があります。ただし、サーバー側では、ルートディレクトリまたはサブディレクトリに list.html が存在する可能性があります。理論的には、サブディレクトリ内の 2 つの

テンプレートファイル

2016/ の間に競合はありません。 5 月 5 日の午後、「同じディレクトリ内のすべてのターゲットは同じレベルである」という原則を理解するために。この原則に基づいて、サブディレクトリ内のテンプレートの問題の多くは簡単に解決できると思います。

サブディレクトリに複数のテンプレートファイルがある場合、インデックスがメインのファイルになります。デフォルトのドキュメント。サブディレクトリ: main がある場合、その下のインデックスは自動的に target:main

になります。このとき main/index を参照したい場合は、main を参照するだけです。

、main/content などの他のファイルがターゲットになります: main/content

しかし、実際には、main と main/content は同じレベルにあります (main=main/index であるため)

インデックス、メインなどに設定できる「デフォルトのメインテンプレート」パラメータ を追加することを 検討できます。

サブディレクトリ内のモジュールと親テンプレートは以下を参照します。

サーバー環境のテンプレートには別の問題があります。それは、サブディレクトリ内のテンプレートです。

たとえば、ルートディレクトリのindex.html は次のようにインポートできます: list/list1.html

サブディレクトリ内のテンプレートは、次のように親ディレクトリ内のテンプレートを参照することもあります。 import: ../header

これは、ブラウザ側の etpl では発生しない状況です

幸いなことに、 がターゲット名をパスとして直接取得する場合、 は次のように etpl でも通常に使用できます。

target: header/head-detail

同じファイルの下で複数のターゲットの場合

もちろん、etpl では 1 つのテンプレートファイルで複数のターゲットが許可されているため、この関数を削除することはできません

次に、テンプレートファイル内で、他のターゲットはインポートされていますか? この時点で、

はこのファイルの別のターゲットへの参照ですか?

はこのファイルの同じレベルにある他のテンプレートファイルへの参照です。 ?

参照先が同じレベルまたは親レベルの他のテンプレートファイルに存在する場合、優先順位は何ですか? – このファイルには最も高い

があり、最も単純な原則によれば、優先順位は次のようになります: 同じファイルの下のターゲット==> 同じレベルの下の他のファイルのターゲット

1 つのファイルが参照しますその他のファイルその他のターゲット

たとえば、header.html がありますが、デフォルトでは target:header とみなされますが、その後ろに別のターゲット li があります。この時点では、別のテンプレートファイルリストがあります。 .html も使用したいのですが、これを引用するにはどうすればよいですか?

当初、インポート時に import: header.li を使用してインポートすることを検討していましたが、テストの結果、そのようなターゲット名が原因で etpl がエラーを報告することがわかりました (後でソースコードを確認すると、この問題は次のように修正できます)ソースコードですが、これは私には合いません要件)

この参照が許可されている場合、次のことが発生する可能性があります: import: head/head-left/logo.image 状況

モジュールファイルからのインポートを一時的に無効にする予定です。他のテンプレートファイルからメイン以外のターゲットを導入します。 (ただし、メインではないターゲットに競合しない名前を付ける人もいると思います。また、他のテンプレートファイルはグローバルターゲットとして参照されるでしょう。これは合法であるべきであり、禁止されるべきではありません)

2016/ 5 /5:

今日アイデアを思いつきました。同じファイル内に複数のターゲットがある場合、メインターゲット以外のターゲットはメインターゲットのサブターゲットとして扱われます。例: メインターゲット: main、このファイル内の他のターゲットは main/li、main/p などです。この方法では、それらを参照したい外部ファイルがある場合は、次のように直接インポートできます: main/li

ただし、次の要件があります: すべてのテンプレートファイルのすべてのターゲットが同じレベルのディレクトリに同じ名前 を付けることはできません。しかし、それは可能です。

午後、別の質問が頭に浮かびました:

たとえば、サブディレクトリ main の下にあるメインテンプレートファイルインデックスに他のターゲット: Good が含まれている場合、ターゲット: main/ にコンパイルされます。コンパイル中は良好です

メインディレクトリに別のテンプレートファイル content.html があり、これには他のターゲットもあります。このとき、main/content/other または main/other にコンパイルする必要がありますか?

ターゲットが他のサブテンプレートで宣言されている場合でも、「同じディレクトリ内のすべてのターゲットが同じレベル」であることを確認する必要があるため、一時的に後者であると決定しました。 files

ターゲットを参照する場合の違い

ノードにはディレクトリの概念があるため、ターゲットにもパスがあります。ブラウザのように import:target1、import:target2 になることはありません。 : import:list/li1, import:list/li2, import:../main/list2

ただし、前述したように、ターゲットに出現すると etpl がエラーを報告することになります

ラッパーでは、../ のような相対パスは、 テンプレートのルートディレクトリ から始まる絶対パスに変換されます。たとえば、root/main/list/ul.html テンプレートファイル import:../list2/li は次のように変換されます: import:/main/list2/li