Symfony2でSonataAdminBundleを使用してツリー構造を編集する

ツリー構造の編集は、Web開発ではかなり一般的なタスクです。 これは、ユーザーが自分のサイトに階層を作成する機会を与えるため、ユーザーにとって非常に便利です。 当然、Symfony2に切り替えた後、最初のタスクの1つはページのそのような階層リストを作成し、そのための管理パネルを作成することでした。 そして、 SonataAdminBundleを管理パネルとして使用しているため、タスクはツリーを編集するために設定することでした。



問題は広範で、需要があり、「すぐに使える」既製のソリューションを得ることが期待されていました。 しかし、これは起こりませんでした。 それだけでなく、Sonataの開発者は、誰かが自分のバンドルを介してツリーを「管理」するという考えについて考えたことがなかったようです。



ツリー自体から始めましょう。 まさに「プログラマーとしての子供時代」から、決して車輪を再発明することを教えられませんでした。 そして、時々「蹴って」レトルトしましたが、新しく発明された自転車は横向きではなく、前に乗りやすくなりました。 ページのツリー構造には、Doctrine Extensionsのネストされたツリーを使用することが決定されました。



Doctrine Extensions Treeを使用したツリーモデルの作成は簡単で、マニュアルで説明されています。 Symfony2内でDoctrine拡張機能を便利に使用するためには、 StofDoctrineExtensionsBundleを接続する必要があります。そのインストールと設定については、 マニュアルで 詳しく説明されています 。 さて、突然誰かがこれに問題を抱えたら、私は喜んでコメントを手伝います。



そこで、ShtumiPravBundle：Pageモデルを入手しました。このモデルの完全なコードは不要なので、この記事では説明しません。



今度は、ネストされたツリーの悪い機能について少し話をしたいと思います。そのため、すべてを数回変更する必要がありました。

1. ツリー構造を保存するために、Doctrine Extensionsは親フィールドだけでなく、データベースに保存されているルート、lft、rgt、lvlフィールドも使用します。 フィールドの目的は明確です。フィールドはツリー内の子の順序を決定し、より単純なSQLクエリを作成して、ツリー要素を「正しい」順序で取得できるようにします。 これらのフィールドは自動的に計算され、データベースに保存されます。 ただし、フィールドlftおよびrgtの値を計算するアルゴリズムを理解できませんでした（一生懸命努力しませんでしたが）。 だからここに。 ツリーのいずれかの要素にあるこれらのフィールドの値の1つが不正確になった場合、これはツリー全体の内訳につながります。 上記のフィールドの計算が複雑で、ツリー要素の数を掛けると、修正がほぼ不可能な内訳。
2. Doctrine Extensions Treeでは、ルート要素を標準メソッド（moveUp、moveDown）と交換することは不可能です。 これを行おうとすると、対応するメッセージとともに「例外」がスローされます。 言うまでもなく、その振る舞いは奇妙で予想外ですが、それに耐えなければなりません。
3. ステップ1で、ルート、lft、rgtフィールドについて説明しました。これらの値が失敗すると、ツリー全体が破壊されます。 次に、火に燃料を追加します。 このような状況は、外部キーの存在が原因でツリー要素を削除するときに障害が発生した場合に発生します。 私の場合、これらは各記事に「ねじ込まれた」追加要素でした。 この問題は、サイトをコンテンツで満たした後、すべての栄光で明らかになり、ツリーを復元するには多くの神​​経と労力が必要でした。

管理パネルのツリー構造の結論

解決する必要がある最初の問題の1つは、管理パネルのツリー形式のページの出力でした。つまり、記事タイトルの前の左側にネストレベルに対応するスペースの数を追加しました。 同じ問題は、選択ドロップダウンにもありました。 ソリューションは非常にシンプルであることがわかりました-__toStringメソッドとgetLaveledTitleメソッドをモデルに追加します。

class Page { ... public function __toString() { $prefix = ""; for ($i=2; $i<= $this->lvl; $i++){ $prefix .= "& nbsp;& nbsp;& nbsp;& nbsp;"; } return $prefix . $this->title; } public function getLaveledTitle() { return (string)$this; } ... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これで、リスト設定で、その場で生成されたlaveled_titleフィールドを使用できるようになりました。



解決策が最善ではないことに同意しますが、ここでは他に説明はありません。







上記で書いた問題のパラグラフ2を思い出してください。 この問題を回避する最も簡単な方法は、1つのルート要素を作成し、それをまったく使用しないか、メインページのテキストとして使用することです。

「== Root Element ==」という名前を付け、他の場所では使用しないことにしました。 つまり、管理パネルでの編集/削除を禁止します。 他のすべての記事は、このルート要素の直接の子孫、または子孫の子孫でなければなりません。 ルート要素は手作業でデータベースに作成され、編集できないようにするために、createQueryメソッドがPageAdminクラスに追加されました。



ここではPageAdminクラスの完全なコードを示し、以下ではどのメソッドと何が使用されたかを説明します。

 <? namespace Shtumi\PravBundle\Admin; use Sonata\AdminBundle\Admin\Admin; use Sonata\AdminBundle\Form\FormMapper; use Sonata\AdminBundle\Datagrid\ListMapper; use Sonata\DoctrineORMAdminBundle\Datagrid\ProxyQuery; class PageAdmin extends Admin{ protected $maxPerPage = 2500; protected $maxPageLinks = 2500; protected $datagridValues = array( '_sort_order' => 'ASC', '_sort_by' => 'p.root, p.lft' ); public function createQuery($context = 'list') { $em = $this->modelManager->getEntityManager('Shtumi\PravBundle\Entity\Page'); $queryBuilder = $em ->createQueryBuilder('p') ->select('p') ->from('ShtumiPravBundle:Page', 'p') ->where('p.parent IS NOT NULL'); $query = new ProxyQuery($queryBuilder); return $query; } protected function configureListFields(ListMapper $listMapper) { $listMapper ->add('up', 'text', array('template' => 'ShtumiPravBundle:admin:field_tree_up.html.twig', 'label'=>' ')) ->add('down', 'text', array('template' => 'ShtumiPravBundle:admin:field_tree_down.html.twig', 'label'=>' ')) ->add('id', null, array('sortable'=>false)) ->addIdentifier('laveled_title', null, array('sortable'=>false, 'label'=>' ')) ->add('_action', 'actions', array( 'actions' => array( 'edit' => array(), 'delete' => array() ), 'label'=> '' )) ; } protected function configureFormFields(FormMapper $form) { $subject = $this->getSubject(); $id = $subject->getId(); $form ->with('') ->add('parent', null, array('label' => '' , 'required'=>true , 'query_builder' => function($er) use ($id) { $qb = $er->createQueryBuilder('p'); if ($id){ $qb ->where('p.id <> :id') ->setParameter('id', $id); } $qb ->orderBy('p.root, p.lft', 'ASC'); return $qb; } )) ->add('title', null, array('label' => '')) ->add('text', null, array('label' => ' ')) ->end() ; } public function preRemove($object) { $em = $this->modelManager->getEntityManager($object); $repo = $em->getRepository("ShtumiPravBundle:Page"); $subtree = $repo->childrenHierarchy($object); foreach ($subtree AS $el){ $menus = $em->getRepository('ShtumiPravBundle:AdditionalMenu') ->findBy(array('page'=> $el['id'])); foreach ($menus AS $m){ $em->remove($m); } $services = $em->getRepository('ShtumiPravBundle:Service') ->findBy(array('page'=> $el['id'])); foreach ($services AS $s){ $em->remove($s); } $em->flush(); } $repo->verify(); $repo->recover(); $em->flush(); } public function postPersist($object) { $em = $this->modelManager->getEntityManager($object); $repo = $em->getRepository("ShtumiPravBundle:Page"); $repo->verify(); $repo->recover(); $em->flush(); } public function postUpdate($object) { $em = $this->modelManager->getEntityManager($object); $repo = $em->getRepository("ShtumiPravBundle:Page"); $repo->verify(); $repo->recover(); $em->flush(); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ネストされたツリーでツリーを構築することには、1つの特徴があります。 正しい順序でツリー全体を左から右に回るには、まず要素をルートフィールドでソートし、次にlftフィールドでソートする必要があります。 このため、$ datagridValuesプロパティが追加されました。



ツリーを編集する場合、ほとんどの場合、ページネーションは必要ありません。 したがって、要素の数を標準の30から2500に1ページ増やしました。

要素の追加/編集

ここでの主な問題は、記事を編集する形式での親の階層ドロップダウンリストの出力でした。 この問題は、エンティティの親フィールドにクロージャを持つquery_builderを追加することで解決しました。 データベースにルート要素「== Root element ==」があるため、親フィールドが必要です。







postPersistおよびpostUpdateメソッドに関しては、これらのアクションの後、ツリー構造が破損しないことを確認するために、リポジトリのverifyおよびrecoverメソッドを呼び出すために追加されました。

隣人を基準にしてアイテムを並べ替える

また、ユーザーが隣人に対して記事を上下に移動できるボタンを作成する必要がありました。 SonataAdminBundleを使用すると、レコードのリストのフィールドでテンプレートを使用できます。 したがって、次の2つのテンプレートを作成する必要があります。それぞれ、上下ボタン用です。



ShtumiPravBundle：管理者：field_tree_up.html.twig

 {% extends 'SonataAdminBundle:CRUD:base_list_field.html.twig' %} {% block field %} {% spaceless %} {% if object.parent.children[0].id != object.id %} <a href="{{ path('page_tree_up', {'page_id': object.id}) }}"> <img src="{{ asset('bundles/shtumiprav/images/admin/arrow_up.png') }}" alt="{% trans %}{% endtrans %}" /> </a> {% endif %} {% endspaceless %} {% endblock %}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ShtumiPravBundle：管理者：field_tree_down.html.twig

 {% extends 'SonataAdminBundle:CRUD:base_list_field.html.twig' %} {% block field %} {% spaceless %} {% if object.parent.children[object.parent.children|length - 1].id != object.id %} <a href="{{ path('page_tree_down', {'page_id': object.id}) }}"> <img src="{{ asset('bundles/shtumiprav/images/admin/arrow_down.png') }}" alt="{% trans %}{% endtrans %}" /> </a> {% endif %} {% endspaceless %} {% endblock %}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これらのテンプレートは、PageAdminクラスのconfigureListFieldsメソッドで接続されます。



routing.ymlファイルに2つのパスを追加する必要があります。それぞれ上ボタンと下ボタン用です。

 page_tree_up: pattern: /admin/page_tree_up/{page_id} defaults: { _controller: ShtumiPravBundle:PageTreeSort:up } page_tree_down: pattern: /admin/page_tree_down/{page_id} defaults: { _controller: ShtumiPravBundle:PageTreeSort:down }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

もちろん、記事の移動を実行するPageTreeSortControllerコントローラーを作成する必要があります。

 <?php namespace Shtumi\PravBundle\Controller; use Symfony\Bundle\FrameworkBundle\Controller\Controller; use Sensio\Bundle\FrameworkExtraBundle\Configuration\Route; use Sensio\Bundle\FrameworkExtraBundle\Configuration\Template; use JMS\SecurityExtraBundle\Annotation\Secure; class PageTreeSortController extends Controller { /** * @Secure(roles="ROLE_SUPER_ADMIN") */ public function upAction($page_id) { $em = $this->getDoctrine()->getEntityManager(); $repo = $em->getRepository('ShtumiPravBundle:Page'); $page = $repo->findOneById($page_id); if ($page->getParent()){ $repo->moveUp($page); } return $this->redirect($this->getRequest()->headers->get('referer')); } /** * @Secure(roles="ROLE_SUPER_ADMIN") */ public function downAction($page_id) { $em = $this->getDoctrine()->getEntityManager(); $repo = $em->getRepository('ShtumiPravBundle:Page'); $page = $repo->findOneById($page_id); if ($page->getParent()){ $repo->moveDown($page); } return $this->redirect($this->getRequest()->headers->get('referer')); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このコントローラーにアクセスできるのは管理者だけなので、ロールROLE_SUPER_ADMINの制限が必要です。

アイテムを削除する

ツリー要素を削除する主な微妙な点は、外部キーによる競合が発生せず、ツリーに障害が発生しないように注意する必要があることです。 これについては、ネストされたツリーの問題のパラグラフ3ですでに説明しました。



記事を削除する前に、他のモデルから記事に関連するすべてのエントリを削除する必要があることを示すために、PageAdminクラスからpreRemoveメソッドを削除しませんでした。 私の場合、これらはAdditionalMenuおよびServiceモデルでした。



また、この場合、カスケード削除モデルでのインストールが機能しないことに注意してください。 実際のところ、Doctrine Extensions Treeは独自のメソッドを使用して子孫を削除しますが、子孫はカスケードに注意を払っていません。 確かに、私はまだカスケード削除をインストールしました：

 class Page { ... /** * @ORM\OneToMany(targetEntity="Service", mappedBy="page", cascade={"all"}, orphanRemoval=true) * @ORM\OrderBy({"position"="ASC"}) */ protected $services; ... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ネストされたツリーは自動的に子孫を削除します。 設定するものは何もありませんでした。

おわりに

私が説明したソリューションには複雑なことは何もないように見えますが、SonataAdminBundleで管理者を作成する機能が複雑であるため、ネストされたツリーの動作が完全に透過的でない場合があるため、しばらくの間このソリューションをいじくり回す必要がありました。 同様のタスクを実装するときに、これが時間の節約に役立つことを願っています。



このソリューションには何が欠けています。 最初に頭に浮かぶのは、サブツリーを隠すことです。 つまり、各要素の横にある「プラス」により、子孫を表示できます。 このようなソリューションは、非常に大きなツリーに関連します。 改善の2番目のアイデアは最初から続きます-管理者がプラス記号をクリックしてこの親要素を記憶し、新しい記事を作成するときに、「親」フィールドで自動的に選択するようにします。



両方の問題の解決は難しくありません。 「プラス記号」用の別のテンプレートを作成し、コントローラーでセッションに保存する要素と表示する要素を保存する必要があります。 さて、createQueryメソッドで、このセッションのデータを処理します。