1

Doctrine2 で Symfony2 を使用しています。私は次のことを達成したい：

 $place = $this->getDoctrine()->getRepository('TETestBundle:Place')->find($id);

そして、その場所には、（セッション中の）ユーザー言語に関する場所の情報（共通データ + テキスト）が表示されます。これを何百回も行うので、2 番目のパラメーターとしてではなく、舞台裏で渡したいと思います。したがって、英語のユーザーは場所の情報を英語で表示し、スペインのユーザーはスペイン語で表示します。

1 つの可能性は、EntityRepository からアプリのロケールにアクセスすることです。サービスとDIで完了していることは知っていますが、理解できません!

// PlaceRepository
class PlaceRepository extends EntityRepository
{
    public function find($id)
    {
        // get locale somehow
        $locale = $this->get('session')->getLocale();

        // do a query with the locale in session
        return $this->_em->createQuery(...);
    }
}

どのようにしますか？作成および拡張する必要がある手順と新しいクラスについて少し詳しく説明していただけますか? 準備ができたら、この翻訳バンドルをリリースする予定です:)

ありがとう！

4

1 に答える 1

1

Doctrine がセッション データにアクセスするための良いアプローチだとは思いません。ORM には、セッション データをプルするだけのオーバーヘッドが多すぎます。

PDO ベースのセッションの構成については、 Symfony 2 クックブックを確認してください。

サービスをセットアップするのではなく、Doctrine イベント リスナーを使用するアプローチを検討します。各ルックアップの直前に、リスナーはどこか (セッション、構成、または将来的に好きな場所) から正しいロケールを選択し、それをクエリに挿入します。魔法のように、モデルはそれらを知る必要はありません。詳細。モデルのスコープをクリーンに保ちます。

モデルまたはリポジトリがセッションに直接クロスオーバーすることは望ましくありません。将来、そのリポジトリでコマンドライン ツールが必要になったらどうしますか? そこにセッションのクラフトがすべてあると、めちゃくちゃになります。

Doctrine イベントリスナーは魔法のようにおいしいです。それらはいくつかの実験を行いますが、最終的には、この種のクエリ操作に対する非常に構成可能な、独創的なソリューションになります。

更新:最も恩恵を受けるのはDoctrine Translatable Extensionのようです。リスナーの登録、適切なロケールを (保持している場所から) 渡すためのフックの提供など、すべての作業が行われています。私は Gedmo 拡張機能を自分で使用しましたが (この特定のものではありません)、それらはすべて高品質であることがわかりました。

于 2012-11-09T07:02:04.563 に答える