architecture.rst 4.8 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142
  1. Architecture
  2. ============
  3. The architecture of the bundle is primarily inspired by the Django Admin
  4. Project, which is truly a great project. More information can be found at the
  5. `Django Project Website`_.
  6. The Admin Class
  7. ---------------
  8. The ``Admin`` class represents the CRUD definition for a specific model. It
  9. contains all the configuration necessary to display a rich CRUD interface for
  10. the entity.
  11. Within the admin class, the following information can be defined:
  12. * ``list``: The fields displayed in the list table;
  13. * ``filter``: The fields available for filtering the list;
  14. * ``form``: The fields used to edit the entity;
  15. * ``formGroups``: The group definition where a field must be displayed (edit form)
  16. * Batch actions: Actions that can be performed on a group of entities
  17. (e.g. bulk delete)
  18. If a field is associated with another entity (and that entity also has an
  19. ``Admin`` class), then the related ``Admin`` class will be accessible from
  20. within the first class.
  21. The admin class is a service implementing the ``AdminInterface`` interface,
  22. meaning that the following required dependencies are automatically injected:
  23. * ``ListBuilder``: builds the list fields
  24. * ``FormContractor``: constructs the form using the Symfony ``FormBuilder``
  25. * ``DatagridBuilder``: builds the filter fields
  26. * ``Router``: generates the different urls
  27. * ``Request``
  28. * ``ModelManager``: Service which handles specific ORM code
  29. * ``Translator``
  30. Therefore, you can gain access to any service you want by injecting them into
  31. the admin class, like so:
  32. .. code-block:: xml
  33. <service id="sonata.news.admin.post" class="%sonata.news.admin.post.class%">
  34. <tag name="sonata.admin" manager_type="orm" group="sonata_blog" label="post"/>
  35. <argument />
  36. <argument>%sonata.news.admin.post.entity%</argument>
  37. <argument>%sonata.news.admin.post.controller%</argument>
  38. <call method="setUserManager">
  39. <argument type="service" id="fos_user.user_manager" />
  40. </call>
  41. </service>
  42. Here, the FOS' User Manager is injected into the Post service.
  43. Field Definition
  44. ----------------
  45. A field definition is a ``FieldDescription`` object. There is one definition per list
  46. field.
  47. The definition contains:
  48. * ``name``: The name of the field definition;
  49. * ``type``: The field type;
  50. * ``template``: The template to use to display the field;
  51. * ``targetEntity``: The class name of the target entity for relations;
  52. * ``options``: Certain field types have additional options;
  53. Template Configuration
  54. -----------------------
  55. The current implementation uses Twig as the template engine. All templates
  56. are located in the ``Resources/views/CRUD`` directory of the bundle. The base
  57. template extends two layouts:
  58. * ``AdminBundle::standard_layout.twig``
  59. * ``AdminBundle::ajax_layout.twig``
  60. The base templates can be configured in the Service Container. So you can easily tweak
  61. the layout to suit your requirements.
  62. Each field is rendered in three different ways and each has its own Twig
  63. template. For example, for a field with a ``text`` type, the following three
  64. templates will be used:
  65. * ``edit_text.twig``: template used in the edit form
  66. * ``filter_text.twig``: template used in the filter box
  67. * ``list_text.twig``: template used in the list table
  68. CrudController
  69. --------------
  70. The controller contains the basic CRUD actions, it controller is related to one
  71. ``Admin`` class by mapping the controller name to the correct ``Admin``
  72. instance.
  73. Any or all actions can be overwritten to suit the project's requirements.
  74. The controller uses the ``Admin`` class to construct the different actions.
  75. Inside the controller, the ``Admin`` object is accessible through the
  76. ``configuration`` property.
  77. Obtaining an ``Admin`` Service
  78. ------------------------------
  79. ``Admin`` definitions are accessible through the 'sonata.admin.pool' service or
  80. directly from the DIC. The ``Admin`` definitions are lazy loaded from the DIC to
  81. reduce overhead.
  82. Declaring a new Admin class
  83. ---------------------------
  84. Once you have created an admin class, you must declare the class to use it. Like
  85. .. code-block:: xml
  86. <!-- app/config/config.xml -->
  87. <service id="sonata.news.admin.post" class="Sonata\NewsBundle\Admin\PostAdmin">
  88. <tag name="sonata.admin" manager_type="orm" group="sonata_blog" label="post"/>
  89. <argument />
  90. <argument>Sonata\NewsBundle\Entity\Post</argument>
  91. <argument>SonataNewsBundle:PostAdmin</argument>
  92. </service>
  93. Or if you're using a YML configuration file,
  94. .. code-block:: yaml
  95. services:
  96. sonata.news.admin.post:
  97. class: Sonata\NewsBundle\Admin\PostAdmin
  98. tags:
  99. - { name: sonata.admin, manager_type: orm, group: sonata_blog, label: post }
  100. arguments: [null, Sonata\NewsBundle\Entity\Post, SonataNewsBundle:PostAdmin]
  101. .. _`Django Project Website`: http://www.djangoproject.com/