2

テンプレート エンジンのベンチマークプログラムを作成しています。最初に、プログラムは、レンダリングされた結果を (文字列として) 返すことによってテンプレート エンジンをテストするように設計されています。ただし、一部のテンプレート作成者は、テンプレート エンジンが結果として文字列を返すべきではなく、出力ストリームまたはライター インスタンスをパラメーターとして受け入れ、レンダリング結果をそれらにマージする必要があるという懸念を提起しています。彼らは、case がテンプレート エンジンが使用されている実際の環境を表していると主張しています。

ASAIK、この発言は 100% 正しくありません。Play!Framework (少なくとも 1.x) では、テンプレート エンジンが文字列を返し、それらを出力ストリームに入れる必要があります。そして、このように整理することは合理的だと思います。論理エラーが原因でテンプレート レンダリング プロセスが失敗した場合、テンプレート エンジンが応答に直接出力した場合、エラーが回復不能になることを考えてみてください。Play にいる間、ブラウザーに半分混乱したデータを実行させるのではなく、エレガントなシステム エラー ページに応答を送信する良い機会があります。

一方、出力に直接レンダリングすると、パフォーマンスとリソース消費に明らかな利点があります。テンプレート エンジン デザイナーにとってどちらがより良い方法なのか、興味があります。

4

2 に答える 2

1

に書き込みWriterます。これが最小公分母だからです。PrintWriterアルゴリズムは便宜上それをラップすることを好むかもしれません、そしてこれはあなたがFileWriter、、、OutputStreamWriterまたはを受け入れることを自由にしますStringWriter。

文字列への書き込みは悪い考えのように思われます。実際の使用法では、後処理のために文字列全体を保持する必要はほとんどなく、代わりに小さな論理部分でドキュメントを書き込んだり送信したりできるため、メモリを消費します。パターンはより現実的になります。

Writerを受け入れる場合は、StringWriterを使用して文字列を取得できることを忘れないでください。文字列を使用する場合、ライター（およびストリーミングAPI）で十分であっても、そのメモリを永久に割り当てる必要があります。

于 2013-01-25T09:02:36.880 に答える
1

私の意見では、文字列を返すとあらゆる種類のパフォーマンスの問題が発生する可能性があるため (応答をできるだけ早く返す必要がある場合の出力遅延から、誰かが巨大なテンプレートを作成する場合のメモリの問題まで)、ストリーム アプローチを使用する必要があります。

また、回復不能なエラーポイントについても同意しません。たとえば、テンプレート エンジンに構成オプションを追加して、進行中のテンプレートを「バッファリング」することができます (バッファリングされた出力ストリームをファイル/メモリに使用し、完了するまで「実際の」出力ストリームには何も書き込まないことによって)。このモードでは、まったく同じエラー ロジックを実装できます。もちろん、このモードはデフォルトでオフにする必要があります-パフォーマンスのために。

于 2013-01-25T09:03:16.033 に答える