Installation

Requirements

No PHP extension beyond a standard build is declared. The application needs the PDO driver of its database (pdo_mysql, pdo_pgsql or pdo_sqlite); the bundle is tested on SQLite, MySQL 8 and PostgreSQL.

Bundles the application registers

The bundle requires the libraries above, not the framework bundles. What it registers depends on the bundles the kernel has (read from kernel.bundles):

The controller and the Twig runtime use the router and request_stack services, and the commands run in bin/console: in practice, the rendering layer needs FrameworkBundle as well. When the container has an event_dispatcher service, the workflow dispatches its events through it. The publisher dates publications with the clock service, which FrameworkBundle registers once symfony/clock is installed.

Installing

The bundle is in 0.1.x-dev (dev-main is aliased to 0.1.x-dev) and is not yet published on Packagist, and neither is phil/ddd-bundle. Until they are, declare a repository that holds both packages, a path repository to a local checkout or a vcs repository per package:

{
    "repositories": [
        { "type": "path", "url": "../phil-bundles/packages/*" }
    ]
}

Then require the bundle, and the framework bundles you want it to wire:

composer require phil/content-bundle:^0.1@dev phil/ddd-bundle:^0.1@dev
composer require doctrine/doctrine-bundle symfony/twig-bundle

The bundle's own composer.json declares "minimum-stability": "dev" and "prefer-stable": true. That only applies when the bundle is the root package; an application that requires it needs @dev on the constraints, as above, or the same stability settings.

Registering the bundle

Add it to config/bundles.php, after DoctrineBundle and TwigBundle:

return [
    Symfony\Bundle\FrameworkBundle\FrameworkBundle::class => ['all' => true],
    Doctrine\Bundle\DoctrineBundle\DoctrineBundle::class => ['all' => true],
    Symfony\Bundle\TwigBundle\TwigBundle::class => ['all' => true],
    Phil\DddBundle\PhilDddBundle::class => ['all' => true],
    Phil\ContentBundle\PhilContentBundle::class => ['all' => true],
];

Registering phil/ddd-bundle is optional for this bundle: it only uses its classes, not its services.

What to write in the application

1. A root entity and a row entity per kind of content (storage.md): the root extends AbstractContentRoot, declares an identifier in a column named id and names its row class; the row extends AbstractDimensionContent and implements the capabilities it needs, with their traits (capabilities.md).
2. The configuration (configuration.md): the served locales and their fallback chains, the root classes, and — to serve pages — the Symfony routes of each kind and the Twig template of each template key.
3. The routes that mount ContentController (routing.md) and the templates they render (rendering.md).

Database schema

The bundle ships no migration. With DoctrineBundle, its mappings are part of the ORM metadata, so the application's migration tool sees them:

bin/console doctrine:migrations:diff
bin/console doctrine:migrations:migrate

The schema holds one table per row class (the application names it), with the columns of the dimension, the root_id join column, the unique constraint (root_id, stage, version, locale_key) and the columns of every capability the class implements; the route table, phil_content_route; and the table of working copies, phil_content_working_copy. The columns are listed in storage.md and capabilities.md.

The ORM mappings are prepended to the entity manager named default (doctrine.orm.mappings); see configuration.md for entity_manager.

Routes and templates

The bundle imports no route file and ships no template. The application mounts ContentController on routes of its own and lists them under phil_content.routes; it writes the templates and lists them under phil_content.templates (routing.md, rendering.md).