PHP/Symfony Data Jukebox Tutorial Bundle |
The Data Jukebox Bundle sticks to Symfony philosophy as much as possible. Shortly put, one defines Entities
, which are then manipulated - in the Controller
- thanks to a corresponding (standard or customized) Repository
. Rendering is achieved via Template
while localization is done thanks to translation files
.
The Data Jukebox Bundle simply adds Properties
to the picture, which corresponds to a PHP class where specific methods - matching the PropertiesInterface
definition - allow to retrieve additional meta-data about the corresponding Entity
and construct - entirely automatically - the views for the common CRUD
(Create-Read-Update-Delete) operations.
The one aspect where the Data Jukebox Bundle differs from Symfony is the way it deals with joined entities. Shortly put: it doesn't! Read operations can not use joined entities the way Symfony does. The idea behind this design decision is that joining entities fields (aka. tables columns) for read purposes is something that is better achieved in SQL views, with all the power of the database engine backing the operation. Thus, while relationships can still be defined and used according to Symfony philosophy when dealing with forms - even within the Data Jukebox Bundle realm - they must be "resolved" at the SQL (view) level when dealing with read actions, with joined columns being returned as scalar values rather than entities (objects). This distinction between the two purposes is implemented using entity inheritance, where an abstract MappedSuperclass
acts as parent for one standard, table-backed Entity
and another joined, view-backed (View)Entity
.
A sample blog application will be used to illustrate how to use the Data Jukebox Bundle.
To start with, we will define a Blog Category Entity
:
The only way it differs from a standard Symfony entity:
Properties
class, using the annotation @Properties(propertiesClass="...")We will cover those changes when dealing with the application core entity (see below).
We will now define the Blog Entry resources.
Given the many-to-one relationship with the Blog Category entity and Data Jukebox way of dealing with those, we must first define the parent abstract SuperClass
:
Then we can define the corresponding "standard", table-backed Entity
(for create/update purposes):
And its joined, view-backed Entity
(for read purposes), where the Category is no longer an entity/object, but a scalar (string) corresponding to the category name:
The Primary Key Interface and its sole getPrimaryKey() method are here to simplify the process of retrieving the entity primary key name(s)/value(s) pair(s). If an entity has more than one field acting as identifier - thus corresponding to a composite primary key - one must just make sure to include all identifier fields in the returned array.
The entity associated Properties is where all the magic of the Data Jukebox Bundle takes its root:
Ok, this is a lengthy definition... but at the end of the day, it says all there is to know about the entity in order to create all views - for create/read/update/delete purposes - automatically, while respecting the business logic that backs the entity.
We can now create the Controller that will create all those views:
... and this is it!
A few things are worth noting when using the Data Jukebox Bundle:
_pk
, even for entities that have a composite (multiple-fields) primary key.form
and (Data Jukebox) DataJukebox_list
/DataJukebox_detail
functions in your Twig templates (Note: PHP templates are NOT supported).translations
files, along the handy getMeta method in your Properties
; just make sure to specify the correct translation domain
.PHP/Symfony Data Jukebox Tutorial Bundle |
Documentation generated on Wed, 15 Nov 2017 15:15:10 +0100 by phpDocumentor 1.4.4