architecture.rst 3.1 KB

1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889
  1. Architecture
  2. ============
  3. The architecture of the bundle is mostly based off of the Django Admin Project,
  4. which is a truly great project. More information can be found at the
  5. `Django Project Website`_.
  6. The Admin Class
  7. ---------------
  8. The ``Admin`` class is the CRUD definition of one Doctrine entity. It contains
  9. all the configuration necessary to display a rich CRUD for the entity. From
  10. within an admin class, the following information can be defined:
  11. * ``listFields``: The fields displayed in the list table;
  12. * ``filterFields``: The fields available for filter the list;
  13. * ``formFields``: The fields used to edit the entity;
  14. * ``formGroups``: The group definition where a field must be displayed (edit form)
  15. * The batch actions: Actions that can be performed on a group of entities
  16. (e.g. bulk delete)
  17. If a field is associated with another entity (and that entity also has an
  18. ``Admin`` class), then the related ``Admin`` class will be accessible from
  19. within the first ``Admin`` class.
  20. The admin class is ContainerAware, meaning that the entire dependency injection
  21. container is injected. Therefore, you have access to every service and can
  22. do things such as:
  23. * Access user permissions to define the list fields;
  24. * Access the ``Router`` to generate custom routes.
  25. Field Definition
  26. ----------------
  27. A field definition is a FieldDescription object. There is one definition per list
  28. field.
  29. The definition contains:
  30. * ``name``: The name of the field definition;
  31. * ``type``: The field type;
  32. * ``template``: The template to use to display the field;
  33. * ``targetEntity``: The class name of the target entity for relations;
  34. * ``options``: Certain field types have additional options;
  35. Template Configuration
  36. ~~~~~~~~~~~~~~~~~~~~~~
  37. The current implementation uses Twig as the template engine. All templates
  38. are located in the Resources/views/CRUD directory of the bundle. The base
  39. template extends two layouts:
  40. * ``BaseApplicationBundle::standard_layout.twig``
  41. * ``BaseApplicationBundle::ajax_layout.twig``
  42. Each field is rendered in three different ways and each has its own Twig
  43. template. For example, for a field with a ``text`` type, the following three
  44. templates will be used:
  45. * ``edit_text.twig``: template used in the form edition
  46. * ``filter_text.twig``: template used in the filter box
  47. * ``list_text.twig``: template used in the list table
  48. CrudController
  49. --------------
  50. The controller contains the basic CRUD actions, the controller is
  51. related to one ``Admin`` class by mapping the controller name to the correct
  52. ``Admin`` instance.
  53. All actions can be easily overwritten depending on the project's requirements.
  54. The controller uses the ``Admin`` class to construct the different actions.
  55. Inside the controller, the ``Admin`` object is accessible through the ``configuration``
  56. property.
  57. Obtaining an ``Admin`` Service
  58. ------------------------------
  59. ``Admin`` definition are accessible through the 'base_application.pool' service.
  60. The ``Admin`` definitions are lazy loaded from the Pool to avoid overhead.
  61. Filter and Datagrid
  62. -------------------
  63. todo ...
  64. .. _`Django Project Website`: http://www.djangoproject.com/