I still did not get the point regarding dependency resolution, so i simply “composed” the composer file by writing down my own requirements (“i want only the hottest, newest stuff!!”, then tracked down the error messages, removing them by explicetly writing down the missing dependencies by using the latest “dev-*” versions. After that i tried to run the project, which actually did not work, but selective downgrade of some of the bundles (framework, security-extra blahblah) finally did the job.

Feel free to use it in your own projects:

{
	"require" : {
              "symfony/symfony" : "v2.0.12",
              "doctrine/common" : "2.1.4",
              "doctrine/orm" : "2.1.6",
              "symfony/finder" : "v2.0.12",

              "symfony/assetic-bundle" : "2.0-dev",
              "twig/extensions" : "dev-master",
              "jms/security-extra-bundle" : "1.1.0",
              "sensio/framework-extra-bundle" : "2.0-dev",
              "sensio/distribution-bundle" : "2.0-dev",
              "sensio/generator-bundle" : "2.0-dev"

 	},
        "autoload" : {
            "psr-0" : {
                "Acme" : "src/",
            }
        }
}

Create a file named “composer.json” in your project’s root directory, then paste the above code into it and save it.

Now run

$ curl -s http://getcomposer.org/installer | php

After that, download all dependencies by typing

$ php composer.phar install

The easiest way to create a full project including AcmeDemoBundle, AppKernel and the whole stuff is to download the symfony 2 standard distribution without vendors and calling the script from there. The only thing to do is to modify the path to autoload.php, which should point to vendor/.composer/autoload.php.

Now you are able to upgrade your project’s dependencies to the newest versions by simply modifying the composer.json file. Have fun!.

Actually its like in PHP:

{{ 11 % 7 }}

As described here

But i guess for most use cases modulus is used to check if a number is divisible by another number.
Therefore Twig has the very conveniant divisible by test function.

{% if loop.index is divisible by(3) %}

Another modulo use case is to check odd and even rows in loops. There Twig has the built-in function cycle to help you.

{{ cycle(['odd', 'even'], i) }}

Once you know its so eeasy;)

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.

A few weeks ago i described how to hook into the form login process in order to change the user session´s locale.

In the meantime a non backwards compatible code modification has been introduced that outdated this article. From now on (Symfony 2.0.4) the locale and default locale settings are maintained within the request object (and not as used to be in the session).

So, here is a little update – under reserve – because the locale setting´s logic will probably change again in the future.

At first, the new locale maintenance code by using a LocaleListener is still buggy. Specially this issue breaks the whole thing atm: https://github.com/symfony/symfony/issues/2386

A quick workaround is to change the priority of the listener from 255 to let´s say 127. That forces the SessionListener to initialize the session right BEFORE the locale listener, so that $request->hasPreviousSession() has actually the chance to return TRUE.

Change Symfony\Component\HttpKernel\EventListener\LocaleListener, L. 69

KernelEvents::REQUEST => array(array('onEarlyKernelRequest', 255), array('onKernelRequest', -1)),

to

KernelEvents::REQUEST => array(array('onEarlyKernelRequest', 127), array('onKernelRequest', -1)),

Hopefully a patch will be available soon to fix the problem – source code modifications in this way are things YOU MUST NOT DO!

For now and demonstration purposes only, this will fit. After that, it´s easy to modify our previously elaborated source code to fit the new circumstances:

Change our listener from:

class EventListener
{
    public function onSecurityInteractiveLogin(InteractiveLoginEvent $event)
    {
        $token = $event->getAuthenticationToken();
        $session = $event->getRequest()->getSession();
        $session->setLocale($token->getUser()->getLocale());
    }
}

into:

class EventListener
{
    public function onSecurityInteractiveLogin(InteractiveLoginEvent $event)
    {
        $token = $event->getAuthenticationToken();
         
        $request = $event->getRequest();
        $session = $request->getSession();

        $locale = $token->getUser()->getLocale();
        $session->set('_locale', $locale);
        $request->setLocale($locale);
    }
}

I am still not sure if this is the best solution to the problem – hopefully the new implementation will be well documented in the future or changed in a way the produces less WTFs …

Any comments appreciated.

    Symfony\Component\Security\Core\SecurityContext|void         getSecurity()
    Symfony\Component\Security\Core\User\(Advanced)UserInterface getUser()
    Symfony\Component\HttpFoundation\Request|void                getRequest()
    Symfony\Component\HttpFoundation\Session|void                getSession()
    string                                                       getEnvironment()
    bool                                                         getDebug()

In Twig liegt der Container im “app”-Namespace, “Übersetzt” nach Twig heißt das ganze also:

    app.security
    app.user
    app.request
    app.session
    app.environment
    app.debug

Viel Spaß beim Templates-Bauen ;)

Also node.js via macports holen:

$ sudo port install nodejs

Und den node.js-eigenen Package-Manager:

$ sudo port install npm

Mit diesem installieren wir als nächsts less, und zwar “global” (via -g)-Flag (“global” bedeutet, dass das Modul unter $nodejs_lib_path/../node_modules abgelegt wird, ansonsten wird es im aktuellen Arbeitsverzeichnis unter ./node_modules installiert):

$ sudo npm install -g less

Damit haben wir alles, um unsere less CSS Stylesheets kompilieren zu können.

Als nächstes holen wir uns den Yui-Kompressor, diesen habe ich mir einfach aus dem Netz gezogen und unter app/java/yuicompressor-2.4.6.jar abgelegt (Die Binary findet ihr unter http://developer.yahoo.com/yui/compressor/).

Nun die Konfiguration:

app/config.yml:

# Assetic Configuration
assetic:
    debug:          %kernel.debug%
    use_controller: false
    filters:
        cssrewrite: ~
        less:
          node: /opt/local/bin/node
          node_paths: [/opt/local/lib/node, /opt/local/lib/node_modules]
        yui_css:
          jar: %kernel.root_dir%/java/yuicompressor-2.4.6.jar

Zu beachten sind die “node_paths”. Der node.js-Modulpfad muss explizit angegeben werden, sonst kann node.js die require()-Statements nicht auflösen (das sind sozusagen die node.js-“Classpaths”). /opt/local/lib/node zeigt auf Core-Module, in /opt/local/lib/node_modules liegt unser less.

Um den Yui-Kompressor zu aktivieren, reicht der simple Pfad zur .jar-Datei.

Nun müssen wir nur noch unser Twig-Layout anpassen:

src/Nerdpress/DemoBundle/Resources/views/layout.html.twig:

<!DOCTYPE html>
<html>
    <head>
        <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
        {% stylesheets
                '@NerdpressDemoBundle/Resources/public/css/main.css'
                '@NerdpressDemoBundle/Resources/public/css/layout.css'
        	filter='less,?yui_css'
                combine=true
        %}
          <link rel="stylesheet" href="{{ asset_url }}" type="text/css" media="all" />
        {% endstylesheets %}

Das “?” vor dem Filter “yui_css” bedingt, dass die CSS-Compression nur angeschaltet wird, wenn der Debug-Parameter auf false steht. “Combine” bedeutet, dass alle CSS-Dateien in einer einzigen, großen Datei zusammengefügt werden, und “less” bedeutet letztlich, dass alle CSS-Dateien mittels less CSS precompiled werden.

That´s it. Die Seite im Browser öffnen und das Ergebnis bewundern. Viel Spaß! Symfony ist schon was feines…

Das Security Bundle ist ein wenig magisch. Da muss man eine HTML-Form definieren, der Rest wird irgendwie konfiguriert (Namen der Post-Parameter wie “_username”, “_password” etc., den Redirect zum Referrer, Remember-Me Funktion und so weiter, das alles wird von der Firewall intern geregelt. Man muss nur eine Login-Route definieren, einen Stub-Controller + Action-Callable (der aber nie ausgeführt wird, weil die Firefall sich davorhängt), fertig.

Das ist angenehm einfach, solange man keine Fragen stellt. Aber wie führe ich zusätzliche Aktionen direkt nach erfolgtem Login aus, ohne Einfuss auf den Code des Security Bundles zu haben?

Meist sucht man dazu einen Hook, Einstiegspunkt oder eine Konfigurationsvariable. In Symfony 2 sucht man natürlich Events, doch die Doku schweigt sich hierzu noch ein wenig aus, also wieder ‘rein in den Sourcecode. Irgendwo muss doch eine Möglichkeit zu finden sein, und tatsächlich, im AbstractAuthentificationListener werden wir fündig:

vendorsymfonysrcSymfonyComponentSecurityHttpFirewallAbstractAuthentificationListener.php

namespace SymfonyComponentSecurityHttpFirewall;

//...

abstract class AbstractAuthenticationListener implements ListenerInterface
{
    // ...
    private function onSuccess(GetResponseEvent $event, Request $request, TokenInterface $token)
    {
        if (null !== $this->logger) {
            $this->logger->info(sprintf('User "%s" has been authenticated successfully', $token->getUsername()));
        }

        $this->securityContext->setToken($token);

        $session = $request->getSession();
        $session->remove(SecurityContextInterface::AUTHENTICATION_ERROR);
        $session->remove(SecurityContextInterface::LAST_USERNAME);

        if (null !== $this->dispatcher) {
            $loginEvent = new InteractiveLoginEvent($request, $token);
            $this->dispatcher->dispatch(SecurityEvents::INTERACTIVE_LOGIN, $loginEvent);
        }

        if (null !== $this->successHandler) {
            $response = $this->successHandler->onAuthenticationSuccess($request, $token);
        } else {
            $response = $this->httpUtils->createRedirectResponse($request, $this->determineTargetUrl($request));
        }

        if (null !== $this->rememberMeServices) {
            $this->rememberMeServices->loginSuccess($request, $response, $token);
        }

        return $response;
    }

Die Klasse ist nur auszugsweise abgedruckt. Interessant sind die Zeilen 233 & 238 im Original-Sourcecode.

Zeile 233 ff. benachrichtigt alle Eventlistener, die auf SecurityEvents::INTERACTIVE_LOGIN hören, wenn ein Event-Dispatcher vorhanden ist (im Falle der Symfony Standard Distribution kann man das voraussetzen).

Zeile 238 ist eine Sonderlocke, sozusagen ein “Security-Bundle-eigenes” Event. Man hat die Möglichkeit, in der jeweiligen Firewall-Einstellung für den Form-Login in der security.yml mit success_handler einen eigenen DIC-Service anzugeben, der SymfonyComponentSecurityHttpAuthenticationAuthenticationSuccessHandlerInterface implementiert.

Das sieht dann in etwa so aus:

      secured_area:
            pattern:    ^/demo/secured/
            form_login:
                check_path: /demo/secured/login_check
                login_path: /demo/secured/login
                success_handler: dvlp_core.login_success_handler

Die Implementierung der Callback-Methode onAuthenticationSuccess(Request $request, TokenInterface $token) des Interfaces ist aber nicht ganz trivial, da als Rückgabewert eben eine Instanz von SymfonyComponentHttpFoundationResponse erwartet wird, die man dann selbsttätig konfigurieren muss (inkl. Rücksprung-Adresse, Referer-Logik und Auswertung der Benutzerkonfiguration). Daher lassen wir das erstmal sein und nutzen den Event-Dispatcher, um uns in den Login hineinzukrallen. Dazu definieren wir einen neuen Service in einem unserer Bundles und taggen ihn als Eventlistener:

Resourcesconfigservices.xml:

    <parameters>
        <parameter key="dvlp_core.event_listener.class">DvlpCoreBundleEventListener</parameter>
    </parameters>
    <service id="dvlp_core.event_listener" class="%dvlp_core.event_listener.class%">
        <tag name="kernel.event_listener" event="security.interactive_login" method="onSecurityInteractiveLogin" />
    </service>

Dann implementieren wir den Listener. Dieser Listener soll die Session-Locale “on login” auf die Lokalisierungs-Einstellung des aktuellen (Datenbank-)-Users setzen.

DvlpCoreBundleEventListener.php:

class EventListener
{
    public function onSecurityInteractiveLogin(InteractiveLoginEvent $event)
    {
        $token = $event->getAuthenticationToken();
        $session = $event->getRequest()->getSession();
        $session->setLocale($token->getUser()->getLocale());
    }
}

Das war´s auch schon. Events to the Rescue. Leider scheinen diese wirklich noch nicht allzu ausführlich dokumentiert zu sein, ich wäre froh, wenn mir jemand das Gegenteil aufzeigen kann!

Viel Spaß beim Ausprobieren.

Schaut man sich den generischen EntityUserProvider an, so sieht man ab Zeile 46 sowas wie

    /**
     * {@inheritdoc}
     */
    public function loadUserByUsername($username)
    {
        if (null !== $this->property) {
            $user = $this->repository->findOneBy(array($this->property => $username));
        } else {
            if (!$this->repository instanceof UserProviderInterface) {
                throw new InvalidArgumentException(sprintf('The Doctrine repository "%s" must implement UserProviderInterface.', get_class($this->repository)));
            }

            $user = $this->repository->loadUserByUsername($username);
        }

        if (null === $user) {
            throw new UsernameNotFoundException(sprintf('User "%s" not found.', $username));
        }

        return $user;
    }

Dieser Code besagt, dass nur dann, wenn die Konfigurationeinstellung “property” aus der security.yml entfernt wird (steht üblicherweise auf “username” und gibt das Datenbankattribut an, das eben den Benutzernamen hält), das entsprechende Doctrine-Entity “User” auch eine Repository-Class hat und diese darüber hinaus UserProviderInterface implementiert, man seine eigene loadUserByUsername()-Methode implementieren kann, die dann von der Firewall zur Identifizierung des Benutzer beim Login herangezogen wird (dieser Vorgang ist komplett intransparent, Symfony Magic).

Also aus seiner “alten” security.yml

    providers:
        default:
            users:
                user:  { password: userpass, roles: [ 'ROLE_USER' ] }
                admin: { password: adminpass, roles: [ 'ROLE_ADMIN' ] }
            entity: { class: DvlpCoreBundleEntityUser, property: username }

sowas machen:

     ...
            entity: { class: DvlpCoreBundleEntityUser }

Dann muss das zu User gehörtige UserRepository nur noch UserProviderInterface implementieren, bspw. so:

<?php

namespace DvlpCoreBundleEntity;

use DoctrineORMEntityRepository;
use SymfonyComponentSecurityCoreUserUserProviderInterface;
use SymfonyComponentSecurityCoreUserUserInterface;

/**
 * UserRepository
 *
 * This class was generated by the Doctrine ORM. Add your own custom
 * repository methods below.
 */
class UserRepository extends EntityRepository implements UserProviderInterface
{
    /**
     * {@inheritdoc}
     */
    public function loadUserByUsername($username)
    {
        return $this->getEntityManager()
            ->createQuery('SELECT u FROM DvlpCoreBundle:User u JOIN u.Profile p WHERE u.username = :username OR p.email = :username')
            ->setParameters(array(
                'username' => $username
            ))
            ->getOneOrNullResult();
    }

    /**
     * {@inheritDoc}
     */
    public function refreshUser(UserInterface $user)
    {
        return $this->loadUserByUsername($user->getUsername());
    }

    /**
     * {@inheritDoc}
     */
    public function supportsClass($class)
    {
        // NEVER CALLED ...
        return $class === 'DvlpCoreBundleEntityUser';
    }
}
}

Schon kann man als Benutzernamen entweder den Username oder die E-Mail-Adresse des Users angeben.

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…

Als zukünftige Ausgaben denkbar sind ein Symfony2-basierendes CMF (Content Management Framework) oder eine auf die speziellen Befürfnisse von Online-Shops zugeschnittene Bundle-Sammlung.

Der Code ist noch nicht als stabil deklariert. Die bereits vorhandene und wie immer intensiv gepflegte Referenz-Dokumentation lädt bereits jetzt zum Reinschnuppern und Ausprobieren ein.