symfony generate:plugin myPlugin

wird gleich eine ganze Symfony-Projekt-Struktur angelegt. Meine Vermutung, dass es mit der Testbarkeit des Plugins zusammenhängt, hat dann dieser sehr gute Artikel bestätigt.

Die Jungs machen sich Gedanken und so macht sogar das ausgiebige Testen richtig Spaß… und ab dafür!

Symfony – Ok, schon länger mein absoluter Liebling. Im letzten Jahr neigte ich dazu alles auf Basis von Symfony umzusetzen. Aber, auch wenn Symfony ein berauschend gut dokumentiertes Framework ist. Es bereits für eine Menge Aufgaben Plugins gibt und auch eigene Erweiterungen schnell programmiert sind: Eine voll ausgestattete Shopanwendung oder auch “nur” ein CMS einzurichten artet zeitlich schnell aus. Bringt einem zuweilen auch um den Verstand. Daher werde ich mich am Riemen reißen. Symfony wird dieses Jahr ausschließlich für Entwicklungen mit besonderer Datenbankstruktur und funktionalen Ansprüchen zum Einsatz kommen. Und ich werde diese Projekte genießen.

Typo3 – Meine Beziehung zum CMS Typo3 ist eher durchwachsen. Es ist ressourcenhunrig, nicht gerade einfach zu konfigurieren und das Backend gewinnt für meinen Geschmack nicht unbedingt einen Schönheitspreis. Aber, es gibt einen entscheidenden Vorteil: Wenn es um eine beliebige Anforderung an ein CMS geht, konnte ich bisher getrost sagen “Typo3 kann das”. Dieses Ungetüm ist einfach dermaßen flexibel und, vor allem in Deutschland, weit verbreitet, das es einem einiges an Kopfschmerzen erspart und Freizeit schafft, wenn man sich dann mal eingearbeitet hat. Daher wird im Bereich Content-Management Typo3 mein CMS für das Jahr 2009.

Magento – Der gesamte Bereich Webshop war die letzten Jahre für mich der Stressfaktor schlechthin. Mittlerweile sehe ich auf 2 Eigenentwicklungen und eine Umsetzung auf Basis der Typo3-Erweiterung tt_products zurück. Zufrieden haben mich die Ergebnisse aber nicht gemacht. Durch mein Lieblingszeitschrift T3N wurde ich dann auf Magento aufmerksam. Zum ersten Finale Release gab es einen großen Hype um Magento.

Tatsache ist: Magento ist ein genialer Webshop. Basierend auf dem Zend Framework besitzt es einen nahezu perfekten Unterbau und es macht einem richtig stolz das Backend einem Kunden zu zeigen. Aber, Magento macht auch sehr sehr viel Arbeit. Alleine die deutsche Mehrwertsteuer einzurichten war anfangs ein Kampf. Einfach mal einen Webshop aufsetzen ist also auch bei magenot nicht der Fall. Dafür wird man am Ende aber für seine Mühen belohnt und so bleibt Magento das Shopsystem meiner Wahl.

Klar, Vorsätze sind dafür da gebrochen zu werden. Für den Moment bilde ich mir einfach ein dieser Artikel hätte etwas verbindliches. Wenn mitte des Jahres dann hier Artikel über das Zend Framework, Drupal und xt:Commerce stehen, kam es zu einem Putsch durch die zweite Garde.

Beim Einbinden meines neuen Moduls in ein recht komplexes Formular schnellen die JavaScript-Fehler in Firebug plötzlich auf stolze 20. Ein Blick auf die Fehlermeldungen: Alle Autocomplete-Felder, umgesetzt mit einem erweiterteten sfWidgetFormJQueryAutocompleter-Widget, welches auf jQuery basiert, sind betroffen. Autocomplete getestet: Nix mehr Autocomplete. Das war der Moment in dem mir klar wurde, dass ich etwas zu leichtsinnig mit dem Einbinden von JavaScript-Frameworks umgegangen war.

Der Zeitplan geriet ins wanken und meine Stimmung stark abzusacken. Zum einen basieren die in Symfony integrierten JavaScript-Helper auf Prototype, zum anderen wird an diversen Stellen, etwa im sfFormExtraPlugin oder im Jobeet-Tutorial, mit jQuery gearbeitet. Nun sollte von Seiten Symfony auf keinen Fall das Festlegen auf ein Framework statt finden, aber von Seite des Entwicklers sehr wohl, wie mir dämmerte. Also, meinen Verdacht auf den Punkt gebracht: Prototype und jQuery kommen sich gehörig in die Quere. Ich hatte in meinem Wahn aber einfach das Beste von beiden übernommen.

Direkt der erste Treffer meiner Suche bestätigt meine Vermutung. Sowohl jQuery, als auch Prototype nutzen das $-Zeichen als Funktionsnamen. Lösungen des Problems war schnell gefunden, nach 21 Uhr Feierabend sah das mir aber nicht mehr aus. Doch ich irrte mich, um 21 Uhr sollte ich auf dem Heimweg sein.

Die schnelle Lösung verdanke ich dem Plugin sfJqueryReloaded. Dieses liefert zum größten Teil jQuery-Pendante für die von Symfony angebotenen Prototype-Helper. Aus meiner genutzten Funktion submit_to_remote wird dann einfach jq_submit_to_remote und im Handumdrehen war Prototype überflüssig.

Wichtig ist es das Plugin in Version 1.2.2 zu installieren, da sich in der 1.1.6 Version ein Bug befindet, durch den die Formular-Inhalte nicht übergeben werden:

symfony plugin:install sfJqueryReloadedPlugin --release=1.2.2

Schön, und weiter geht es mit der Ajaxifizierung!

generator:
  class: sfPropelGenerator
  param:
    i18n_catalogue:        my_translation

Diese Angabe führt dazu, dass symfony in application/i18n/my_translation.xx.xml nach den Übersetzungen für die generierten Dateien sucht. Bei xx handelt es sich dabei um den Ländercode, also z.B. my_translation.de.xml. Der Aufbau dieser Dateien wird hier beschrieben. Durch diese Änderungen kann jetzt der Titel der Listen und Formulare angepasst werden.

Übersetzungen der im Model definierten und vom Generator ausgegebene Felder greift in dieser Datei jedoch nicht. Hierzu muss der jeweiligen Form-Klasse erst mitgeteilt werden, auf welchen Katalog sie zurückgreifen soll:

$this->widgetSchema->getFormFormatter()
  ->setTranslationCatalogue('my_translation');

Damit können auch die Felder in der Datei angepasst werden, womit die Tabellenübersicht und das Formular übersetzt werden können. Noch nicht greifen tut die Übersetzung für die generierten Filter. Daher muss auch der Katalog für die jeweilige Filter Klasse unter lib/filter angepasst werden. Hierzu einfach die schon bekannte Zeile zur Konfiguration nutzen:

$this->widgetSchema->getFormFormatter()
  ->setTranslationCatalogue('my_translation');

Nach der Anpassung an diesen drei Stellen ist die Übersetzung des Moduls zentral in der Datei my_translation.de.xml möglich.

Wie das Feld ausgegeben werden soll, wird nicht mehr über die Generator-Konfiguration angegeben, sondern das Widget für das Feld in der Form-Klasse des Objekts muss angepasst werden:

$this->widgetSchema['genre_list']->setOption(’renderer_class’, ’sfWidgetFormSelectDoubleList’);

Schon hat man das gewohnte Ergebnis. Tja, eigentlich logisch…

Zu all diesen kleinen Problemchen werde ich hier posten, so das sie anderen erspart bleiben und mir nicht in Vergessenheit geraten. Los geht’s mit dem Anpassen der Datum-Anzeige im Admin-Genearator.

Die Anwendung an der ich arbeite basiert auf schon bestehenden Daten. Dummer Weise blieben beim Import der älteren Datensätzen die Jahresangaben scheinbar auf der Strecke. Schnell war klar, dass es nicht am Import-Script, sondern an den vom Admin-Generator für datetime bereit gestellten Datum-Felder lag. Diese erlauben nur eine Anzeige von 5 Jahren in der Vergangenheit und 5 Jahren in der Zukunft.

Nach etwas Suchen, findet sich in der Klasse sfWidgetFormDate dann auch die Zeile:

$years = range(date('Y') - 5, date('Y') + 5);

Alles klar, das konnte ich so nicht gebrauchen. Schnell war im Netz eine passende Lösung gefunden. Um die Auswahl und Anzeige von Jahren auch weiter in der Vergangenheit und der Zukunft zu erlauben, muss die Form-Klasse des jeweiligen Objektes angepasst werden. In meinem Fall z.B.:

$years = range(1950, date('Y')+5);
$years_list = array_combine($years, $years);

$this->widgetSchema['ba_date']->setOption(’date’, array(’years’ => $years_list));

So funktioniert es dann auch mit Daten in den Fünfzigern. Zugegeben, wenig intuitiv, aber es besteht schon ein Ticket welches in Zukunft für eine bessere Lösung sorgen soll…

Eine Entscheidung

Symfony selbst bietet an diversen Stellen Infos, von der selbst geschriebenen PHP basierten Suchmaschine, bis zum sfLucenePlugin. Nun heißt es, im mittlerweile in die Jahre gekommen Askeet Tutorial, Zend würde für sein Framework noch etwas länger brauchen. Seit der Veröffentlichung des Zend Frameworks in der Stable Version 1.0, kann davon natürlich keine Rede mehr sein. Da ich das Zend Framework sehr schätze – Warum? Verdammt starkes Argument, aber: Es kommt von Zend! – viel mir die Entscheidung leicht.

Das sfLucenePlugin arbeitet mit der Zend Search Lucene Klasse aus dem Zend Framework und stellte damit genug Anreiz für mich da, die Sache mal auszuprobieren. Eine Alternative zum Plugin, in dessen Beschreibung ausdrücklich auf das Alpha Stadium hingewiesen wird, ist die manuelle Integration der Klasse aus dem Zend Framework. Den Weg dazu beschreibt Johannes Schmidt hier im t8d-Blog oder auch hier Dave Dash auf Englisch. Wohl der zuverlässigere Weg, mit dem ich mich auch noch beschäftigen werde, aber das Plugin sollte erst einmal seine Chance bekommen.

Woher kommt dieses “Lucene” eigentlich?

Bei der Lucene Search Komponente des Zend Frameworks handelt es sich um eine in PHP5 implementierte Version der ursprünglich von Apache in Java programmierten Volltextsuchmaschine Lucene. Mehr Informationen zu diesem Ursprung bei Apache finden sich hier. Also, ziemlich starke Namen, die da auftauchen und nun endlich ran an den Speck!

Plugin Installation

Die Installation gestaltete sich gewohnt einfach.

1. Installieren des Plugins:

   symfony plugin-install http://plugins.symfony-project.com/sfLucenePlugin

2. Konfigurationdateien anlegen:

   symfony lucene-init myapp

3. Symfony Cache leeren:

   symfony cc

Die grundlegende Konfiguration

Um eine erstes Ergebnis zu erzielen, habe ich mich einfach an die Konfigurationvorschläge auf der Plugin Seite gehalten. Das gesamte Plugin wird über die Datei search.yml im config Ordner des Projekts (z.B. projekt/config/search.yml) konfiguriert. Also, Datei geöffnet und folgendes rein geschrieben:

index:
  name: MyIndex
  encoding: UTF-8
  short_words: 2
  cultures: [en]

Der name des Indexes wird vom Plugin benötigt, aber scheint sonst keine sonderliche Bedeutung zu haben.

Unter encoding ist prinzipiell auch eine andere Kodierung möglich, in der Doku wird aber ausdrücklich darauf hingewiesen, dass UTF8 generell die beste Wahl darstellt.

Über short_words ist dem Plugin mitzuteilen, bei welcher Zeichenlänge es Wörter gar nicht erst in den Index aufnehmen soll. In diesem Fall also 2 Zeichen.

Ein großer Vorteil des Plugins: Es unterstützt die Internationalisierung bereits. So sind über den Parameter cultures die Sprachen anzugeben, für die ein Index erstellt werden soll. Zumindest eine Sprache ist hier Pflicht, sonst kann der Index nicht erstellt werden.

Infos zu weiteren Konfigurationmöglichkeiten finden sich auf der Projekt Seite.

Die Applikation konfigurieren

Nun geht es darum, dem Plugin zu sagen, welche Daten es in den Index aufnehmen soll. Ich entschied mich für die ORM-Layer Variante und habe dazu die search.yml Datei von eben (also im Beispiel projekt/config/search.yml) um den folgenden Bereich erweitert:

models:
  Post:
    fields:
      id: unindexed
      title:
        boost: 1.5
        type: text
      excerpt: text
      body: text
    description: body
    title: title

Im Bereich fields werden die einzelnen Felder angegeben, welche in den Index übernommen werden sollen. Genauere Infos zu den verwendeten Typen, finden sich hier in der Zend Dokumentation.

Zusätzlich ist es noch möglich, bestimmten Feldern eine höhere Gewichtung im Suchergebnis zu verschaffen. Im Beispiel geschehen beim Feld title, mit der Angabe boost: 1.5

Eigentlich ist die Konfiguration für das Modul damit abgeschlossen, da das Plugin eigentlich automatisch heraus finden soll, welches Feld als Titel und welches als Beschreibung in der Trefferliste angezeigt werden soll. Bei mir ging das nicht so wirklich und so habe ich mit den Angaben description: body und title: title angeben können, welche Felder verwendet werden sollen.

Routing der Applikation

Jetzt muss noch definiert werden, worauf in den späteren Ergebnislisten verlinkt werden soll. Hier kommt die search.yml Datei im Config Ordner der Applikation zum Einsatz. Der Eintrag:

models:
  Post:
    route: post/show?id=%id%

gibt den Pfad an, der bei einem Ergebnis für Post genutzt werden soll. %id% wird dabei automatisch durch die ID des Eintrages ersetzt. Voraussetzung dazu ist allerdings, dass sich die ID auch im Index befindet.

Einrichten Behavior

Nun muss das Model selbst noch so erweitert werden, dass bei Änderungen der Daten automatisch der Index aktualisiert wird. Zurzeit Arbeitet das Plugin leider nur mit Propel zusammen, Doctrine soll folgen. Die Anpassung der Model Klasse, in diesem Beispiel lib/model/Post.php, erfolgt über folgende Zeile, am Ende der Datei:

sfLucenePropelBehavior::getInitializer()->setupModel('Post');

Durch diesen Aufruf werden Behavior für Pre Save, Post Save, Pre Delete und Post Delete initialisiert. Mehr zum Thema Model Behavior findet sich hier in der Dokumentation, im Abschnitt “Using Model Behaviors”.

Ein kleines, aber überaus wichtiges Detail: Propel unterstützt in Standardkonfiguration keine Behavior. Daher muss in der Datei project/config/propel.ini der Wert von propel.builder.addBehaviors von false auf true gesetzt werden. Nach dem ändern dieses Wertes muss das Model mit einem symfony propel-build-model neu gebaut werden, sonst ist die Frustration groß… ich weiß von was ich spreche ;)

So, endlich: Die Volltextsuche!

Alles ist so weit konfiguriert und es kann an das Erstellen des Indexes gehen:

symfony lucene-rebuild myapp

Initialisiert den Index, wobei myapp mit dem Namen der Applikation ersetzt werden muss, für die der Index erstellt werden soll.

Nun fehlt nur noch die Oberfläche, um das Ganze auch zu testen. Hierzu bietet das Plugin bereits ein Standardmodul. Um diese zur Verfügung zu stellen, muss die settings.yml, im Config Ordner der Applikation, um folgende Zeilen erweitert werden, damit das mitgelieferte Modul des Plugins verfügbar ist:

all:
  .settings:
    enabled_modules: [default, sfLucene]

Ein Aufruf der Applikation, mit dem Modul sfLucene, zaubert jetzt auch die lang ersehnte Suchmaske auf den Bildschirm.

Keine Wildcards?!

Ok, eine Suche nach Packungen funktioniert einwandfrei, die Suche nach Packung führt jedoch zu keinem Ergebnis. Hm, dumm, aber, siehe da, nach der Zend Doku versteht die Suche durchaus Wildcards. Also nach Packung* gesucht und nach etwas Testen erst einmal dumm aus der Wäsche geguckt: Kein Ergebnis. Wem soll ich denn bitte diese Suche andrehen?

Die Lösung des Problems war dann ein wenig Tricky. Ich stieß auf eine Diskussion, in der es um die fehlende Wildcard Unterstützung geht, samt der Lösung des Problems!

Diese sieht wie folgt aus: Auch wenn Zend die Wildcards bereits in die Dokumentation übernommen hat, unterstützt die Suche diese in der Stable Version bisher noch nicht, im Nightly Build aber! Also, aktuelles Nightly Build runter geladen, die Search Komponente aus library/Zend/ kopiert und in den Ordner plugins/sfLucenePlugin/lib/vendor/Zend/ über die bestehenden Dateien kopiert. Und Zack, nach einem symfony lucene-rebuild: Die Suche nach Packung* führte zu dem gewünschten Ergebnis und ich konnte wieder aufatmen :)

Was soll nun werden, hm?

Ich könnte nun noch weiter ins Detail gehen, würde dabei aber letztlich nur noch das wiederholen, was eh schon auf der Projektseite beschrieben wird. Es gibt noch diverse Konfiguratonsmöglichkeiten wie Resulthighlighting, Stopwords, eigene spezielle Indexierung und so weiter, aber erst einmal habe ich meine Suche und will wissen wie sie tickt, aber ich sehe dem Ganzen optimistisch entgegen. Erster Eindruck: Ein starkes Plugin!

P.S.: Ich will in dem Blog eigentlich keine News bloggen, die bereits zu Hauf gebloggt wurden, aber wo ich schon mal dabei bin: Heute ist Symfony 1.0.8 erschienen! Die Änderungen gibt es hier.

Wie konnte es nur so weit kommen?

Ok, ich merke, ich muss weiter ausholen: In den letzten Jahren habe ich sehr viel mit Joomla bzw. Mambo gearbeitet, eigene Komponenten geschrieben und auch größere Projekte auf Basis von Joomla umgesetzt. Seit Ende letzten Jahres warte ich nun auf Joomla 1.5. Habe mir die Beta Versionen schon einige Male angesehen, aber so richtige Hochstimmung wollte da nicht aufkommen, davon abgesehen, dass die neue Version bis heute nicht als stabil zur Verfügung steht. Anstatt dessen letzte Woche die, wie ich finde, Hiobsbotschaft: Das “Quality & Testing”- sowie das Design & Accessibility”-Team wurde abgeschafft. Herrje, was soll das denn jetzt? Nun, darum soll es hier nicht gehen. Einen sehr guten Beitrag dazu gibt es aber unter www.nitsche.org.

Um bei der Beziehung zu bleiben: Joomla und ich haben uns auseinandergelebt, sind aber noch gute Freunde, man kennt das ja. Ich will Joomla nicht schlecht machen, ich mag es, aber vor allem wenn es um Anwendungsentwicklung ging, gab es ganz klare Grenzen, an denen alles eher in Frustration umschlug. So machte ich mich also auf die Suche, nach einem wirklichen PHP Framework. Recht schnell hatte ich die wohl üblichen Verdächtigen in der engeren Auswahl:

• ZendFramework
• CakePHP
• PradoFramework
• eZ Components
• Symfony Framework

Eigentlich hätte ich gerne die erste Stable Version des Zend Frameworks genutzt. Das wäre eine reine Sache der Vernunft gewesen. Das Zend Framework wird früher oder später zum quasi Standard PHP Frameworks, da habe ich eigentlich keine Zweifel. Aber, warum Vernunft, wenn es um Liebe geht?! Daher gibt es hier keinen Vergleich der Frameworks, dafür habe ich, mit gerade mal 2 Tagen, bei weitem nicht intensiv genug getestet. Einen interessanten Erfahrungsbericht und Vergleich zwischen cakePHP und Symfony findet man hier und einmal Goolge angeworfen, hagelt es nur so Vergleichstests.

Nein, es geht darum, warum ich mich so schnurstracks in Symfony verliebt habe. Ohne lange Kennenlernphase, Händchenhalten und alles was dazu gehört…

Nun, Symfony ist verdammt sexy!

Ich bin krank? Hm, ich versuche zu erklären, wie ein OpenSource Projekt sexy sein kann:

1. Die Dokumentation läßt kaum Wünsche offen und wird aktiv von der Community weiterentwickelt. Grundlage ist ein komplettes Buch, welches direkt aus der Feder der Entwickler stammt, was der Verständlichkeit allerdings in keiner Weise schadet, also nicht in unverständliche Fachsimpelei ausartet. Am Beispiel von Symfony werden unzählige etablierte Techniken zur professionellen PHP-Entwicklung leicht verständlich angesprochen, so das selbst Programmierer, die bereits eine andere Liebe gefunden haben, daran ihren Spaß haben können.
2. Die Doku ist recht theoretisch gehalten, im Praktischen setzt dafür dann aber das Askeet Tutorial der Dokumentation die Krone auf. In 24 Tagen (Es handelt sich dabei ursprünglich um einen Weihnachtskalender) wird die komplette Entwicklung einer Anwendung in Symfony geschildert, so das man danach wirklich heiß ist, selbst zu entwickeln. Live ist die Anwendung hier im Einsatz.
3. Mit Hilfe von Scaffolding wird die Anwendungsentwicklung enorm beschleunigt. Keine wiederkehrenden, nervenden Aufgaben: Wenige Zeilen auf der Komandozeile und das Grundgerüst steht. Im einstündigen Tutorial “My first symfony project” ist sehr gut nachzuvollziehen, wie viel Arbeit dadurch von Symfony übernommen wird. Einige kennen es sicherlich durch Ruby on Rails, aber hey, ich stehe nun mal auf PHP und da bin ich froh, dass da so etwas nettes nach meiner sexuellen Ausricht …ok, lassen wir das.
4. Der Admin Generator ist dann wirklich ein wahrer Segen. Anhand von Konfigurationsdateien und der Datenbankstruktur, generiert Symfony das komplette Backend, ohne das dazu auch nur eine Zeile PHP nötig wäre. Das Zend Framework bietet bisher noch nichts vergleichbares. In Aktion ist der Admin Generator in diesem Video zu bewundern – zwischenzeitlich hatte ich Probleme den Mund wieder zu schließen…
5. Soweit ich es bisher überblicken kann, handelt es sich um eine wirklich solide PHP5 Codebasis, ohne ständige Ausnahmen. PHP5 ist damit allerdings auch Voraussetzung. Zudem machen die Entwickler einem Hoffnung, in dem sie das ganze als “Enterprise Version” bezeichnen, die Codebasis also noch lange Zeit gepflegt werden soll.
6. Es ist bereits alles an Bord zur Internationalisierung. Eine Never Ending Story bei der Joomla Entwicklung.
7. Viele eingebaute Helfer, die einem das Leben einfacher machen. So ist z.B. Prototype und script.aculo.us bereits integriert. Ein sehr schönes Anwendungsbeispiel dazu ist dieses Video, in dem ein Ajax Warenkorb, mit einigen netten Effekten, programmiert wird.
8. Zur Philosophie gehört es, möglichst viel in Konfigurationsdateien auszulagern. Was auf den ersten Blick nach ziemlichem Overhead aussieht – es gibt bis in die letzte Ebene immer speziellere Konfigurationsdateien – stellt sich als ideale Grundlage für leicht erweiterbare und konfigurierbare Anwendungen da.
9. Das Framework ist durch zahlreiche Plugins erweiterbar. Ein Beispiel, welches mir meine Entscheidungsfindung letztlich enorm vereinfacht hat: Das Zend Framework ist via Plugin zu integrieren!
10. Es gibt noch einiges mehr zu entdecken, aber an dieser Stelle habe ich es satt, mich für meine Liebe zu rechtfertigen, und fordere zu eigenen Entdeckungsreisen auf!

Was für eine Nachricht denn nun eigentlich?

Herrje, nach all diesen Liebesbekundungen, zum eigentlichen Thema zurück. Heute trudelte auch bei mir die Nachricht ein, dass Yahoo, nachdem bereits Yahoo Bookmarks auf Symfony basiert, auch die kommende Version des sehr beliebten Social Bookmaringkdienstes Delicious auf Symfony aufsetzt.

Für mich sind solche Nachrichten wie, hm, ja, als ob mich die Eltern meiner Freundin mögen… Quak! Nein, es bedeutet das meine Entscheidung, wenn sie auch noch so viel aus dem Bauch heraus war, so falsch nicht gewesen sein kann!

Und was soll nun werden, hm?

In den nächsten Monaten werde ich das ein oder andere Projekt auf Basis von Symfony umsetzen. Die ersten Härteprüfungen. Ich freue mich darauf. Hoffentlich besteht die Beziehung das. Es gibt sicherlich auch einiges das gegen Symfony spricht. Als erstes mag es die Lernkurve sein, die anfangs doch arg steil ist, aber es lohnt sich!

Vielleicht habe ich ja auch den ein oder anderen auf den Geschmack gebracht. Keine Angst, ein weiterer Vorteil von Symfony ist, dass man es, im Gegensatz zum Partner, gerne teilt…