Symfony 2.4 wurde kürzlich veröffentlicht. Aber was steckt dahinter? Viele haben mich gefragt, was dieses neue Symfony eigentlich kann und wann oder ob sich ein Upgrade lohnt. In diesem Blogpost will ich ein paar Worte über die neuen Features und deren Benutzung verlieren.

Expression Engine

Wahrscheinlich die grösste und am meisten erwartete Neuerung ist die Expression Engine, welche einem Entwickler erlaubt funktionale Ausdrücke in verschiedenen Bereichen einzusetzen. Dieses neue Feature eignet sich besonders bei Konfigurationen, bei denen eine Entscheidung anhand verschiedener Indikatoren getroffen werden muss, wie bspw. die Zugangskontrolle:

Dieses Beispiel zeigt, wie Regeln für die Zugangskontrolle mittels einer Expression in der security.yml konfiguriert werden können. Aber das ist noch nicht alles. Um ein weiteres Beispiel zu zeigen, definieren wir eine Abhängigkeit in unserer Service-Konfiguration mittels einer Expression:

Es gibt unzählige weitere Anwendungsmöglichkeiten um die neue ‘Expression Language’ zu benutzen, jedoch gibt es meiner Meinung nach auch Nachteile. Die Expression Engine erlaubt uns, Business Logik in unsere Konfigurationen zu schreiben. Es gibt Fälle, in denen das Sinn macht und auch nötig ist, aber generell ist das keine gute Idee. Wo immer möglich, sollten Konfiguration und Business-Logik getrennt werden, da diese Ausdrücke nicht testbar sind, und Debugging eine echte Qual sein kann.

Fazit: Ein cooles Feature, welches vieles einfacher macht. Es sollte jedoch nicht exzessiv benutzt werden.

Weitere Infos:
– New in Symfony 2.4: The ExpressionLanguage Component
– Book > Security > Securing by an Expression
– Expression Language Component

Der RequestStack

Ich denke jeder, der mit Symfony arbeitet kam schon einmal in die Situation, dass er das Request-Objekt in einem Service gebraucht hätte. Aber was tun, wenn mehrere Requests in einem Prozess behandelt werden?

HINWEIS: Wer Symfonys’ Sub-Requests nicht kennt, möchte evtl. zuerst diesen Blogpost darüber lesen: New in Symfony 2.2: The new fragment sub-framework

Das Problem welches ich aufzeigen möchte ist, dass es sehr schwierig ist, zu wissen welcher Request in den Service injected werden soll. Okay, wir können über  synchronized services reden, aber meiner Meinung nach ist das ein Workaround. Eigentlich ist das Problem der Request selbst, da dies ein Value-Objekt ist, welches als Service angesprochen werden kann.

Der RequestStack löst dieses Problem. Wie man in der API Dokumentation sieht, ist dies ein kleiner Service, welcher Zugang zum Master-, Eltern- und dem derzeit aktuellen Request gibt. Also statt dem Request, wird der RequestStack neu injected. Dieser stellt den Zugang zum benötigten Request sicher:

Nebenbei gesagt: Direkt auf den Request als Service zuzugreifen ist ab Version 2.4 deprecated und wird in Symfony 3.0 nicht mehr möglich sein.

Weitere Infos:
– New in Symfony 2.4: The Request Stack
– Request Handling in Symfony 3.0

Kleinere Änderungen

Es gibt auch kleinere Änderungen, die durchaus interessant sind. Beispielsweise kann ich den Form-Profiler und die Möglichkeit Logs auf der Konsole auszugeben nur empfehlen:

Fazit

Die neuen Features sind meiner Meinung nach genau so cool wie der Rest des Frameworks. Es gibt keine riesigen Monolith-Changes. Die Änderungen, die es in den Release geschafft haben sind wie immer stabil und nützlich. Zur Zeit bereiten wir uns bei @ymc_ch darauf vor, Symfony 2.4 Webapplikationen auszurollen und ich kann jedem empfehlen, das auch zu tun.

Diese Liste ist nicht komplett und viele Erklärungen basieren auf persönlichen Meinungen – wie so oft. Haben sie Fragen oder Feedback? Twittern sie an @frank_neff oder schreiben sie einen Kommentar.

This is a german translation. Find the original article on frankneff.ch

0 Kommentare

Einen Kommentar abschicken

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *