Im generierten Partial _form_field wird das aktuelle Form Objekt mit in das konfigurierte Partial gegeben:

include_partial('cmAdvertAdmin/'.$name, array('form' => $form, 'attributes' => $attributes instanceof sfOutputEscaper ? $attributes->getRawValue() : $attributes));

Über dieses Form-Objekt kommt man dann auch wieder an das aktuelle Objekt und alles funktioniert, ganz ohne das Überschreiben von generierten Dateien oder Umwegen. Im Partial also:

$form->getObject()->getValue();

In letzter Zeit war immer TYPO3 das mittel der Wahl und meine praktischen Erfahrungen im Bezug auf Symfony2 damit leider gleich Null. Um so mehr ging es mir in diesem Jahr mehr um Inspiration. Denn in Sachen modernen Programmierparadigmen ist und bleibt Symfony aus meiner Sicht ein Musterstück.

Silex – Symfony goes micro

Der erste Vortrag über das symfony micro Framework Silex war zwar ganz interessant, allerdings wollte mir für meine tägliche Arbeit so gar kein Anwendungsfall einfallen und so blieb es für mich eines von vielen Beispielen am Tag, dass Symfony2 einfach wunderbar Modular aufgebaut ist.

Inspire yourself of Symfony2 to create better code

Marc Weistroffs Vortrag brachte dann schon den Grund meiner Anwesenheit ziemlich genau auf den Punkt und enttäuschte auch nicht. Von Seperation of Concerns (SoC) über PHPs PSR-0 bis hin zu den zahlreichen Interfaces in Symfony2 (140, im Gegensatz zu den eher mageren 4 in Symfony1), gab es massenhaft Input und Hausaufgaben in Form von Lesestoff.

Catching Opportunities with Open Source

Gleich zu Zweit und mit einer Unmenge an kleinen Anekdoten gespickt, entfalteten Stefan Koopmanschap und Christian Schaefer in ihrem Vortag ein recht mitreißende Dynamik. Es ging nicht um Symfony, sondern um die Arbeit an OpenSource Projekten im Generellen, ob es nun das Schreiben von Code oder Doku ist: Was bringt einem persönlich die Mitarbeit an OpenSource-Projekten eigentlich?!

Zuerst waren mir einige Gründe ehrlich gesagt etwas unangenehm. Irgendwie dachte ich mir: Klar hat man beruflich gewisse Vorteile, wenn man sich entsprechend engagiert. Aber ein Gentleman genießt und schweigt, oder? Ist aber totaler Quatsch. Es war eigentlich gut solche Dinge einfach mal klar auf den Punkt zu bringen, erst recht wenn damit Leute zu animieren sind sich mehr einzubringen.

Nach dem Vortrag hatte ich das Gefühl ich müsste dringend mehr für die Community machen. Leider bekomme ich es zeitlich nur kaum gebacken. In jedem Fall gebührt all denjenigen, die täglich OpenSoucre leben, mein tiefster Respekt und Dank, egal ob für Fame and Glory oder das nächste Bewerbungsgespräch.

The Sonata AdminBundle

Das AdminBundle ist das was in Symfony1 die Admin Generatoren waren. Die Konfiguration setzt dabei mehr auf das direkten definieren von Feldern im PHP-Code, anstatt wie vormals auf YAML. Auf den ersten Blick erscheint das etwas komplexer. Da die Konfiguration aber eigentlich direkt auf der Symfony2-Form Komponente aufsetzt, sollte es schnell zu verstehen sein. Die YAML-Konfiguration in Symfony1 ist rückblickend betrachtet oft auch ein Ärgernis gewesen, da die Konfiguration schwieriger nach zu vollziehen war.

Aus meiner Sicht hat es dem Vortrag aus meiner Sicht etwas an Pepp gefehlt. Eigentlich sollte es aber schon vollkommen genügen zu Wissen, dass es nun auch für Symfony2 wieder einen Admin Generator gibt, um Begeisterung auszulösen. In symfony1 hat er mir bereits Unmengen an Zeit gespart.

Extending and Leveraging the Power of the Command Line Interface

Für mich war das Vorstellen der Console Component das beste Beispiel einer Symfony2-Komponente. Nicht praxisnah, aber gut nachvollziehbar und unterhaltsam wurde an Hand eines Hangman für die Kommandozeile auch gleich die kinderleichte Erweiterung demonstriert. Ein kurzweiliger Vortrag, der Lust darauf gemacht hat gleich selbst los zu legen. Die Smyfony2 Components sind wahrlich mehr als einen Blick wert!

Dependency Injection and the Symfony2 Service Container

Im Gegensatz zur CLI-Component war der Vortrag zur Dependency Injection Component für mich weniger interessant. Zum einen weiß ich die Vorteile bereits zu schätzen, zum anderen bin ich da aber einfacher der Anwender. Ich werde das Ganze letztlich wie in Symfony2 vorgegeben einsetzen und mich an Vorzügen erfreuen . Das ich die Komponente mal für sich alleine benötigen würde, kann ich mir beim besten Willen nicht vorstellen.

The State of Symfony

Der Höhepunkt des Tages war, wie nicht anders zu erwarten, die Keynote von Fabien Potencier. Der Mann weiß mit seinem französischen Akzent und Charme mitzureißen, aber mit seiner Art auch zu provozieren. Da steht jemand, der ganz klar nur das Beste will und von seiner Arbeit überzeugt ist.

Da wird gleich zu Anfang mal der Krieg der Frameworks propagiert. Symfony2 das MVC aberkannt: “Because I don’t care”. Wenn er sich auf etwas festlegen sollte, dann darauf das es sich bei Symfony2 um ein Request/Response-Framework handelt…

Am Ende gibt es zur Abrundung dann noch eine Erweiterung zur Performance-Analyse innerhalb der Admin-Toolbar. Diese wird später auf die Frage “Wann sie den verfügbar sein” obercool ohne ein weiteres Wort gepusht. Ja, er reißt mit, die coole Socke.

Letztlich ist die Zeit wie im Flug vergangen, auch wenn man merkt das da jemand spricht der wirklich riesige Projekte angeht und überhaupt in einer ganz anderen Welt Zuhause ist, als ich es bin… egal, eine wirklich tolle Keynote und guter Abschluss.

Abschließend

Zum Ende gab es dann noch “A shitload of beer” mit Sebastian… sehr schön, ist es doch letztlich der Austausch der so einen Tag wirklich rund macht. Allerdings ist es nur ein Wunder das ich meinen letzten Zug noch erwischt habe bzw. überhaupt noch nach Hause gefunden habe ;)

Im nächsten Jahr wird es voraussichtlich keinen späten Zug mehr nach Hause geben. Die Symfony-Community wächst. Tatsächlich ist Deutschland nach Frankreich und den USA bereits der drittgrößte Markt für Symfony und so wird es im nächsten Jahr, anstatt eines vierten Symfony Day in Köln, wohl eine weitere Symfony Live in Berlin geben, in Anlehnung an die bereits bestehenden in Paris und San Francisco. Ich freue mich darauf!

Early bird Preise für die T3CON gibt es noch bis zum 5. August. Den SymfonyDay gibt es noch bis zum 1. September günstiger. Also, schnell sichern!

Zudem  steht noch die Prüfung zum Certified TYPO3 Integrator beim Typo3Camp im München an. Wenn es hier also auch erst mal weiter eher ruhig bleiben sollte: Ab September werde ich mich vor lauter Themen nicht mehr retten können.

Vor Ewigkeiten gab es dazu zwar mal ein Ticket. Trotzdem hat eine entsprechende Lösung leider nicht den Weg in die aktuelle stabile Version 1.3/4 gefunden und wird es nach Kris Wallsmith auch nicht mehr. So weit zumindest mein aktueller Kenntnisstand.

Der aus meiner Sicht einfachste Weg führt daher aktuell über die direkte Anpassung der jeweiligen sfForm Class. Über die generator.yml kann nur das ganze Formular eingebunden werden, wie auch hier im Forum beschrieben, z.B:

form:
  display:
    "Content German":  [de]
    "Content English": [en]

Translation Component

Den Start hat die neue Translation-Komponente gemacht. Diese ist sicherlich etwas besser als die alte Variante, aus meiner Sicht aber nicht besonders spannend. Gut gefallen hat mir bereits zu diesem Zeitpunkt der Session die Art mit der seine Entwicklungen vorstellte und seine Entscheidungen erklärte. Etwa ging er darauf an welche Lösungen er alle gesichtet hat und warum z.B. die Zend_Translate nicht das Rennen gemacht hat und so letztlich eine Neuentwicklung nötig war.

Template Engine

Weiter ging es mit Twig. Ja, Symfony2 bringt eine eigene Template-Engine mit und ich hatte meine Meinung dazu: Das brauche ich nicht. Prinzipiell eine Meinung die Symfony2 durchaus zulässt, da die Views sowohl mit Twig als auch mit PHP generiert werden können und beide gleichberechtigt existieren. Trotzdem, Fabien lieferte einige Beispiele und mit jedem wurde klarer: Twig macht es wirklich einfacher und ist so integriert, dass ich ihm zumindest eine Chance geben werde.

Forms

Mit jeder größeren Symfony-Version in den letzten Jahren gab es auch größere Änderungen am Form-Framework. Auch wenn ich mich mit jeder Variante irgendwie, irgendwann anfreunden konnte, war jede Lösung doch immer recht schwer zugänglich. Mit der neuen Formular-Lösung wage ich aber zu behaupten, dass sich diese Probleme nun erledigt haben.

Die neuen Formulare sind überaus flexibel und nun ja, auch einfacher zu verstehen. Keine Magie. Jede Formular-Ausgabe ist zu 100% über Twig-Templates anpassbar. Alleine diese Tatsache hätte mir in der Vergangenheit schrecklich viel Zeit erspart. Ich freue mich darauf!

Firewall

Cool hört sich das an, so Fabien. Stimmt, aber es scheint auf Anhieb auch sehr cool. Die “Firewall” stellt eine Schicht von Symfony dar, die, wer hätte das gedacht, für dich Sicherheit zuständig ist. Ich neige dazu zu sagen “typisch Symfony2″ ist diese Schicht einfach konfigurier- und erweiterbar. Die Namensgebung ist dabei, wie bei allem Symfony2 Komponenten, einem Betriebssystem nachempfunden.

Postkarten

Zur Diskussion wurde Fabien auf einen Tweet angesprochen, in dem er seine Zweifel am Open-Source-Gedanken in den Raums stellt. Die vorherige Frage innerhalb der Diskussion machte auch klar wie es dazu kommt: Fabien MUSS sich Zeit nehmen bestimmte Funktionen umzusetzen. Er MUSS sich dafür entschuldigen, dass er auch etwas Zeit mit Familie und Freunden verbringen will. Klar kann er das nicht ganz ersnt meinen, aber scheinbar gibt es Leute die seine großartige Arbeit nicht im Ansatz zu schätzen wissen und ihm selbst Zeit mit seiner Familie nicht gönnen wollen.

Seine Antwort bezüglich des Tweets viel so auch etwas länger aus. Man merkte, ihm war das Thema sehr wichtig. Verständlich. Zum Ende seiner Antwort äußerte er dann den Wunsch, eines Tages nach jedem fertiggestellten Symfony-Projekt einen Postkarte zu erhalten. Wenige Tage rief er dazu auch noch einmal in seinem Blog auf.

Für mich steht fest, Fabien ist das Herz von Symfony und wird auch von mir in Zukunft Postkarten erhalten. Das ist das Mindeste.

Bei mir traf das Thema einen empfindlichen Nerv. Nicht nur bei mir, wie sich dann bei der Diskussion heraus stellte. Es ist schon vom Entwickler-Standpunkt aus schwer sich gegen ein CMS wie Drupal oder Typo3 zu entscheiden. Wenn ich mich gegen den Einsatz eines solchen CMS entscheide, entscheide ich mich auch gegen Unmengen fertiger Funktionen und noch mehr bereits entwickelter Plugins.

Bei jedem Symfony-Projekt mit dem ich anfange, mache ich mir zum Beispiel aufs Neue Gedanken, wie das Menü am besten verwaltet werden kann und aktive Menüpunkt entsprechend angezeigt werden können. Sicherlich, es gibt diverse Lösungen dazu. In einem fertigen CMS muss ich mich um solche allgemeinen Dinge nicht mehr kümmern und kann mich auf Kernprobleme konzentrieren.

So weit die Theorie. Meine eigene Zerrissenheit in diesem Thema hat sich vor ein paar Wochen schon hier widergespiegelt. Das verstärkte Auftreten von Phrasen wie “Drupal Hell” nach dem Vortrag, haben dann auch nahe gelegt, dass ich damit nicht alleine bin. Man setzt auf diese ganzen tollen bestehenden Funktionen eines CMS. Hat seine 90% oder 95% fertig und die letzten paar Prozent zur Fertigstellung werden zur Hölle, da einem das CMS zu viele Steine in den Weg legt. Die Entscheidung für das CMS ist aber seit langem gefallen. Der Weg zurück also nicht mehr drin. Man ist mittendrin in der CMS Hölle.

Etwa in dieser Phase eines Projekts, spätestens aber wenn es beim nächsten Mal um die Entscheidung für den Einsatz eines CMS geht, sehnt man sich die wohlige, gut dokumentierte und logische Struktur eines Frameworks wie Symfony zurück. Dort mögen zwar viele Dinge erst programmiert werden müssen. Dort kann ich sie aber auch konsequent umsetzen.

Ich hatte Mitte letzten Jahres meine ganz besonderen Höllen-Erfahrungen, neben den alltäglichen: Es ging um einen Veranstaltungskalender innerhalb einer Typo3 Seite. Als Extension war bereits zur Angebotserstellung die Calendar Base Extension auserwählt. Eine Extension die Typo3 eigentlich um genau die richtigen Funktionen erweitert.

Die Umsetzung beginnt: Ein paar kleine zusätzliche Vorgaben durch das Design. Ein paar Wünsche von Kundenseite. Die Einsicht das der Programmcode der Extension das reine Chaos ist und schon musste ich gleich mehrere Wochen in der Hölle schmoren… dabei war nur eine Woche ohne Hölle zur gesamten Umsetzung eingeplant. So lernt man Typo3 hassen, obwohl es selbst dafür gar nichts kann und arbeitet faktisch ohne Bezahlung.

Nun, Gaylords Präsentation konnte da leider auch nicht die Killer-Argumente bringen, warum man auf jeden Fall auf eine Framework setzen sollte. Zu zahlreich sind die Gegenargumente. So gilt es vor jedem Projekt wieder aufs neue genau abzuwägen. Das Vorhandensein einer Extension und eines CMS mit allen Funktionen genügt leider noch lange nicht um sich darauf verlassen zu können.

Mein Lösungsansatz, der in letzter Zeit zum Erfolg zu führen scheint, ist es wesentlich mehr Zeit für Planung und Konzeption einzuplanen. Auch bei ganz normalen kleinen Firmenseiten. Ich bombardiere den Kunden mit Fragen und drehe jedes Plugin dreimal um, bevor ich mich für den Einsatz eines CMS entscheide. Die letzten Prozente zur Fertigstellung verlieren durch diese Vorarbeit aber wesentlich an Schrecken.

Letztlich bin ich mir sicher das es nicht mehr lange dauern kann bis entweder Typo3 mit seiner Flow3 Basis oder Symfony mit seinen CMF-Bestrebungen die Entscheidung für mich wesentlich vereinfacht. Bis dahin führt das Thema bei mir aber leider weiter zu ausufernden Posts…

Übrigens, die Kunden bekommen letztendlich immer das Optimum und so ist es ihnen egal ob Framework oder CMS. Da muss ich persönlich gar nichts verkaufen. Der Kampf jedoch, der hinter dem erreichen des Optimums steht, ist letztlich immer mein eigenes unbezahltes Problem.

Die Slides scheinen leider noch nicht online zu stehen.

Kris stellte, nachdem er sich vorgestellt hatte, mit einer abstrus langen Liste eigener Extensiosn, in Windeseile verschiedene Lösungsansätze vor. Vom Apache pimpen bis zum sfRoute erweitern. Was sich bei mir einstellte war weniger ein vollständiges Nachvollziehen, als ein Flow. Genau der Flow der sich bei der Entwicklung mit Symfony einstellt.

Fehlende Funktionen, spezielle Anforderungen, undokumentierte Tiefen: Alles kein Problem. In Symfony ist schnell die richtige Stelle zum Einhaken gefunden und entsprechend erweitert. So gelang es Kris nicht mir auf die schnelle viele neue Sachen beizubringen, aber sehr wohl wieder die enorme Flexibilität von Symfony vor Augen zu führen.

Die Session behandelte dabei noch Symfony 1.x. Ich bin gespannt was erst los ist, wenn Symfony2 in den Produktiveinsatz geht!

Da ich test.ical.ly regelmäßig lese, gab es in diesem Vortrag für mich persönlich nicht viel neues zu entdecken. Trotzdem hat es mal etwas die Leute auch live zu sehen. Christian stellte sein Vorgehen zum Testen von Symfony Plugins vor. Ein Thema über das er schon einmal gebloggt hat und mir damit das Testen meiner Plugins wesentlich erleichtert hat.

Ganz zu Anfang gab er den Hinweis auf das sfTaskExtraPlugin. Ich habe das Plugin im Einsatz seit dem ich angefangen habe Seiten mit Apostrophe umzusetzen und kann es auch nur jedem ans Herz legen. Plugins in ihrer kompletten Struktur sind mit einem Befehl in der Kommandozeile angelegt.

Plugins sind dabei nicht nur beim Testen sinnvoll, da sie eine abgeschlossene Umgebung bieten. Auch geht es nicht nur darum die Plugins für andere zugänglich zu machen. Seit dem mir das Plugin bekannt ist, kapsele ich alle Programmierung in eigene Plugins. Dieser Schritt, der durch das Plugin stark vereinfacht wird, führt zu wesentlich mehr Struktur innerhalb eines Symfony-Projekts.

Im Vortrag wurden diese Vorteile, aber auch das Testen im Allgemeinen noch einmal beleuchtet. Auch was gegen Lime und für PHPUnit spricht wurde thematisiert. Ich möchte mich an dieser Stelle einfach mal für die hilfreichen Posts von Christian bedanken. Sie haben mir bereits viel Arbeit erspart und das sichere Gefühl des Testens mit PHPUnit näher gebracht.

Pierre Joye hatte als Windows-Angestellter aus meiner Sicht, und auch in Anbetracht der Appledichte im Raum, nicht unbedingt den leichtesten Einstand. Das war ihm aber völlig klar. Die Übergänge seiner PowerPoint-Präsentation waren durchgängig beachtlich und avancierten zum Running Gag, da sie die Keynote Nutzer beeindrucken sollten. Das war es dann aber schon mit dem durchaus sympathischen Bashing. Er ist nämlich auch PHP-Core Member und so war sein Thema auch weniger Symfony alleine, als PHP im allgemeinen.

Die Nachricht das PHP5.3 die erste Version ist, die nun auch unter Windows problemlos läuft, löste nicht unbedingt Begeisterungstürme aus, war in Anbetracht seiner Arbeit für Microsoft aber sicherlich wichtig.

Spannender war da sein aufstellen bekannter kritischer Thesen gegen den Einsatz von PHP. Thesen die man alle nicht von der Hand weisen kann. Darum ging es aber auch nicht. Nachdem er PHP eigentlich schon in Grund und Boden geredet hatte, baute er es wieder auf. Klar, es geht schöner. Aber, darum geht es nicht. It’s not about beauty!

Er zog auch dem letzten Zuhörer den Zahn PHP sei der Weisheit letzter Schluss. Hob jedoch hervor das man sich als PHP-Entwickler mehr als Handwerker als Künstler sehen sollte. In PHP lassen sich verdammt schnell Ergebnisse erzielen. PHP ist auch in den seltensten Fällen der Flaschenhals wenn es um Performance geht. Und, ja, es gibt viele Dummköpfe, wie überall, die nicht damit umgehen können und so gerade mit einer Sprache wie PHP eine ganze Menge Mist bauen. Mit Verstand angewandt ist PHP mittlerweile aber eine  mächtige Sprache.

Ein sehr kurzweiliger, interessanter und auch amüsanter Vortrag war das…

Doctrine 2, mit dem ich selbst noch nicht gearbeitet habe, unterstreicht diesen Eindruck nur noch einmal. Arbeiten, mit welcher persistenten Schicht auch immer, lassen sich über das Fluent-Interface wie einfache durch Pfeile miteinander verbunden Sätze schreiben. Die DQL (Doctrine Query Language) mag zwar auch eine interessante Sache sein, in eigenen Projekten ging es bisher aber immer ohne. Durch Bibliotheken wie Doctrine beschleicht mich ab und an die diffuse Angst ich könnte normales SQL verlernen.

Das Kernthema des Vortrags war aber der noch im Alpha Stadium befindliche neue Object Document Mapper für MongoDB. Dabei unterscheidet sich das Interface praktischer Weise auf den ersten Blick nur wenig von dem des Doctrine OR-Mapper. Trotzdem gab es einige interessante Vergleiche, welcher Aufwand direkt auf Basis von MongoDB betrieben werden muss und wie viel Arbeit dagegen der Document Mapper übernimmt. MongoDB selbst ist dabei bereits im PHP-Core implementiert.

Für mich ist der ganze NoSQL-Hype immer noch schwer greifbar und neu. Persönlich habe ich “leider” wenig mit Projekten zu tun, die dermaßen auf Performance angewiesen wären, wie sie durch den Einsatz einer solchen Lösung zu erreichen sein soll.

Gerade zum Ende der Präsentation und mit der Diskussion wurde dann aber auch noch einmal klar gestellt: MongoDB bzw. generell der NoSQL-Ansatz ist kein Ersatz für eine relationale Datenbanken. Wenn es aber etwa darum geht Dokumente z.B. in einem Cache zu sichern, ist MongoDB die bessere Wahl. Mit dem Doctrine Document Mapper für MongoDB sollte dem einfachen Einsatz dann eigentlich auch nichts mehr im Wege stehen.