ebene7 » Symfony2

Twig: Flexibel arbeiten mit Blöcken

Daniel — Sun, 10 Mar 2013 18:00:54 +0000

Durch die Arbeit mit Symfony2 lerne ich immer mehr auch die Vorteile und hohe Flexibilität von Twig zu schätzen. Es bietet einfach eine Menge Funktionen von Hause aus und lässt sich zudem auch einfach erweitern. Aber das nur am Rande.

In einem Projekt an dem ich gerade arbeite verwende ich ein Bootstrap-Grid und will gewisse Teile nur rendern, wenn sie verwendet werden bzw. Inhalte bereitstellen. Dazu müssen entsprechende Blöcke überprüft und CSS-Klassen angepasst werden.

Erstmal das Basis-Template ohne irgendwelche Anpassungen (base.html.twig):


  ...
  
    
      

        
        {% block sidebar_left %}{% endblock %}
        

        
        {% block content %}{% endblock %}
        

        
        {% block sidebar_right %}{% endblock %}

Der Nachteil an diesem Konstrukt ist recht offensichtlich. Das Layout ist starr und leere Elemente würden viel Platz verschwenden. Um das zu vermeiden können wir das Template etwas intelligenter machen. Normalerweise hat Logik in Templates nichts zu suchen, aber in dem Fall geht es allein um die Anzeige.

Die Blöcke lassen sich in Variablen schreiben und dann prüfen.

{% set sbleft = block('sidebar_left') %}

{% if sbleft is not empty %}
  {# mach irgendwas #}
{% endif %}

Durch diesen einfachen Code lassen sich die einzelnen Teile im Template nun einfach steuern. Auch wenn es ein paar Zeilen Code braucht, aber das wird später vielfach wieder eingespart.

{% set sbleft = block('sidebar_left') %}
{% set sbrigth = block('sidebar_right') %}

{% if sbleft is empty and sbright is empty %}
  {% set contentClass = 'span12' %}
{% elseif sbleft is empty or sbright is empty %}
  {% set contentClass = 'span8' %}
  {% set sidebarClass = 'span4' %}
{% else %}
  {% set contentClass = 'span6' %}
  {% set sidebarClass = 'span3' %}
{% endif %}


  ...
  
    
      

        {% if sbleft is not empty %}
        
        {% block sidebar_left %}{% endblock %}
        
        {% endif %}

        
        {% block content %}{% endblock %}
        

        {% if sbright is not empty %}
        
        {% block sidebar_right %}{% endblock %}
        
        {% endif %}

Damit ist dieses Template nun schlau genug und weiß wann welcher Bereich angezeigt werden soll und in welcher Größe. Die Klassen für die Sidebars können auch getrennt für jede Seite vergeben werden, wenn der Aufbau nicht symetrisch sein soll.

In einem anderen Template können wir wie gewohnt damit arbeiten.

{% extends "::base.html.twig" %}

{% block content %}
Hier der Seiteninhalt.
{% endblock %}

{% block sidebar_right %}
Hier die rechte Sidebar.
{% endblock %}

Viel Spaß beim Probieren! Kommentare, Anmerkungen oder Fragen sind wie immer willkommen.

Symfony2: Custom ParamConverter für HTTP-Requests erstellen

Daniel — Thu, 31 Jan 2013 21:00:49 +0000

Eines der vielen kleinen Goodies die Symfony2 zu bieten hat ist der ParamConverter. Die ParamConverter übersetzen die Parameter beim HTTP-Request nach den gewünschten Vorgaben. So können zum Beispiel Datenmodelle direkt geladen oder Datum-Strings als DateTime-Objekte genutzt werden. Wenn man mit einem Standardsetup arbeitet, sind diese Converter direkt dabei.

Aber auch eigene Converter sind schnell geschrieben und einsatzfähig. Sämtliche Möglichkeiten des ParamConverters stehen in der Dokumentation.

Als Ausgangspunkt haben wir in dem Beispiel eine Action, die mit einer ID aufgerufen wird.


Über die Annotation @ParamConverter weiß das System nun, dass der Parameter übersetzt werden soll. Die bereits zu Beginn erwähnten Converter sind bereits registriert. Um nun eine eigene Logik zu verwenden, brauchen wir einen eigenen Übersetzter. Die Klasse muss das Interface ParamConverterInterface implementieren.
Die Schnittstelle ist sehr einfach gehalten und bietet alls was man braucht. Die Methode supports() muss ein TRUE oder FALSE zurückgeben, ob die Klasse die Anfrage übersetzen kann und apply() mach dann den Rest.
getName();
        $idParam = $name . 'Id';
        $class = $configuration->getClass();

        if (!$request->attributes->has($idParam)) {
            return false;
        }

        $id = $request->attributes->get($idParam);

        $model = loadModelById($id);
        $request->attributes->set($param, $model);

        if (null === $model->getId()) {
            throw new NotFoundHttpException(sprintf('%s object not found.', $class));
        }

        return true;
    }

    function supports(ConfigurationInterface $configuration) {
        return modelClassExists($class);
    }
}
Die Klasse soll schematisch zeigen, wie ein Converter funktionieren könnte. Die beiden Funktionen loadModelById() und modelClassExists() stehen nur als Pseudocode da. Alle verfügbaren Werte können über die Annotation $configuration abgerufen werden. Über $configuration kommen wir an den Namen des Parameter und den TypeHint.
Sensio\Bundle\FrameworkExtraBundle\Configuration\ParamConverter Object
(
    [name:protected] => post
    [class:protected] => E7\DemoBundle\Model\Post
    [options:protected] => Array
        (
        )

    [optional:protected] =>
    [converter:protected] => model
)
Bevor unser Converter überhaupt beachtet wird, müssen wir ihn in der services.yml als Service registrieren.
services:
    request.param_converter:
        class: E7\DemoBundle\Request\ParamConverter\ModelParamConverter
        tags:
            - { name: request.param_converter, converter: model }
Ab jetzt sollte alles zusammenarbeiten und wir können nach belieben Requestparameter umformen. Viel Spaß!

Symfony2: Globale Variablen in Routen

Daniel — Thu, 13 Dec 2012 05:00:17 +0000

Für ein Projekt wollte ich ein Prefix für die Routen verwenden und dieses an einer zentralen Stelle konfigurieren können. In diesem Fall sollte damit der Admin-/Backendbereich abgegrenzt werden.

Nach etwas Suchen fand ich eine Möglichkeit in der Symfony Dokumentation.

Ab Version 2.1 kann ein Parameter in der Konfigurations-Datei gespeichert werden.

# app/config/config.yml
parameters:
    backend_prefix: admin

Dieser Parameter kann dann z.B. in der Route-Annotation oder der Routing Konfiguration verwendet werden.

/**
 * @Route("/%backend_prefix%/user")
 */
class UserBackendController extends Controller {
    /**
     * @Route("/")
     */
    public function indexAction() {
        /* do something */
    }
}

Durch das Prefix ist dieser Bereich nicht nur optisch im URL abgehoben, sondern kann durch die Security Konfiguration auch leicht nur für einzelne Nutzergruppen freigegeben werden.

Symfony Live 2012 in Berlin

Daniel — Mon, 26 Nov 2012 05:00:16 +0000

In der vergangenen Woche fand am 22. und 23.11. 2012 die Symfony Live 2012 in Berlin statt.

Ich hatte ein Ticket für den Freitag und will den Tag kurz für euch zusammenfassen.

Das Event fand in einer Kirche statt und startete nach dem Frühstücksbuffet fast pünktlich. Der Saal war gut besetzt und dank der Technik konnte man auch aus den hinteren Reihen den Vorträgen gut folgen. Wenn ich die Anmoderation richtig in Erinnerung habe, waren Besucher aus 19 Ländern dabei.

Die Sitzplätze fand ich etwas beengt und das kostenlose WLAN war leider die meiste Zeit überlastet, aber beides für mich eher nebensächlich.

Alle Vorträge und die Moderation wurden erwartungsgemäß auf Englisch gehalten und waren dank der erfahrenden Sprecher meist nicht nur informativ, sondern auch recht unterhaltsam.

Meine persönlichen Favoriten an dem Tag waren der Vortrag “Symfony2 Form Tricks” von Bernhard Schussek (symmetry ) und die Keynote von Fabien Potencier. Alle Themen der beiden Tage sind auch auf der Symfony-Seite zu finden.

In vielen Vorträgen wurde gezeigt wie einfach verschiedenen Aufgaben in Symfony2 umgesetzt werden können und wie der Code wiederverwendbar bleibt. Nach dem Motto “Don’t Reinvent The Wheel”.

Vieles wird dabei über Konventionen vereinheitlicht und gleichzeitig vereinfacht und immer mehr Konfigurationseinstellungen können über Annotations im Code mitgegeben werden. Auch das Eventsystem und Listerners spielen weiter eine große Rolle.

Aus meiner Sicht hat sich der Tag gelohnt. Vieles war bei durch die Arbeit mit Symfony2 bereits bekannt, aber es war doch noch genug Neues dabei. Für mich ist es immer interessant zu sehen, wie andere Entwickler bestimmte Aufgaben lösen und warum der jeweilige Weg gewählt wurde.

Falls auch jemand von euch an einem der beiden Tage dabei war, schreibt gerne einen Kommentar wie es euch gefallen hat.

Symfony2: Action in einem anderen Twig-Template ohne Layout rendern

Daniel — Fri, 28 Sep 2012 04:00:01 +0000

Mit Twig hat man als Entwickler viele Freiheiten und kann sehr flexible Templates erstellen. So ist es auch möglich Seiten durch Vererbung in ein Layout zu packen oder über die Action das Template ohne Layout in ein anderes zu rendern.

Dazu kann im Template die aufgerufene Route abgefragt werden, um gewisse Teile anzuzeigen oder nicht.

{% extends app.request.attributes.get('_route') == '_internal' ?
'::empty.html.twig' :
'MyAppMyBundle::layout.html.twig' %}

Symfony2: Event-Listener über Annotations registrieren

Daniel — Mon, 27 Feb 2012 05:00:04 +0000

In den letzten Monaten habe ich hier leider nicht sehr viel geschrieben und freue mich daher um so mehr, wenn ich dann mal wieder über ein spanndendes Thema schreiben kann. So dann auch, wie ich finde, heute.

Es geht um zwei einfache, aber zugleich sehr nützliche Dinge, die das PHP-Framework Symfony2 mitbringt: Ein einfaches, flexibles Event-Handling und Annotations.

Für mich waren die letzten drei Wochen auch die ersten Gehversuche mit Symfony2 und bislang wurden alle meine Erwartungen bestätigt. Das Framework ist sehr flexibel, aber auch recht komplex. Wer allerdings andere MVC-Frameworks wie Zend kennt, der wird sich auch hier schnell zurecht finden.

So, genug Lob an der Stelle. Neben der positiven Eigenschafft eines Eventhandlingsystems fiel mir auch gleich die Art auf, wie sich in Symfony2 Controllerrouten mit Annotations konfigurieren lassen.

Leider habe ich nichts Vergleichbares für Eventlistener gefunden und die klassische Konfiguration über YML gefiel mir dann auch nicht mehr so recht. Das nahm ich dann also gleich mal als praxisnahes Kennenlernbeispiel her und habe mir da was gebaut.

Als erstes braucht es immer einen Auslöser, damit die Annotations verarbeitet werden. Dafür habe ich mich an das Event “kernel.request” gehängt, das noch vor dem Kontrolleraufruf verarbeitet werden kann.

Einen speziellen Listener hatte ich erst dazwischen, habe es dann später aber wieder etwas vereinfacht. Mein Code entspricht vielleicht nicht allen Symfony-Richtlinien, aber zum Arbeiten und Erklären reicht es aus.

Zum Verarbeiten der Annotations habe ich eine einfache Klasse aufgebaut und mich dabei an den “Route()”-Annotations orientiert. Die Methode “findClass()” ist aus bestehendem Code “recycled”, da sie anders schwerer erreichbar wäre.

reader = $reader;
    $this->eventDispatcher = $eventDispatcher;
  }

  public function init() {
    $listenersDir = realpath(__DIR__ . '/../../Listener');

    $iterator = new \RecursiveIteratorIterator(
      new \RecursiveDirectoryIterator($listenersDir),
        \RecursiveIteratorIterator::LEAVES_ONLY);

    foreach ($iterator as $file) {
      if (!$file->isFile() || '.php' !== substr($file->getFilename(), -4)) {
        continue;
      }

      if ($class = $this->findClass($file)) {
        $reflClass = new \ReflectionClass($class);
        if ($reflClass->isAbstract()) { continue; }

        foreach($reflClass->getMethods() as $method) {
          $annotation = $this->reader->getMethodAnnotation($method, $this->eventAnnotationClass);
          if (!$annotation instanceof Event || empty($annotation)) { continue; }
          $this->registerEvents($annotation, $class, $method->getName());
        }
      }
    }
  }

  /**
   *
   * @param    \MyNamespace\Annotations\Event $eventAnnotation
   * @param    string|object $class
   * @param    string $method
   * @return   \MyNamespace\Annotations\AnnotatedEventClassLoader
   */
  public function registerEvents($eventAnnotation, $class, $method) {
    $listener = is_object($class) ? $class : new $class();

    foreach ($eventAnnotation->getEvents() as $event) {
      $this->eventDispatcher->addListener(
        $event, array($listener, $method), $eventAnnotation->getPriority()
      );
    }
    return $this;
  }

  /**
   * Returns the full class name for the first class in the file.
   *
   * @param string $file A PHP file path
   *
   * @return string|false Full class name if found, false otherwise
   */
  protected function findClass($file) {
    $class = false;
    $namespace = false;
    $tokens = token_get_all(file_get_contents($file));
    for ($i = 0, $count = count($tokens); $i < $count; $i++) {
      $token = $tokens[$i];

      if (!is_array($token)) { continue; }

      if (true === $class && T_STRING === $token[0]) {
        return $namespace.'\\'.$token[1];
      }

      if (true === $namespace && T_STRING === $token[0]) {
        $namespace = '';
        do {
          $namespace .= $token[1];
          $token = $tokens[++$i];
         } while ($i < $count && is_array($token) && in_array($token[0], array(T_NS_SEPARATOR, T_STRING)));
       }

       if (T_CLASS === $token[0]) {
         $class = true;
       }

       if (T_NAMESPACE === $token[0]) {
         $namespace = true;
       }
     }

     return false;
   }
}

Damit der Loader später auch seinen Dienst tut, muss er noch als Listener für das “kernel.request”-Event bekannt gemacht werden. Dafür habe ich die Datei “app/config/annotations.xml” mit folgendem Inhalt angelegt.





  
    MyNamespace\Annotations\AnnotatedEventClassLoader

Die Konfiguration muss dann auch noch der AppKernel-Klasse mitgeteilt werden und damit ist der Loader eingebunden.

class AppKernel extends Kernel {
  // other methods...

  public function registerContainerConfiguration(LoaderInterface $loader) {
    // ...
    $loader->load(__DIR__ . '/config/annotations.xml');
  }
}

Annotations werden durch eigene Klassen verarbeitet und können dadurch mit beliebiger Logik versehen werden. Alles was einer Annotation als Parameter mitgegeben wird, bekommt die Klasse als Array im Constructor übergeben.

Für die Registrierung von Eventlistener brauchte ich nur die Events, die hier kommasepariert übergeben werden und gegebenenfalls noch die Priotität, in dem Fall optional. Die Klasse selber wird auch durch eine Annotation als solche gekennzeichnet.

setEvents($options['value']);
    }

    $this->setPriority(
      isset($options['priority']) ? $options['priority'] : 0 );
  }

  public function getEvents() {
    return $this->events;
  }

  public function setEvents($events) {
    if(!is_array($events)) {
      $events = array_map('trim', explode(',', $events));
    }
    $this->events = $events;
    return $this;
  }

  public function getPriority() {
    return $this->priority;
  }

  public function setPriority($priority) {
    $this->priority = (int)$priority;
      return $this;
  }
}

Nun sollte alles an PHP-Code und Konfiguration an seinem Platz sein, aber wie funktioniert das jetzt genau?

Durch das Event wird der Loader benachrichtigt, dass die Listener initialisiert werden sollen. Dazu wird das Verzeichnis “Listener” nach Klassen mit Annotations durchsucht, welche dann von der Annotation-Event-Klasse verarbeitet werden. Innerhalb des Loader werden dann die Listener für die Events registriert und können von da an verwendet werden.

Die Untersuchung des PHP-Codes funktioniert mit Reflections, was ansich immer den Ruf hat langsam zu sein. Der AnnotationReader verfügt über ein eigenes Caching und macht sich daher zeitlich nicht negativ bemerkbar.

Der Loader durchsucht das gesamte Verzeichnis in beliebiger Tiefe nach Dateien, daher bleibt man in der Namensvergabe frei.

Ein Listener könnte dann zum Beispiel so aussehen:


Ein Aufruf aus dem Kontroller funktioniert dann wie gewohnt über den EventDispatcher, der fast überall als Service erreichbar ist.
public function indexAction() {        
  $this->get('event_dispatcher')->dispatch('foo.bar');
}

// oder
public function indexAction() {
  $someEvent = new SomeEvent();       
  $this->get('event_dispatcher')->dispatch('foo.bar', $someEvent);
}
Wie gesagt sind das meine ersten Versuche mit Symfony und der Code ist nicht optimiert. Die Funktionen des Loaders sollten noch weiter in Unterobjekte verteilt werden, damit das ganze noch flexibler wird und auch der gecodete Teil mit dem Verzeichnisnamen ist verbesserungfähig.
Ich konnte dabei wieder ein paar Sachen lernen und vielleich spart es ja dem einen oder anderen von euch etwas Zeit, falls ihr das braucht.