Archiv für die Kategorie ‘PHP’

Eigene Validatoren für Symfony Forms

Mittwoch, 04. November 2009

Symfony liefert von Haus aus eine Menge Validatoren mit, um Formulareingaben, die ein Nutzer tätigt, zu überprüfen, neudeutsch: zu validieren. Leider reichen diese sonst sehr mächtigen Validatoren nicht immer aus; so auch in einem aktuellen Projekt.
Für E-Mail-Templates gibt es eine ganze Reihe von vordefinierten Platzhaltern, die jeweils als regulärer Ausdruck vorliegen. So wird für die Anrede in einer E-Mail der Platzhalter {salutation} verwendet, der dann gemäß der ausgewählten Sprache ersetzt wird.

Diese Platzhalter sind zwingend notwendig und müssen deshalb nach dem Abschicken des Formular überprüft werden. Dazu haben wir die Validator-Klasse PlaceholderValidator erstellt.

1
2
3
4
5
6
7
8
9
10
11
12
<?php
class PlaceholderValidator extends sfValidatorBase
{
    public function configure($options = array(), $messages = array())
    {
    }
 
    public function doClean($value)
    {
        return $value;
    }
} ?>

Der Klassenrumpf ist einfach erklärt: Enthalten sind zwei Funktionen, configure und doClean. In der ersten Funktion haben wir die Möglichkeit, unserem Validator bestimmte Optionen und Nachrichten zu geben. Optionen werden benötigt, um den Validator bzw. dessen Überprüfungsroutine zu spezifizieren, und Nachrichten werden benötigt, um Fehlermeldungen vorzubereiten. Optionen gibt es bei einem Großteil der symfony-eigenen Validatoren. Mit ihnen können wir angeben, wieviele Zeichen ein String mindest haben muss, und ob ein Formularfeld ein Pflichtfeld ist oder nicht. Ein beispielhafter Funktionskörper könnte passend zum Beispiel des E-Mail-Template-Validators also wie folgt aussehen:

1
2
3
4
5
6
public function configure($options = array(), $messages = array())
{
    $this->addOption('patterns_required');
 
    $this->addMessage('patterns_required', 'Your template must contain the placeholder "%pattern%"');
}

Als nächstes implementieren wir das Herzstück unseres Validators: die doClean-Methode. Der eingegebene Wert im Formularfeld wird von Symfony an die doClean übergeben. Hier erfolgt nun die Validierung dieses Wertes. Um unser E-Mail-Template zu überprüfen, müssen wir mit Hilfe von regulären Ausdrücken prüfen, ob die benötigen Platzhalter im übergeben Wert vorkommen. Dies realisieren wir in einer Schleife und werfen, sofern der reguläre Ausdruck keine Übereinstimmungen findet, einen Fehler. Dieser enthält den Namen der Fehlermeldung, die wir in der configure-Funktion definiert haben, sowie Namen des Platzhalters, der für diesen Fehler verantwortlich ist. Somit erhält der Nutzer eine Fehlermeldung, in dem ihm mitgeteilt wird, welcher Parameter fehlt.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
public function doClean($value)
{
    $patterns = $this->getOption('patterns');
 
    if($this->hasOption('patterns_required') && $this->getOption('patterns_required') == true)
    {
        foreach($patterns as $pattern)
        {
            if(!preg_match("/".$pattern."/", $value))
            {
                throw new sfValidatorError($this, 'patterns_required', array('pattern' => $pattern));
            }
        }
    }
 
    return $value;
}

Um diesen Validator nun in Formularen zu verwenden, genügt es, dem Validator-Schema mitzuteilen, dass wir unseren Placeholder-Validator nutzen möchten.

1
$this->setValidator('template', new PlaceholderValidator(array('patterns_required' => true, 'patterns' => $patterns)));

Mit den Validatoren gibt Symfony dem Entwickler ein mächtiges Werkzeug in die Hand, welches einfach zu verwenden ist und in allen Formularen zum Einsatz kommen kann.

URLs mit .html-Suffix

Donnerstag, 17. September 2009

Standardmäßig bereitet Symfony die URLs in dem Format /module/action/parameter auf. Dies kann zum Beispiel in einem Blog die URL /article/read/1 sein. Um nun einer Suchmaschine eine statische HTML-Seite zu suggerieren, genügt es, in der Datei settings.yml im Konfigurationsordner einer Applikation folgende Zeilen hinzuzufügen:

1
2
3
prod:
.settings:
suffix:         .html

Symfony erweitert dann selbstständig die URLs, sodass sie aussehen, als läge dort eine statische HTML-Datei. Die Endung wird nur für die produktive Umgebung aktiviert. Damit alle Umgebungen mit Suffixen arbeiten, genügt es, das ‘prod’ durch ‘all’ zu ersetzen.