1

これをできるだけ明確に説明しようと思います。私はかなり大きなプロジェクトに取り組んでおり、CrudController を作成しました。このコントローラーには、いくつかのデフォルト アクション ( indexAction、createAction、archiveAction...) があります。対応するビューもいくつか作成しました。

  • ビューはedit.html.twigform_widget() 関数でフォームを描画します
  • list.html.twigビューは、データ配列と (構成可能な) 列配列を取得します。これにより、必要な列といくつかのアクション ボタン (デフォルトでは編集およびアーカイブ ボタン)を含む単純なテーブルが描画されます。

アイデアは、アプリケーションを迅速に開発できるようになったことです。新しいエンティティ、リポジトリ、フォームタイプを作成し、最後に BaseController の代わりに CrudController を拡張するコントローラーを作成します。EntityController で、CrudController の構成が正しいことを確認します (エンティティ名、FormType へのポインターなど)。これはすべて魅力のように機能します。

ただし、「レンダリング」または「ダウンロード」(レンダリングが完了したとき)という追加のアクション(編集とアーカイブ以外)が必要なエンティティ(プロジェクト)があるところまで来ました。余分なアクションを追加するためだけにこの 1 つのエンティティのリスト ビューを完全に上書きしたくなかったので、このシナリオに再び遭遇するので、リスト ビューからアクションのレンダリングを移動しようとしました。特定のプロジェクトのステータスに基づいて、アクションのみをレンダリングするビューと追加のアクションを追加actions.html.twigするビューを作成しました([レンダリング] ボタンまたは [ダウンロード] ボタンを表示する必要がありますか?)。actionsAction

私list.html.twigは使用しました：

{% for row in data %}
    {{ render(controller(entityControllerActionsAction, {'id': row.id})) }}
    ...
{% endfor %}

ただし、レンダリングはメモリを大量に消費することが判明し、リストにいくつかのエンティティを表示するとすぐに、「メモリが不足しています」というエラーが発生します。以前は 12MB しか使用していなかったページが、突然 128MB (メモリ制限) を超えて使用されました。これはまったく受け入れられません。また、ロード時間が大幅に増加しました

この問題に対する適切なオブジェクト指向のDRYソリューションを探しています。

  • ここで render() 関数がメモリとパフォーマンスを大量に消費する理由はありますか? それを減らすことができれば、問題は解決するでしょう。
  • render() 関数を模倣するか、別のものを使用する方法はありますか。

私はビルド済みのコードなどを探しているのではなく、どちらの方向に進むべきかについてのアドバイスを求めています。お時間をいただきありがとうございます。

4

1 に答える 1

0

このStackoverflow の投稿で述べたように、 「レンダリング」は新しいリクエストを生成し、メモリ使用量を増加させます。代わりに、デフォルトのアクション ブロックを定義するブロック構造を使用してみてください。これをプロジェクト エンティティに上書きします。

于 2013-03-27T10:38:22.427 に答える