The twig-extension repository is usually fetched by calling

$ bin/vendor install

into your project´s ./vendor directory (because it is part of the ./deps file of each symfony 2 standard edition).

After installing the required vendor files, register the namespace fallback in your autoload.php (if you use the one delivered with Symfony 2 Standard, this should already have been done for you):

use Symfony\Component\ClassLoader\UniversalClassLoader;
use Doctrine\Common\Annotations\AnnotationRegistry;

$loader = new UniversalClassLoader();
$loader->registerNamespaces(array(
    'Symfony'          => array(__DIR__.'/../vendor/symfony/src', __DIR__.'/../vendor/bundles'),
    // ...
));

$loader->registerPrefixes(array(
    'Twig_Extensions_' => __DIR__.'/../vendor/twig-extensions/lib',
    'Twig_'            => __DIR__.'/../vendor/twig/lib',
));

Remember that twig extensions are always registered as tagged services, but it is not always desirable to register a twig extension like e.g. the Debug-Extension as a regular service globally. We could do so by adding the service definition to the services.xml-file in one of our bundles. But due to the special purpose of the debug extension, we will choose a different, more “project-wide-configuration”-way.

Luckily, Symfony provides means to dynamically load services “on demand” and depending on the current environment.

Add the following lines to your app/config/config_dev.yml:

services:
    debug.twig.extension:
        class: Twig_Extensions_Extension_Debug
        tags: [{ name: 'twig.extension' }]

The “services”-configuration option may be utilized to register any class as a DIC managed service, for each project and independent from your bundle configuration (But remember that “regular” service definition configuration should usually happen in your bundle´s configuration files, otherwise you will not able to distribute your bundles because of missing or broken dependencies).

For twig extensions that should only be loaded for special purposes (like our DEBUG-function which is only needed in development environments), config_dev.yml is the perfect place to register them.

Note the “tags”-configuration which marks the service as a twig extension. Now, let´s create a demo twig-template and try the {% debug %} function:

{% extends "NerdpressDemoBundle::layout.html.twig" %}
{% debug %}

That will do. Open the page in your favorite webbrower (after defining a route, a controller and other stuff i won´t mention here) and admire the debug output. Note that the output will be much more nicer if you have had installed a native php debug extension like e.g. XDebug.

Mein Lieblingsthema ist ja zur Zeit der Dependency Injection Container. Und irgendwie stinkt mir die ganze Container-Konfiguration noch gewaltig. Meine kläglichen Versuche, selbst mal so was ähnliches wie eine brauchbare Autowiring-Implementierung herunterzubrechen, waren natürlich auch bzw. erst recht nicht der große Wurf – was vor allem daran lag, dass ich den Service Container und damit den ganzen Sinn und Zweck des Ganzen einfach mal wegrationalisiert hatte – Loose Coupling sieht natürlich anders aus, das sei den Kritikern zugestanden. Ich verteidige mich mal dadurch, dass ich eigentlich nur mal mit Mixins rumspielen wollte – da hab’ ich wohl die eine oder andere Begrifflichkeit durcheinander geworfen.

Aber um mal zu des Pudels Kern zu kommen: Ist es wirklich so geil, mit kilometerlangen XML-Dateien, ‘ner Menge Initialisierungscode und ohne mit der heißgeliebten Code-Completion in der IDE meiner Wahl ein Paradigma zu kaufen, das im speziellen Anwendungskontext – nicht im Framework-Kontext – eher selten Anwendung findet?

Es ist doch so: PHP bietet zwar mittlerweile eine vernünftige Reflection API, aber wenig (keine) Möglichkeiten, Code zur Compile- oder Runtime effizient zu injizieren (vorbei bspw. an der Sichtbarkeit, was für Property Injection aus meiner Sicht erforderlich wäre). Mit Handständen geht das mittels der Reflection API, noch fieser mit bspw. Runkit.

Somit ist – (natürlich nur aus meiner Sicht, was im Übrigen für den gesamten “Complaint” gilt – dabei wäre ich wirklich froh, berichtigt zu werden) jeder Versuch, die Konfiguration eines wie auch immer gearteten, auf PHP sitzenden, DIC mit Syntactic Sugar anzureichern, vergeblich. Und Syntactic Sugar ist dringend vonnöten, um das Zeug in der Praxis RAD-tauglich zu machen. Nehme ich PHP den RAD-Faktor, was bleibt denn dann noch übrig?

Symfony 2 behilft sich damit, einen DI-Container zu definieren und ihn als PHP-Code wegzucachen. Dieser hat dann Accessoren für alle definierten Services, Constructor-Injection ist durch Referenzierung in den Konfigurationsdateien möglich. Die Doku spricht zusätzlich von Setter- und Property-Injection, dazu konnte ich aber irgendwie keine dokumentierten Beispiele finden. Es gibt aber immerhin die Möglichkeit, Methoden in der Service-Klasse als Pre- oder Post-Initialization Interceptoren auszuführen.

Letztlich tut der Container, was er soll: Abhängigkeiten in beliebige Instanzen zu injizieren. Bei Bedarf auch gegen ein Interface, aber das ist letztlich aufgrund des Sprachentwurfs nur optional (Was impliziert, das man auf Kosten riesiger Flexibilität – die man nicht braucht – schnell mal riskiert, durch einen falsch konfigurierten DI-Container seine Anwendung kaputt zu machen).

Aber der Aufwand steht meiner Meinung nach noch in keinem Verhältnis zum Nutzen. Am Beispiel einer Controller Extension, die als Service definiert wird, möchte ich das mal demonstrieren. Die offizielle Symfony 2-Dokumentation sagt, dass

To keep things simple, Symfony2 by defaults does not require that controllers be defined as services. Furthermore Symfony2 injects the entire service container into your controller.

Das ist immerhin schon einmal eine Information. Das Standardverhalten ist also, dass ich automagisch eine Controllerklasse habe, die den Container kennt (Wie? Magisch? Ich dachte, Symfony 2 hat die Magie zugunsten transparentem Code und ständiger Kontrolle über jeden Aspekt des Core-Frameworks aufgegeben?). Dadurch, dass er ein ContainerAware Interface implementiert, kennt er auch einen Shortcut auf

$this->container->get('serviceid')

, nämlich

$this->get('serviceid');

. Um Bspw. ein Doctrine-Entity zu persistieren, reichen “ein paar codezeilen”:

     $em = $this->get('doctrine.orm.entity_manager');
     $em->???($myEntity);

Wie hieß die Methode da am Entity Manager jetzt nochmal? Das ist das erste Problem: Dadurch, dass alle Services anonym im Service Container herumdümpeln bzw. auf ihre Instanziierung warten, habe ich in meiner IDE keinerlei Code-Completion mehr. Um das wieder zu erreichen, muss ich entweder
– einen Accessor schreiben (getEntityManager()) und diesen mittels PHP-Doc type-hinten (annotieren) oder
– mindestens einen magischen Docblock davorsetzen, der genau *meiner* IDE die Möglichkeit gibt, den Variablentyp zu erraten (aber ggf. proprietär ist, d.h. in anderen IDEs nicht unbedingt funktionieren muss). Für die Netbeans IDE gibt es dafür bspw. das “vdoc“-Feature.

Das ganze setzt natürlich voraus, dass ich *weiß*, welches Interface der Service doctrine.orm.entity_manager implementiert bzw wie die konkrete Klasse (samt Namespace) desselben heißt. Und vorher muss ich auch noch wissen, wie überhaupt der *Servicename* des Entity Managers lautet.

Bin ich also komplett Ahnungslos, rufe ich erstmal ein Terminal auf, tippe sowas wie

$ app/console container:debug --show-private

ein und suche mir anschließend in der kilometerlangen Liste genau die Services zusammen, die ich brauche.

Dafür brauche ich als Framework-Newbie schonmal richtig tiefgehende Kenntnisse darüber, was ein DIC überhaupt ist, tut und zur Konfiguration erfordert.

Um also das, was “früher” ein

new Cart($color, $maxSpeed)->save()

war, zu erreichen, muss ich nun erstmal ganz schön viel Sport treiben (dieses Beispiel nur exemplarisch, es steht außer Frage, dass die Doctrine 2-Architektur wirklich klasse ist. Das Manko aus meiner Sicht ist die Integration in Sf2, nicht der ORM-Layer an sich.)

Möchte ich den Accessor der ContainerAware-Implementierung am Controller vermeiden und die Services “direkt” injizieren, muss ich ihn selbst als Service am DIC registrieren. Wie das funktioniert, würde den Rahmen sprengen, nur so viel: Der Aufwand steht aus meiner Sicht wieder in keinem Verhältnis zum Ergebnis. Allerdings habe ich damit den Vorteil, dass ich bspw. keine abstrakte Controllerklasse mehr zu erweitern habe – der Controller kann ein simples Popo sein. Dass es aber nicht zu simpel sein darf, zeigt bspw., das ich trotz alledem mindestens einen Constructor definieren muss, der eben alle benötigten Services aufnimmt und an Instanzvariablen bindet. Und das können einige sein – fängt an beim Templating, geht übers Formframework, ggf. den Entity-Manager, einen Mailer und was einem sonst noch so einfällt. Dabei wollten wir doch ab jetzt nur noch leichtgewichtige Controller haben?

Meiner Meinung nach liegt die Lösung der Malaise in zwei Alternativen: Man baut so lange Abstracts, die den ganzen Kram als Shortcuts bereitstellen (dann hätten wir bspw. wieder eine komplexe, abstrakte Kontrollerklasse, die mindestens alles kennt, was in Symfony 1 noch dem ApplicationContext gehörte) – womit wir unser Loose Coupling Pardigma wieder in den Schrank zu den übrigen Ideen stellen können, die im Nachgang irgendwie doch nicht funktionierten. Oder legt Autowiring drüber.

Flow 3 baut bspw. an einem DIC + Autowiring, der alle verwalteten Services durch eine Kombination der Analyse von Annotationen (also PHP-Doccomments) und Signaturen (Typehints) direkt an die erzeugten Instanzen bindet. Die Konfiguration scheint damit sehr viel leichtgewichtiger.

Grails (was so weit ich weiß auf der Spring IOC-Komponente sitzt) geht noch einen Schritt weiter und mappt Instanzvariablen durch reine Naming-Conventions: Wenn also eine Instanzvariable auf “Service” endet und es zur Eigenschaft “mailerService” einen passenden Service “mailer” gibt, wird dieser automagisch injiziert. Kein zusätzlicher Code noch Annotations vonnöten.

Ich wüsste aber nicht, wie man solche Features wirklich performanceneutral, effizient und stabil auf einer Plattform wie PHP aufsetzen könnte – dafür ist die Sprache einfach (noch) nicht weit genug.

Abschließend bleibt ein übler Nachgeschmack – und der Eindruck, dass man sich hier fatal an den XML-“Konfigurationswahnsinn” der entsprechenden Java-“Vorbilder” annähern möchte. Wo doch gerade in diesem Lager intensiv daran gearbeitet wird, genau davon abzurücken und Konfigurationen eben durch Konventionen zu ersetzen.

Was denkt ihr? Kann das ganze doch durch Routine punkten, sodass es durch ein wenig konkrete Projekterfahrung doch ganz leicht von der Hand geht? Wird der DIC im Tagesgeschäft schon intensiv benutzt, oder werden nur die Standardfunktionen des Frameworks verwendet und das Zeug “unter der Haube” doch lieber den Framework- und Bundle-Entwicklern überlassen? Ich bin wieder sehr gespannt auf Meinungen und Kritik…

Also, bauen wir die Sandbox mal nach:

Wir brauchen: Ein halbwegs aktuelles PHP 5.3.x, MySQL 5.x, Apache 2 und git.

Dann erstmal den aktuellen Symfony2-Master ziehen…

$ git clone https://github.com/fabpot/symfony.git symfony2test

… und die Vendor-Scripte installieren:

$ cd symfony2test
$ sh ./install_vendors.sh

Nun sollte sich folgendes Verzeichnislayout ergeben haben:

drwxr-xr-x  6 joshi joshi 4,0K 2010-11-30 21:19 .
drwxr-xr-x 22 joshi joshi 4,0K 2010-11-27 16:34 ..
-rw-rw-rw-  1 joshi joshi  998 2010-11-30 21:10 autoload.php.dist
drwxr-xr-x  8 joshi joshi 4,0K 2010-11-30 21:19 .git
-rw-r--r--  1 joshi joshi   34 2010-11-30 15:49 .gitignore
-rwxrwxrwx  1 joshi joshi  840 2010-11-30 21:10 install_vendors.sh
-rw-rw-rw-  1 joshi joshi 1,1K 2010-11-30 21:10 LICENSE
-rw-rw-rw-  1 joshi joshi 1,1K 2010-11-30 21:10 phpunit.xml.dist
-rw-rw-rw-  1 joshi joshi 1,2K 2010-11-30 21:10 README
drwxrwxrwx  3 joshi joshi 4,0K 2010-11-30 21:10 src
drwxrwxrwx  3 joshi joshi 4,0K 2010-11-30 21:10 tests
-rwxrwxrwx  1 joshi joshi  541 2010-11-30 21:10 update_vendors.sh
drwxrwxrwx 11 joshi joshi 4,0K 2010-11-30 21:13 vendor

Die Vendor-Scripts liegen zunächst mal im Projekt-Root-Verzeichnis; Dort haben sie aber nichts verloren:

$ mv vendor/ src/

Nun haben wir alles, um eine Symfony-App zu erstellen – das funktioniert momentan aber noch ausschließlich in Handarbeit:

$ mkdir -p web app/cache app/logs app/views app/config  src/Bundle src/Application/HelloBundle/Controller src/Application/HelloBundle/Resources/config src/Application/HelloBundle/Resources/views src/Application/HelloBundle/Resources/views/Hello src/Application/HelloBundle/Entity

Anmerkung: Diese wilde Verzeichnisstruktur entspricht 1:1 der Sandbox. Sicherlich steht das endgültige Verzeichnis-Layout eines typischen Symfony2-Projekts noch nicht fest – auch gibt es ja, wie bereits erwähnt, (noch) keine globale Executable samt symfony:generate-project Task. Ein Ziel von Symfony2 ist, die Modularisierung und Entkopplung der einzelnen Framework-Komponenenten (genannt “Bundles”) zu verfeinern. Ähnliche Konzepte kennt man aus der Java-Welt, aber auch bspw. aus CMF wie Silverstripe.

So ist der aktuelle Dev-Branch also eher als lose Sammlung einzelner “Bundles” zu verstehen und nicht als Full-Stack-Framework (Die Menge aller Bundles + Task-Bundle wird aber wieder genau das sein). Am ehesten vielleicht vergleichbar mit dem Aufbau des Zend-Frameworks – wobei das wohl fast als Negativ-Beispiel für “fake-loose-coupling” herhalten kann. Symfony2-Bundles sind “echt” decoupled und erwarten als einzige Abhängigkeit einen PHP-Autoloader.

“Bundles” sind die “Plugins” aus Symfony 1.x, mit dem Unterschied, dass das Core-Framework selbst (“Kernel”) wiederum auch ein Bundle ist.

Kurz gesagt: Das Verzeichnislayout, das in Symfony1.x zwar auch mehr oder weniger flexibel war, doch nur unter Schmerzen tiefgreifend veränderlich war, ist nun erstmal völlig variabel. Da ich mich aber an Fabians vorausschauender best-practice orientieren möchte, sieht “mein” Verzeichnislayout jetzt eben zufälligerweise aus wie das der Symfony2-Sandbox:

app/
  cache/
  config/
  logs/
  views/
autoload.php.dist
install_vendors.sh
LICENSE
phpunit.xml.dist
README
src/
  Application/
    HelloBundle/
      Controller/
      Entity/
      Resources/
        config/
        views/
  Bundle/
  Symfony/
  vendor/
    ...
tests/
update_vendors.sh
web/

Das Verzeichnis /web ist unser Webroot, es sollte nun also ein VirtualHost angelegt werden, der auf dieses zeigt:

<VirtualHost *:80>
  SetEnv APP_ENV dev
  ServerName symfony2.int
  DocumentRoot /var/www/symfony2test/web
</VirtualHost>

Nun können wir damit beginnen, unsere Anwendungsdateien zu erstellen, indem wir einen Frontcontroller anlegen:

web/index.php

<?php
require_once __DIR__.'/../app/AppKernel.php';
use SymfonyComponentHttpFoundationRequest;
$kernel = new AppKernel('prod', false);
$kernel->handle(new Request())->send();

Zunächst holen wir uns den für unsere Anwendung spezifischen Kernel, instanziieren und bitten ihn, einen Http-Request zu bearbeiten.

Damit das Routing funktioniert, benötigen wir noch eine .htaccess-Datei (oder eine entsprechende mod_rewrite-Regel in der VirtualHost-Konfiguration):

web/.htaccess

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteRule ^(.*)$ index.php [QSA,L]
</IfModule>

Dann erzeugen wir unseren Kernel und eine Cache-Definition in app/:

app/AppKernel.php

<?php
require_once __DIR__.'/../src/autoload.php';

use SymfonyComponentHttpKernelKernel;
use SymfonyComponentDependencyInjectionLoaderLoaderInterface;

class AppKernel extends Kernel
{
    public function registerRootDir()
    {
        return __DIR__;
    }

    public function registerBundles()
    {
        $bundles = array(
            new SymfonyBundleFrameworkBundleFrameworkBundle(),
            new SymfonyBundleTwigBundleTwigBundle(),

            // enable third-party bundles
            new SymfonyBundleZendBundleZendBundle(),
            new SymfonyBundleSwiftmailerBundleSwiftmailerBundle(),
            new SymfonyBundleDoctrineBundleDoctrineBundle(),
            
            // register your bundles
            new ApplicationHelloBundleHelloBundle(),
        );

        if ($this->isDebug()) {
            $bundles[] = new SymfonyBundleWebProfilerBundleWebProfilerBundle();
        }

        return $bundles;
    }

    public function registerBundleDirs()
    {
        return array(
            'Application'     => __DIR__.'/../src/Application',
            'Bundle'          => __DIR__.'/../src/Bundle',
            'Symfony\Bundle' => __DIR__.'/../src/Symfony/Bundle',
        );
    }

    public function registerContainerConfiguration(LoaderInterface $loader)
    {
        // use YAML for configuration
        $loader->load(__DIR__.'/config/config_'.$this->getEnvironment().'.yml');
    }
}

Interessant sind die beiden zu implementierenden Methoden registerBundles() und registerBundleDirs(). RegisterBundles() teilt dem Kernel mit, welche Bundles in der Anwendung aktiv sind und verwendet werden – vergleichbar mit enablePlugins() der projectConfiguration.class.php eines beliebigen Symfony 1.x Projekts. registerBundleDirs() mappt wiederum die einzelnen Bundle-Namespaces auf ihre Pfade. Dies ist eigentlich ein wenig doppelt-gemoppelt, verwenden wir doch einen SPL-Autoloader, um unsere Namespaces zu registrieren. Allerdings benötigt der Kernel noch einmal explizit ein Namespace-Bundle-Pfad-Mapping, um bspw. Template-Namespaces korrekt aufzulösen. Stimmt bspw. der Pfad zum SymfonyBundle-Namespace nicht, läuft zwar die Anwendung, doch die Template-Engine kann die Pfade zu bspw. den Assets (Bildern und CSS-Stylesheets) des WebProfilerBundles nicht auflösen. Dies hätte den gleichen Effekt, als hätte ich vergessen, das Assets-Verzeichnis web/sf in einer Symfony 1.x-Anwendung zu referenzieren.

Vorsicht: Die Sandbox und Beispielscripts verwenden hier teils falsche Pfade: So zeigt der Namespace-Pfad der Symfony-Bundles zunächst auf src/vendor/symfony/src/Symfony/Bundle statt auf src/Symfony/Bundle. Das funktioniert in dem Falle auch, weil es eben zwei Symfony-Installationen in der Sandbox gibt (einmal die via install_vendors.sh und die, die man sich selbst gezogen hat). Man sollte sich immerhin für eine entscheiden und seine Projekt- und Arbeitsdateien entsprechend aufräumen. Aber dafür machen wir’s hier ja auch “from scratch”.

Jede Symfony2-Anwendung benötigt zudem eine konkrete, anwendungsspezifische Cache-Implementierung:

app/AppCache.php

<?php
require_once __DIR__.'/AppKernel.php';
use SymfonyBundleFrameworkBundleCacheCache;
class AppCache extends Cache
{
}

Nun können wir uns an die Konfiguration begeben. In der Datei app/AppKernel.php wird bestimmt, wie und wo konfiguriert wird:

    public function registerContainerConfiguration(LoaderInterface $loader)
    {
        // use YAML for configuration
        $loader->load(__DIR__.'/config/config_'.$this->getEnvironment().'.yml');
    }

Demnach müssen wir für jedes Environment eine config_%env%.yml-Datei erstellen. Dadurch, dass das Symfony2 Configuration-Framework explizite Vererbung (besser: imports) untestützt, reicht eine “globale” config.yml und entsprechend angepasste config_%env%.yml-Dateien:

app/config/config.yml

app.config:
    charset:       UTF-8
    error_handler: null
    csrf_secret:   xxxxxxxxxx
    router:        { resource: "%kernel.root_dir%/config/routing.yml" }
    validation:    { enabled: true, annotations: true }
    templating:    {} #assets_version: SomeVersionScheme
    session:
        default_locale: en
        lifetime:       3600
        auto_start:     true

# Twig Configuration
twig.config:
    debug:            %kernel.debug%
    strict_variables: %kernel.debug%

Dann erstellen wir die Konfiguration für das development environment:

app/config/config_dev.yml

imports:
    - { resource: config.yml }

app.config:
    router:   { resource: "%kernel.root_dir%/config/routing_dev.yml" }
    profiler: { only_exceptions: false }

webprofiler.config:
    toolbar: true
    intercept_redirects: true

zend.config:
    logger:
        priority: debug
        path:     %kernel.logs_dir%/%kernel.environment%.log

In Z. 1 wird config.yml als “gobale” Konfiguration importiert. Ansonsten alles mehr oder weniger selbsterklärend, die einzige Auffälligkeit ist, dass das Routing hier nun explizit konfiguriert wird (siehe Z. 5) – im Gegensatz zu Symfony 1.x-Projekten.

Anmerkung: Falls sich jemand wundern sollte, wo und wie diese Fülle an Optionen dokumentiert sind: Hier hilft nur in die jeweilige Service-Definition des DI-Containers zu schauen. Das mag zu Beginn sehr verwirren, doch die einheitliche Bundle-Struktur hilft da wiederum bei der Navigation. Bundle-Konfigurationen findet man ausschließlich im Verzeichnis Resources/ eines Bundles.

Zurück zur Routing-Configuration, die nun angelegt werden muss:

app/config/routing.yml

homepage:
    pattern:  /
    defaults: { _controller: FrameworkBundle:Default:index }

hello:
    resource: HelloBundle/Resources/config/routing.yml

app/config/routing_dev.yml

_main:
    resource: routing.yml

_profiler:
    resource: WebProfilerBundle/Resources/config/routing/profiler.xml
    prefix:   /_profiler

Auch jetzt wurden zwei Routing-Konfigurationen (global und dev), beide werden transparent in config.yml bzw. config_dev.yml referenziert. Die routing_dev.yml ist ausschließlich da um die Route für das WebProfilerBundle zu registrieren.

Die Route “hello” in Z. 5 der routing.yml referenziert wiederum eine Bundle-spezifische Route, abzulegen im HelloBundle:

src/Application/HelloBundle/Resources/config/routing.yml:

hello:
    pattern:  /hello/:name
    defaults: { _controller: HelloBundle:Hello:index }

Somit haben wir fast alles zusammen, um eine Anwendung zum Laufen zu bringen – Front Controller, Kernel-Konfiguration, Cache, Routing – nur die konkrete Implementierung unserer Anwendung fehlt noch sowie ein winziges Detail, der Autoloader. Dieser wird ebenfalls durch unseren Kernel angeschmissen (siehe Z. 1 app/AppKernel.php). Erwartet wird eine flache autoload.php-Datei in src/ – ob sie dort korrekt gelagert ist, oder eher in src/Application liegen sollte oder gar im Projekt root – das kann sich jeder selbst zusammenreimen.

src/autoload.php:

<?php
require_once __DIR__ . '/Symfony/Component/HttpFoundation/UniversalClassLoader.php';

use SymfonyComponentHttpFoundationUniversalClassLoader;

$vendorDir = __DIR__ . '/vendor';

$loader = new UniversalClassLoader();
$loader->registerNamespaces(array(
    'Symfony'                        => __DIR__,
    'Application'                    => __DIR__,
    'Bundle'                         => __DIR__,
    'Doctrine\Common\DataFixtures' => $vendorDir.'/doctrine-data-fixtures/lib',
    'Doctrine\Common'               => $vendorDir.'/doctrine-common/lib',
    'Doctrine\DBAL\Migrations'     => $vendorDir.'/doctrine-migrations/lib',
    'Doctrine\ODM\MongoDB'         => $vendorDir.'/doctrine-mongodb/lib',
    'Doctrine\DBAL'                 => $vendorDir.'/doctrine-dbal/lib',
    'Doctrine'                       => $vendorDir.'/doctrine/lib',
    'Zend'                           => $vendorDir.'/zend/library',
));
$loader->registerPrefixes(array(
    'Swift_' => $vendorDir.'/swiftmailer/lib/classes',
    'Twig_'  => $vendorDir.'/twig/lib',
));
$loader->register();

In autoload.php verwenden wir keine PHP-nativen Autoload-Mechanismen noch den SPL-Autoload-Wrapper direkt, sondern eine weitere Symfony2 Framework-Komponente: Den UniversalClassLoader. Dieser Loader kann Namespaces auflösen, lässt sich aber ebenfalls auf die “alte”, unter PHP >= 5.2 gängige Zend bzw. Pear-Notation mappen, was das obige Codesnippet aufzeigt. Intern baut der UniversalClassLoader natürlich auf den entsprechenden SPL-Funktionen auf.

Vorsicht: Der Code entspricht wieder nicht dem originalen Sandbox-Code (Der Namespace-Pfad für die Symfony-Komponenten ist wieder src/ statt src/vendor/symfony/src).

Wir haben weiter oben Routen definiert, die nun entsprechende Endpunkte im HelloBundle brauchen. Wir implementieren dazu eine Bundle-Definition und einen HelloController:

src/Application/HelloBundle/HelloBundle.php

<?php

namespace ApplicationHelloBundle;

use SymfonyComponentHttpKernelBundleBundle;

class HelloBundle extends Bundle
{
}

src/Application/HelloBundle/Controller:

<?php

namespace ApplicationHelloBundleController;

use SymfonyBundleFrameworkBundleControllerController;

class HelloController extends Controller
{
    public function indexAction($name)
    {
        return $this->render('HelloBundle:Hello:index.twig', array('name' => $name));

        // render a PHP template instead
        // return $this->render('HelloBundle:Hello:index.php', array('name' => $name));
    }
}

und die zugehörige View:

{% extends "HelloBundle::layout.twig" %}

{% block content %}
    Hello {{ name }}!
{% endblock %}

Nun müssen wir nur noch die im Template referenzierte Layout-Datei anlegen:

src/Application/HelloBundle/Resources/views/layout.twig:

{% extends "::layout.twig" %}

{% block body %}
    <h1>Hello Application</h1>

    {% block content %}{% endblock %}
{% endblock %}

Und wiederum die in diesem Bundle-spezifischen Layout-Template referenzierte “globale” Layout-Datei – stilsicher mit HTML5-Doctype:

app/views/layout.twig:

<!DOCTYPE html>
<html>
    <head>
        <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
        <title>{% block title %}Hello Application{% endblock %}</title>
    </head>
    <body>
        {% block body %}{% endblock %}
    </body>
</html>

Das wars. Man sollte nun im Browser zwei Seiten sehen können, einmal die Standard-Projekt-Route “/” auf FrameworkBundle:Default:index gemapped und die Route /hello/:name auf HelloBundle:Hello:index gemapped. Zu beachten ist hierbei das Namespace-Mapping auf die Pfade, die im AppKernel unter registerBundleDirs() angegeben wurden – zum besseren Verständis der Namensraumauflösung der Routen sowie der Templates.

Abschließend kann man sich noch eine Symfony-Konsolenanwendung nach /app legen:

app/console

#!/usr/bin/env php
<?php
require_once __DIR__.'/AppKernel.php';
use SymfonyBundleFrameworkBundleConsoleApplication;
$kernel = new AppKernel('dev', true);
$application = new Application($kernel);
$application->run();

nach einem

$ chmod + x app/console

kann man nun via ./app/console folgende Ausgabe bewundern und sich mit den ersten Symfony-Bundle-Tasks vertraut machen:

$ app/console
Symfony version 2.0.0-DEV - app

Usage:
  [options] command [arguments]

Options:
  --help           -h Display this help message.
  --quiet          -q Do not output any message.
  --verbose        -v Increase verbosity of messages.
  --version        -V Display this program version.
  --ansi           -a Force ANSI output.
  --no-interaction -n Do not ask any interactive question.
  --shell          -s Launch the shell.

Available commands:
  help                         Displays help for a command (?)
  list                         Lists commands
assets
  :install                     
doctrine
  :ensure-production-settings  Verify that Doctrine is properly configured for a production environment.
doctrine:cache
  :clear-metadata              Clear all metadata cache for a entity manager.
  :clear-query                 Clear all query cache for a entity manager.
  :clear-result                Clear result cache for a entity manager.
doctrine:data
  :load                        Load data fixtures to your database.
doctrine:database
  :create                      Create the configured databases.
  :drop                        Drop the configured databases.
doctrine:generate
  :entities                    Generate entity classes and method stubs from your mapping information.
  :entity                      Generate a new Doctrine entity inside a bundle.
  :proxies                     Generates proxy classes for entity classes.
  :repositories                Generate repository classes from your mapping information.
doctrine:mapping
  :convert                     Convert mapping information between supported formats.
  :convert-d1-schema           Convert a Doctrine 1 schema to Doctrine 2 mapping files.
  :import                      Import mapping information from an existing database.
doctrine:query
  :dql                         Executes arbitrary DQL directly from the command line.
  :sql                         Executes arbitrary SQL directly from the command line.
doctrine:schema
  :create                      Processes the schema and either create it directly on EntityManager Storage Connection or generate the SQL output.
  :drop                        Drop the complete database schema of EntityManager Storage Connection or generate the corresponding SQL output.
  :update                      Processes the schema and either update the database schema of EntityManager Storage Connection or generate the SQL output.
init
  :bundle                      
router
  :debug                       Displays current routes for an application
  :dump-apache                 Dumps all routes as Apache rewrite rules

Heute möchte ich einen alternativen, vielleicht pragmatischeren Ansatz als der andererer populärer Implementierungenn herbeispinnen, um Dependency Injection (DI) in PHP 5.3 zu realisieren.

Für diverse Programmiersprachen gibt es – auf den jeweiligen Anwendungsbereich mehr oder weniger spezialisierte – sogenannte Dependency-Injection (DI)-Container. Der DI-Container als solcher dient im Grunde als Manager oder Konfigurator, der das Zusammenspiel unserer Abhängigkeiten definiert – meist auf Grundlage einer Konfigurationsdatei, die bspw. in XML vorliegt:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd">

  <bean id="..." class="...">
    <!-- collaborators and configuration for this bean go here -->
  </bean>

  <bean id="..." class="...">
    <!-- collaborators and configuration for this bean go here -->
  </bean>

  <!-- more bean definitions go here... -->

</beans>

(Quelle: Springsource)

Eine weitere Möglichkeit Abhängigkeiten zu definieren, bietet das Convention Over Configuration-Paradigma: Heißt bspw. eine Member-Variable “Mailservice”, so kann der zugrundeliegende DI-Container entsprechend konfiguriert werden, sodass bei Instanziierung automatisch eine Klasse gleichen Namens (Mailservice) instanziiert und an das Objekt gebunden wird (so macht’s bspw. Grails in seinen MVC-Controller-Instanzen, wobei hier natürlich wieder das Spring IoC (Das hat nichts mit dem internationalen olympischen Komitee zu tun, sondern ist die Abkürzung für “Inversion of Control” und steht gleichbedeutend für “Dependency Injection”). Diese Implementierung erfordert natürlich ausgereifte Introspektionsmechanismen der zugrundeliegenden Programmiersprache (Stichwort “Reflection“), außerdem muss man dem DI bzw. IOC-Container vorher beigebracht haben, welche Klassen oder Verzeichnisstrukturen überhaupt durchsucht und unter “DI-Kontrolle” gestellt werden müssen – ein zusätzlicher Programmieraufwand ist also immer noch gegeben. Unvorhersehbarkeiten im Code und eine erhöhte WTF’s/min-Rate kommen dabei frei Haus.

PHP bieted zu dem ganzen Thema ab Werk erstmal – nix. Die Reflection-API ist aber schonmal ein ausgereiftes Werkzeug, um definierte Abhängigkeiten auszuwerten. Das allerdings ausschließlich mittels lesendem Zugriff auf Metadaten von bspw. Klassen, Methoden oder auch System- bzw. benutzerdefinierten Funktionen. Schreibende Operationen sind im Sprachkern erst einmal nicht vorgesehen. Es ist also prinzipiell möglich, zur Laufzeit Abhängigkeiten durch Konvention zu definieren, die Auflösung selbiger ist aber “mit Boardmitteln” nicht zu realisieren.

Ein eigenes Sprachkonstrukt wie Mixins ist auch (noch) nicht implementiert, und anonyme (“Lambda“)-Funktionen lassen sich nicht wie in Javascript oder auch Groovy direkt an den Objekt-Prototypen hängen oder auch an einzelne Instanzen, sondern müssen mühsam “by reference” gezogen und dann erst ausgewertet werden.

Javascript:

  var foo = function() { }
  foo.prototype.bar = function() { return "bar"; }
  foo.baz = foo.prototype.bar;

  var foobar = new foo;
  foo.bar(); // -> "bar"
  foo.baz(); // -> "bar"

PHP:

  $foo = new stdClass();
  $foo->bar = function() 
  {
    return "bar";
  }
  $foo->bar(); // method not found
   
  $bar = $foo->bar;
  $bar(); // -> "bar"

Zugegeben: Gäbe es bereits Mixins oder Prototypen im PHP-Kontext, wäre die Implementierung eines DI-Containers wohl eher unspannend, mindestens aber überflüssig. Dennoch fehlt eine zuverlässige Möglichkeit, PHP-Instanzen zur Laufzeit mit neuen Methoden anreichern zu können. Daher gehen die meisten PHP-DI-Frameworks immer den Weg über einen recht aufgeblähten DI-Container. Dieser macht aber im Grunde nichts anderes, als Referenzen zu verwalten. Der Container selbst wird dann an die anzureichernde Instanz gebunden, im Idealfall eventuell aber noch via magischer Methode __call() verborgen. Dann aber muss die zu aufnehmende Instanz wiederum mindestens ein Interface “Injectable” o.Ä. implementieren. Letzlich aber passiert am Ende immer folgendes:

class myController extends Controller
{
  public function indexAction(HttpRequest $request)
  {
    $db = $this->getService('Database');
  }
}

Der Service-Container übernimmt also die klassische Aufgabe des “ApplicationContext”: Er managed Referenzen, rückt diese aber erst “on demand” heraus. Meiner Meinung hat man dabei nicht allzu viel gewonnen, vor allem, wenn das obige Codeschnippsel noch eine Menge Konfiguration, Code zum Bootstrappen des DI-Containers und/oder Caching voraussetzt.

Ich persönlich würde mir dann doch eher “ganz oldschool” ein paar getter/setter zusätzlich schreiben und mich einfach darauf verlassen, dass der gute, alte ApplicationContext sowieso (fast) alles enthält, was ich brauch’, mit der Konsequenz, dass dieser eben nicht gerade leichtgewichtig ist.

Wozu also das ganze?

Ein alternativer DI-Container mit Doctrine 2 Annotations und Runkit

Die Annotations-Implementierung von Doctrine 2 ist einfach und mächtig genug, um eine beliebigen Klasse mit Metainformationen auszustatten, die die zu injizierenden Abhängigkeiten definieren. Runkit ermöglicht es, auf Basis dieser Metadaten Abhänigkeiten an das ensprechende Objekt zu binden – zur Laufzeit und ohne zusätzliche Implementierung von Schnittstellen o.Ä. Vom Prinzip her sollte es also möglich sein, eine Klasse zu schreiben, diese zu annotieren und dann bei Instanziierung automatisch alle gewünschten Abhängigkeiten zur Verfügung stehen zu haben. Ein Codebeispiel:

index.php:

  require __DIR__ . '/lib/vendor/doctrine-common/lib/Doctrine/Common/ClassLoader.php';

  use DoctrineCommonClassLoader;
  
  $classLoader = new ClassLoader('DoctrineCommon', __DIR__ . '/lib/vendor/doctrine-common/lib');
  $classLoader->register();

  $classLoader = new ClassLoader('deifschleife', __DIR__ . '/lib');
  $classLoader->register();

  // INITIALISIERUNG DES DI-CONTAINERS
  $di_container = new deifschleifediContainer;
  
  $di_container->setClassnames(array(
    'deifschleifeDITest'
  ));
  
  // "AUFNEHMENDE" KLASSE
  $test = new deifschleifeDITest();

  // GEHÖRT deifschleifeADependency
  echo $test->foo();
  
  // GEHÖRT deifschleifeAnotherDependency
  echo $test->bar();

  // GEHÖRT deifschleifeYetAnotherDependency
  echo $test->baz();
  
  // GIBT's NICHT, ÜBER __call() ABGEFANGEN
  echo $test->methodThatDoesNotExist();

Kurz erklärt:

$di_container = new deifschleifediContainer;
$di_container->setClassnames(array(
    'deifschleifeDITest'
  ));

Instanziiert den DI-Container und stellt eine Klasse (deifschleifeDITest) unter seine “Kontrolle”.

$test = new deifschleifeDITest();

  // GEHÖRT deifschleifeADependency
  echo $test->foo();
  
  // GEHÖRT deifschleifeAnotherDependency
  echo $test->bar();

  // GEHÖRT deifschleifeYetAnotherDependency
  echo $test->baz();
  
  // GIBT's NICHT, ÜBER __call() ABGEFANGEN
  echo $test->methodThatDoesNotExist();

Instanziiert die überwachte Klasse deifschleifeDITest und ruft einige Methoden auf, die sämtlich aus anderen Klassen nach DITest injiziert wurden. Die letze Methode ist nirgends existent. deifschleifeDITest implementiert ausschließlich __call(), ansonsten ist die Klasse (fast) leer:

<?php
namespace deifschleife;

/**
 * @Services({
 *   @Service(
 *    class="deifschleifeADependency",
 *    constructorArgs={
 *      "pong"
 *    }
 *  ),
 *  @Service(
 *    class="deifschleifeAnotherDependency",
 *    constructor={"deifschleifeAnotherDependency", "getAnotherDependency"}
 *  ),
 *  @Service(
 *    class="deifschleifeYetAnotherDependency",
 *    constructor="makeYetAnotherDependency"
 *  )
 * })
 */
class DITest
{
  public function __call($method, $args)
  {
    return sprintf("Called __call, Method: %s, Args: %s", $method . '()', implode(', ', $args));
  }

  public function makeYetAnotherDependency()
  {
    return new YetAnotherDependency();
  }
}

Interessant sind die Klassen-Annotationen ganz oben: @Services teilt dem Doctrine 2 Annotation Parser mit, dass hier eine Reihe von PHP-Klassen, die zu injizierende Methoden enthalten, zusammenzusuchen sind. Jeder einzelne @Service in der Liste kann noch grob konfiguriert werden, so kann bspw. eine eigene Factory-Methode für jede Dependency angegeben werden.

Die einzelnen Dependencies sind “ganz normale” PHP-Klassen. Intern passiert folgendes: Die Runkit-Erweiterung dient dazu, über runkit_method_add() “on the fly” eine magische Methode __call() an die mit zusätzlcihen Methoden anzureichernde Klasse deifschleifeDITest zu binden. Existiert bereits eine entsprechende Methode __call(), wird diese intern via runkit_method_rename() umbenannt und am Ende von __call() (neu) aufgerufen. Das bedingt natürlich eine gewisse Rücksichtname bei zusätzlicher Verwendung von __call().

Die Idee unterscheidet sch also nur unwesentlich von bereits vorhandenen Konzepten, spart aber einige Schritte ein:

1.) Man benötigt keine Abstrakte Klasse und/oder Interface, die dass die getService()-Logik bereitstellt.
2.) Man benötigt kaum zusätzliche Konfigurationsaufwand – eine einfache Annotation im PHPDOc-Comment-Format reicht aus (es spricht allerdings nichts dagegen, je nach Gschmäckle einen Config-Adapter dazwischen zu schieben, der das Mapping via XML oder bspw. Yaml erlaubt)
3.) Man kann auf Proxy-Instanzen verzichten, die __call() transparent bereitstellen.

Fazit: Es ist prinzipiell möglich, Dependency Injection – passender noch “Mixins” – mit PHP zu realisieren, ohne nennenswert viel Codeoverhead zu produzieren.

Allerdings muss man berücksichtigen, dass Runkit eine experimentelle Erweiterung ist, deren Zuverlässigkeit in komplexen Projekten nicht vorauszusehen ist. Außerdem wird es sehr wahrscheinlich in Bälde ein mächtiges, neues Sprachkonstrukt geben, das Mixins ermöglicht (siehe RFC zu Traits). Und natürlich kann ich mir auch totalen Murks zusammen gereimt haben, denn sicherlich sind die existierenden Implementierungen von fähigeren Architekten entworfen worden und haben bestimmt ihre Daseinsberechtigungen in einem Kontext, den ich vielleicht einfach noch nicht erfasst haben. Comments dazu wären wir sehr willkommen!

Ausblick

Die Lösung zentral über __call() ist die Schnelle, aber nicht optimale. Vorstellbar ist eine injizierung sämtlicher öffentlicher Methoden wie runkit_method_add, und ein globaler Accessor, der die Objektinstanz der Abhängigkeit liefert. Das ganze könnte man (optional) konfigurierbar gestalten (über Doctrine 2 Annotationen), um eventuellen Namenskonflikten auszuweichen.

Test-Sourcen

Die PHP-Quelltexte zu den obigen Beispielen kann man hier herunterladen:
http://ifschleife.de/dependency_injection.tar.gz

Ich habe die DoctrineCommon-Package bereits beigelegt, das Beispiel sollte also unter PHP5.3 funktionieren (bitte di.php aufrufen, der Rest ist noch durchsetzt mit Doctrine 2 Testklamotten).

Eine Anleitung, wie man Runkit unter php5.3 zum laufen kriegt, gibt es hier (Japanisch, aber der Quelltext ist auf PHP ;))

Die Test-Sourcen liegen, wie in den obigen Codebeispielen beschrieben, unter lib/de/ifschleife. Ich möchte betonen, dass das nur eine Art Fallstudie ist, ich wäre aber über jeden Kommentar erfreut, der mir widerlegt oder bestätigt, ob man den programmatischen Ansatz vielleicht weiterverfolgen sollte.

Vielen Dank für die Aufmerksamkeit! :)

Also anstatt zu schreiben:

class DefaultController {
  
  def mySuperService
  
  def index = {
   mySuperService = new MySuperService(params);
   mySuperService.getData()
  }
}

schreibe ich einfach

class DefaultController {
 
  def mySuperService
 
  def index = {
   mySuperService.getData()
  }
}

Gut, sieht jetzt nicht besonders spektakulär aus, doch wenn man weiß, dass mySuperService im Hintergrund (Stichwort “Spring Managed Bean”) automatisch instanziiert sowie an meinen Controller gebunden wurde und dass da prinzipiell noch viel mehr geht, ist das bereits ein ganz brauchbares Feature.

Natürlich ist die Injizierung per Naming-convention eine Grails-eigene Lösung (alles, was auf Service endet, ist ein Service und wird injiziert), um Konfigurationsarbeit zu sparen. Für gewöhnlich wird das Verhalten sogenanner “managed Beans” natürlich konfiguriert, entweder Java-typisch via XML-Konfigurationsdatei oder durch Annotationen.

Dabei kann wiederum java-typisch auch der “Scope” einer Bean bestimmt werden; hier bringt vor allem der “Singleton” bzw. Application Scope einen Vorteil gegenüber einer statuslosen PHP-Anwendung. Doch bereits die Fähigkeit, den Scope überhaupt fein granulieren zu können, setzt das ganze wieder von PHP-Gemurkse ala $_SESSION, $_REQUEST etc. ab.

Also egal wo und in welchem Kontext man Managed Beans, Enterprise Java Beans, Spring Beans (Die Unterschiede interessieren hier mal nicht die Bohne – ich könnte sie auch gar nicht qualifiziert erläutern) einsetzt – das IoC-Muster spart Code, vereinfacht Abhängigkeiten und sorgt für schlankere Konstruktoren – ist insgesamt also eine sehr mächtige Sache.

Was aber nicht heißt, dass so etwas generell nicht auch in meiner PHP-Anwendung funktionieren kann.

sfDependencyInjectionContainerPlugin

Dieses Plugin (http://www.symfony-project.org/plugins/sfDependencyInjectionContainerPlugin) leistet genau das: Es verwaltet entweder über eine in PHP formulierte DSL(hust), über XML oder eine symfony-typische .yml-Datei konfigurierte Abhängigkeiten. Das Plugin ist selbst nur ein Adapter, das die Symfony-Komponente DependencyInjection in ein Symfony 1.2 (und höher) Projekt integriert – in Symfony 2.0 wird DependencyInjection voraussichtlich Bestandteil des Systemkerns sein.

Zur Installation und Konfiguration des Plugins verweise ich auf die README-Datei. Trotzdem vielleicht der Hinweis, dass die Bibliotheken mit einem eigenen Autoloader daherkommen, daher empfehle ich, folgende Programm-Zeilen in eure ProjectConfiguration.class.php hinzuzufügen:

config/projectConfiguration.class.php

  require_once dirname(__FILE__) . '/../pfad/zur/DependencyInjection/Komponente/sfServiceContainerAutoloader.php';
  sfServiceContainerAutoloader::register();

Anders habe ich es nicht hinbekommen, zwar lässt sich durch eine config/autoload.yml die Laufzeit von Class Not Found-Fehlern befreien, aber das Symfony Command Line Interface geht dann trotzdem hops. Für einen Tipp, wie man’s eleganter hinkriegt, wäre ich dankbar.

Beispielsweise möchte ich den Nerdpress-RSS-Feed in meine Seite einbinden. Dazu baue ich einen Proxy, um bequem via AJAX auf das entfernte RSS-XML zugreifen zu können.
Diesen Proxy definiere ich als Service und injiziere ihn meine Symfony-Module:

config/services.yml:

services:
  NerdpressRssProxy:
    class: NerdpressRssProxy

Diese drei Zeilen reichen bereits aus, um meine Abhängigkeit zu definieren.

Nun implementiere ich die Service-Klasse:

lib/NerdpressRssProxy.php

class NerdpressRssProxy
{
  /**
   * @var sfFileCache
   */
  protected $cache;

  /**
   * @return sfFileCache
   */
  public function getCache()
  {
    if (null === $this->cache)
    {
      $this->cache = new sfFileCache(array('cache_dir' => sfConfig::get('sf_cache_dir')));
    }
    return $this->cache;
  }

  /**
   * @return string
   * @throws Exception
   */
  public function getEntries()
  {
    $cache = $this->getCache();

    sfContext::getInstance()->getConfiguration()->loadHelpers(array('Helper', 'Tag', 'Url', 'Text'));

    if(!($rss = $cache->get('nerdpress_rss')))
    {
      if(($rss = @file_get_contents('https://nerdpress.org/feed')))
      {
        $rss = auto_link_text($rss, 'all', array('class' => 'external'));

        $cache->set('nerdpress_rss', $rss, 3600);
      }
      else
      {
        throw new Exception('Rss feed could not be opened');
      }
    }
    return $rss;
  }
}

Die Methode getEntries() rufe ich nun in meinem Nerdpress-RSS-Modul auf, um die WebResponse zu befüllen:

apps/frontend/modules/rssProxy/actions/actions.class.php

class rssProxyActions extends sfActions
{
  public function preExecute()
  {
    $this->getResponse()->setContentType('application/rss+xml');
  }
  
  public function executeNerdpress(sfWebRequest $request)
  {
    try
    {
      // SERVICE HOLEN UND getEntries() AUFRUFEN
      $rss = $this->getService('NerdpressRssProxy')->getEntries();

      $this->getResponse()->setHttpHeader('Content-Length', mb_strlen($rss));
      $this->getResponse()->setContent($rss);
    }
    catch(Exception $e)
    {
      $this->forward404($e->getMessage());
    }
    return sfView::NONE;
  }
}

Das wars. Einfach, oder? Ingesamt 3 Zeilen yml-Konfiguration reichen, um Dependency Injection “the PHP way” zu realisieren, Symfony sei Dank. Natürlich ist nicht *ganz* so hübsch wie in der J2EE-Welt und sicherlich funktional noch weit davon entfernt. Aber ein Anfang ist gemacht, und wenn man seine Services erst einmal auf diese Art und Weise unter Kontrolle bringt, ist man vom Nutzen der Sache schnell überzeugt: Mit ein bisschen Disziplin gehören “Controller-Spaghettiwürste” nämlich der Vergangenheit an.

Bitte entschuldigt eventuell fehlerhafte oder unsaubere Beschreibungen der Begriffe “Bean”, “IoC”, JSF2 etc. Ich bitte explizit um Korrektur in Form von Kommentaren :)