saving_hooks.rst 5.0 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137
  1. Saving hooks
  2. ============
  3. When a SonataAdmin is submitted for processing, there are some events called. One
  4. is before any persistence layer interaction and the other is afterward. Also between submitting
  5. and validating for edit and create actions ``preValidate`` event called. The
  6. events are named as follows:
  7. - new object : ``preValidate($object)`` / ``prePersist($object)`` / ``postPersist($object)``
  8. - edited object : ``preValidate($object)`` / ``preUpdate($object)`` / ``postUpdate($object)``
  9. - deleted object : ``preRemove($object)`` / ``postRemove($object)``
  10. It is worth noting that the update events are called whenever the Admin is successfully
  11. submitted, regardless of whether there are any actual persistence layer events. This
  12. differs from the use of ``preUpdate`` and ``postUpdate`` events in DoctrineORM and perhaps some
  13. other persistence layers.
  14. For example: if you submit an edit form without changing any of the values on the form
  15. then there is nothing to change in the database and DoctrineORM would not fire the **Entity**
  16. class's own ``preUpdate`` and ``postUpdate`` events. However, your **Admin** class's
  17. ``preUpdate`` and ``postUpdate`` methods *are* called and this can be used to your
  18. advantage.
  19. .. note::
  20. When embedding one Admin within another, for example using the ``sonata_type_admin``
  21. field type, the child Admin's hooks are **not** fired.
  22. Example used with the FOS/UserBundle
  23. ------------------------------------
  24. The ``FOSUserBundle`` provides authentication features for your Symfony Project,
  25. and is compatible with Doctrine ORM, Doctrine ODM and Propel. See
  26. `FOSUserBundle on GitHub`_ for more information.
  27. The user management system requires to perform specific calls when the user
  28. password or username are updated. This is how the Admin bundle can be used to
  29. solve the issue by using the ``preUpdate`` saving hook.
  30. .. code-block:: php
  31. <?php
  32. namespace FOS\UserBundle\Admin\Entity;
  33. use Sonata\AdminBundle\Admin\AbstractAdmin;
  34. use FOS\UserBundle\Model\UserManagerInterface;
  35. class UserAdmin extends AbstractAdmin
  36. {
  37. protected function configureFormFields(FormMapper $formMapper)
  38. {
  39. $formMapper
  40. ->with('General')
  41. ->add('username')
  42. ->add('email')
  43. ->add('plainPassword', 'text')
  44. ->end()
  45. ->with('Groups')
  46. ->add('groups', 'sonata_type_model', array('required' => false))
  47. ->end()
  48. ->with('Management')
  49. ->add('roles', 'sonata_security_roles', array( 'multiple' => true))
  50. ->add('locked', null, array('required' => false))
  51. ->add('expired', null, array('required' => false))
  52. ->add('enabled', null, array('required' => false))
  53. ->add('credentialsExpired', null, array('required' => false))
  54. ->end()
  55. ;
  56. }
  57. public function preUpdate($user)
  58. {
  59. $this->getUserManager()->updateCanonicalFields($user);
  60. $this->getUserManager()->updatePassword($user);
  61. }
  62. public function setUserManager(UserManagerInterface $userManager)
  63. {
  64. $this->userManager = $userManager;
  65. }
  66. /**
  67. * @return UserManagerInterface
  68. */
  69. public function getUserManager()
  70. {
  71. return $this->userManager;
  72. }
  73. }
  74. The service declaration where the ``UserManager`` is injected into the Admin class.
  75. .. configuration-block::
  76. .. code-block:: xml
  77. <service id="fos.user.admin.user" class="%fos.user.admin.user.class%">
  78. <tag name="sonata.admin" manager_type="orm" group="fos_user" />
  79. <argument />
  80. <argument>%fos.user.admin.user.entity%</argument>
  81. <argument />
  82. <call method="setUserManager">
  83. <argument type="service" id="fos_user.user_manager" />
  84. </call>
  85. </service>
  86. Hooking in the Controller
  87. -------------------------
  88. You may have noticed that the hooks present in the **Admin** do not allow you
  89. to interact with the process of deletion: you can't cancel it. To achieve this
  90. you should be aware that there is also a way to hook on actions in the Controller.
  91. If you define a custom controller that inherits from ``CRUDController``, you can
  92. redefine the following methods:
  93. - new object : ``preCreate($object)``
  94. - edited object : ``preEdit($object)``
  95. - deleted object : ``preDelete($object)``
  96. - show object : ``preShow($object)``
  97. - list objects : ``preList($object)``
  98. If these methods return a **Response**, the process is interrupted and the response
  99. will be returned as is by the controller (if it returns null, the process continues). You
  100. can generate easily a redirection to the object show page by using the method
  101. ``redirectTo($object)``.
  102. .. note::
  103. Use case: you need to prohibit the deletion of a specific item. You may do a simple
  104. check in the ``preDelete($object)`` method.
  105. .. _FOSUserBundle on GitHub: https://github.com/FriendsOfSymfony/FOSUserBundle/