ebene7

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.

MySQL: Datenbank kopieren

Daniel — Tue, 05 Feb 2013 13:00:22 +0000

Bestehende Datenbank in Datei schreiben:

mysqldump datenbank_orig > datenbank_orig.sql -ubenutzername -p

Neue Datenbank aus Datei befüllen:

mysql -ubenutzername -p datenbank_kopie < datenbank_orig.sql

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' %}

Sortieren mit PHP5 Closures und dem Java Comparator Pattern

Daniel — Fri, 31 Aug 2012 04:00:13 +0000

Was mich schon oft bei PHP ein wenig störte ist, dass es zum Sortieren nicht so schöne Comparatoren wie in Java gibt.

Nun habe ich in der Vergangenheit ja schon das eine oder andere über Closures in PHP und Java Comparatoren für PHP geschrieben und wollte das nun mal zusammenbringen.

Einige PHP-Sortierfunktionen erlauben Callbacks, um die Reihenfolge zu bestimmen. Da ich das Ganze aber gerne in gut testbaren OOP-Einheiten hätte, müssen wir einen kleinen Umweg gehen.

Zunächst das obligatorische Interface.

namespace E7;

interface Comparator {
  public function compare($a, $b);
}

Diese Schnittstelle implementieren wir mit einer abstrakten Klasse.

namespace E7;

class BaseComparator implements Comparator {
  public function compare($a, $b) {
    if ($a == $b) { return 0; }
    return $a < $b ? -1 : 1;
  }

  public function __invoke() {
    return call_user_func_array(array($this, 'compare'), func_get_args());
  }
}

Und schon haben wir einen einfachen, und zugegebenermaßen nicht typsicheren, Comparator.

Durch die magische Methode __invoke() kann ein Objekt nun wie eine Callbackfunktion verwendet werden.

Für die Sortierung von Objekten kann das dann einfach erweitert werden.

class PersonComparator extends BaseComparator {
  public function compare($a, $b) {
    // hier Prüfung auf Typ etc.
    return parent::compare($a->getId(), $b->getId());
  }    
}

Um die Sortierreihenfolge negieren zu können, können wir einen einfachen Wrapper nutzen.

class ReverseOrder implements Comparator {
  private $_comparator;

  public function __construct(Comparator $comparator) {
    $this->_comparator = $comparator;
  }

  public function compare($a, $b) {
    return $this->_comparator->compare($a, $b) * -1;
  }
}

Beispiel…

//--
$people = array();
for ($i = 0; $i < 10; $i ++) {
  $people[] = new Person();
}

echo 'BEFORE
';
foreach($people as $person) {
  echo "$person
";
}

$comparator = new ReverseOrder( new PersonComparator() );

uasort($people, function($a, $b) use ($comparator) {
    return $comparator->compare($a, $b);
});

// oder

uasort($people, $comparator);

echo 'AFTER
';
foreach($people as $person) {
  echo "$person
";
}