Generelles zu Filtern

In der kleinen AsciiArt unten kann man erkennen wie Filter funktionieren. Von links kommt das Request an die Applikation, dieses wird vom Dispatcher bearbeitet, der das Request und seine Daten durch die Globalen Filter schickt, diese leiten es dann an die entsprechende Action weiter, welche wiederum das ganz durch ihre eigenen Filter schickt. Jetzt wird erst das Output generiert und die Filter werden danach in umgekehrter Reihenfolge wieder durchlaufen.

Agavi's Filter sind wie eine Zwiebel

Bei allen Filtern ist es so, dass die Auflistung die Reihenfolge der Ausführung bestimmt. Weiter unten ein kleines Beispiel dazu.

Globale Filter

Was sind globale Filter? – Globale Filter gelten für das Request an die Applikation. Als Beispiel kann hier der FormPopulationFiler dienen. Dieser Filter ist in der Lage eine HTML mit Werten zu füllen, was aber erst gemacht werden kann, nachdem das ganze Request durchgelaufen ist und das Output generiert worden ist. Somit ist es möglich in dem Request weitere ActionContainer zu kreieren und weiter Actions auszuführen.

Die Konfiguration der Globalen Filter findet in der global_filter.xml im Konfigurationsverzeichnis der Applikation statt. Hierbei bestimmt die Reihenfolge in welcher sie in der Datei aufgelistet werden in welcher Reihenfolge sie ausgeführt werden.

<filter name="FirstFilter"/>
<filter name="SecondFilter"/>

Hier würde der Filter mit dem Namen FirstFilter zuerst, danach dann der SecondFilter ausgeführt. Die Globalen Filter werden vom Controller geladen und auf gerufen. Hierbei gilt, dass der Controller explizit den Filter AgaviDispatchFilter registriert und ihn dann gleich danach aufruft. In diesem wird das Response gesetzt, aus dem was noch kommt.

Action Filter

Action Filter sind, wie der Name auch schon sagt, für die Action gedacht. Die Grafik oben verdeutlicht dieses sehr gut. Eine Action generiert uns ja in der passenden View das Output, welches vor der Ausgabe dann noch mit dem FormPopulationFilter bearbeitet wird.

Bei den Action Filtern gibt es eine Besonderheit. Zum einen gibt es die Action Filter, die für jede Action aufgerufen werden und Spezial Action Filter die nur für eine bestimmt Action aufgerufen werden. Die Spezialfilter werden im app/Modulverzeichnis/config/action_filters.xml spezifiziert. Die Filter die für alle Actions gelten sollen werden in app/config/action_filters.xml spezifiziert.
Zur der Reihenfolge der Ausführung ist zu sagen, dass erst die generellen und dann die speziellen.

Noch etwas sehr wichtiges, dass man bei dem entwerfen eines Action Filters nicht vergessen darf, ist das jeder Slot, jede ForwardAction ihre eigene FilterChain hat, welche die Filter nochmal durchläuft. Deswegen gibt es zwei Verschiedene Methoden in der Klasse. Die eine, executeOnce, wird immer für die “main” Action auf gerufen, die andere execute wird dann in den restlichen FilterChains auf gerufen. Sollte man aber wollen, dass der Filter beim ersten bis zum letzten Aufruf immer gleich aufgerufen wird, bedient sich die Klasse AgaviFilter dem Trick, dass executeOnce einfach execute aufruft. ExecuteOnce muss als explizier überschrieben werden.

Aufbau eines Filters

Filter sollten immer die Klasse AgaviFilter erweitern. Dort sind schon einmal die grundlegenden Funktionen definiert wie die oben beschriebene executeOnce Methode.

In dem nachfolgenden Beispiel implementieren wir die Klasse FooBarFilter. Diese kann entweder wie im Beispiel ein Klasse sein die sowohl Global als aus Action Filter ist oder nur eines von beiden. (Hier ist es zu Demonstrationszwecken so gewählt)

<?PHP
class FooBarFilter extends AgaviFilter implements AgaviIActionFilter, AgaviIGlobalFilter {
 
public function executeOnce(AgaviFilterChain $filterChain, AgaviExecutionContainer $container)
{
    /* Stuff to be done before the Rest of filters and Output generation is executed */
 
    /* Now we continue with the other filters. THIS MUST BE DONE!!! */
    $filterChain->execute($container);
 
    /* now to the Stuff which needs to be done afterwards. ie. Output transformation etc. */
}
}
?>

Das Beispiel oben hat zu dem nur die Methode executeOnce, was also heißt das der Filter pro Kontext nur einmal ausgeführt würde.

Weiter Infos zu und um Agavi gibt es auf http://www.agavi.org. Auch zu empfehlen ist der Agavi FAQ in dem einige interessante Themen rund um Agavi behandelt werde.

ENGLISH TRANSLATION WILL FOLLOW!

Generelles zu Filtern

In der kleinen AsciiArt unten kann man erkennen wie Filter funktionieren. Von links kommt das Request an die Applikation, dieses wird vom Dispatcher bearbeitet, der das Request und seine Daten durch die Globalen Filter schickt, diese leiten es dann an die entsprechende Action weiter, welche wiederum das ganz durch ihre eigenen Filter schickt. Jetzt wird erst das Output generiert und die Filter werden danach in umgekehrter Reihenfolge wieder durchlaufen.

Bei allen Filtern ist es so, dass die Auflistung die Reihenfolge der Ausführung bestimmt. Weiter unten ein kleines Beispiel dazu.

Globale Filter

Was sind globale Filter? – Globale Filter gelten für das Request an die Applikation. Als Beispiel kann hier der FormPopulationFiler dienen. Dieser Filter ist in der Lage eine HTML mit Werten zu füllen, was aber erst gemacht werden kann, nachdem das ganze Request durchgelaufen ist und das Output generiert worden ist. Somit ist es möglich in dem Request weitere ActionContainer zu kreieren und weiter Actions auszuführen.

Die Konfiguration der Globalen Filter findet in der global_filter.xml im Konfigurationsverzeichnis der Applikation statt. Hierbei bestimmt die Reihenfolge in welcher sie in der Datei aufgelistet werden in welcher Reihenfolge sie ausgeführt werden.

<filter name="FirstFilter"/>
<filter name="SecondFilter"/>

Hier würde der Filter mit dem Namen FirstFilter zuerst, danach dann der SecondFilter ausgeführt. Die Globalen Filter werden vom Controller geladen und auf gerufen. Hierbei gilt, dass der Controller explizit den Filter AgaviDispatchFilterregistriert und ihn dann gleich danach aufruft. In diesem wird das Response gesetzt, aus dem was noch kommt.

Action Filter

Action Filter sind, wie der Name auch schon sagt, für die Action gedacht. Die Grafik oben verdeutlicht dieses sehr gut. EineAction generiert uns ja in der passenden View das Output, welches vor der Ausgabe dann noch mit demFormPopulationFilter bearbeitet wird.

Bei den Action Filtern gibt es eine Besonderheit. Zum einen gibt es die Action Filter, die für jede Action aufgerufen werden und Spezial Action Filter die nur für eine bestimmt Action aufgerufen werden. Die Spezialfilter werden im app/Modulverzeichnis/config/action_filters.xml spezifiziert. Die Filter die für alle Actions gelten sollen werden inapp/config/action_filters.xml spezifiziert.
Zur der Reihenfolge der Ausführung ist zu sagen, dass erst die generellen und dann die speziellen.

Noch etwas sehr wichtiges, dass man bei dem entwerfen eines Action Filters nicht vergessen darf, ist das jeder Slot, jede ForwardAction ihre eigene FilterChain hat, welche die Filter nochmal durchläuft. Deswegen gibt es zwei Verschiedene Methoden in der Klasse. Die eine, executeOnce, wird immer für die “main” Action auf gerufen, die andere execute wird dann in den restlichen FilterChains auf gerufen. Sollte man aber wollen, dass der Filter beim ersten bis zum letzten Aufruf immer gleich aufgerufen wird, bedient sich die Klasse AgaviFilter dem Trick, dass executeOnce einfach execute aufruft. ExecuteOnce muss als explizier überschrieben werden.

Aufbau eines Filters

Filter sollten immer die Klasse AgaviFilter erweitern. Dort sind schon einmal die grundlegenden Funktionen definiert wie die oben beschriebene executeOnce Methode.

In dem nachfolgenden Beispiel implementieren wir die Klasse FooBarFilter. Diese kann entweder wie im Beispiel ein Klasse sein die sowohl Global als aus Action Filter ist oder nur eines von beiden. (Hier ist es zu Demonstrationszwecken so gewählt)

<?PHP
class FooBarFilter extends AgaviFilter implements AgaviIActionFilter, AgaviIGlobalFilter {
 
public function executeOnce(AgaviFilterChain $filterChain, AgaviExecutionContainer $container)
{
    /* Stuff to be done before the Rest of filters and Output generation is executed */
 
    /* Now we continue with the other filters. THIS MUST BE DONE!!! */
    $filterChain->execute($container);
 
    /* now to the Stuff which needs to be done afterwards. ie. Output transformation etc. */
}
}
?>

Das Beispiel oben hat zu dem nur die Methode executeOnce, was also heißt das der Filter pro Kontext nur einmal ausgeführt würde.

Weiter Infos zu und um Agavi gibt es auf http://www.agavi.org. Auch zu empfehlen ist der Agavi FAQ in dem einige interessante Themen rund um Agavi behandelt werde.

Keine verwandten Artikel gefunden.

Als erstes sollte man sich die Librarys von Doctrine besorgen. Ich selber speichere alle externen librarys im Verzeichnis %project_dir%/libs ab.

svn co http://svn.doctrine-project.org/tags/1.1.0/lib/ libs/doctrine

nun haben wir schon einmal die Librarys im Verzeichnis %project_dir%/lib/doctrine.

Konfiguration in Agavi

Damit Agavi nun diese auch läd müssen sie zur autoload.xml hinzugefügt werden.

<!-- Doctrine -->
<autoload name="Doctrine">/path/to/project/libs/doctrine/Doctrine.php</autoload>

Zum anderen sollte in settings.xml use_database auf true gesetzt werden, damit Agavi überhaupt zu Datenbanken verbindet. Als nächstes ist nun die database.xml an der Reihe. Die hier angegebene Konfiguration sollte immer an die eingenen Wünsche angepasst werden!

<?xml version="1.0" encoding="UTF-8"?>
<ae:configurations xmlns:ae="http://agavi.org/agavi/config/global/envelope/1.0" xmlns="http://agavi.org/agavi/config/parts/databases/1.0">
 
	<ae:configuration>
		<databases default="doctrine">
 
			<database name="doctrine" class="AgaviDoctrineDatabase">
				<ae:parameters>
					<ae:parameter name="dsn">mysql://<username>:<password>@<host>/<databasename></ae:parameter>
					<ae:parameter name="attributes">
						<ae:parameters>
							<ae:parameter name="AUTOLOAD_TABLE_CLASSES">true</ae:parameter>
							<ae:parameter name="VALIDATE">LENGTHS</ae:parameter>
							<ae:parameter name="AUTO_ACCESSOR_OVERRIDE">true</ae:parameter>
						</ae:parameters>
					</ae:parameter>
					<ae:parameter name="manager_attributes">
						<ae:parameters>
							<ae:parameter name="model_loading">conservative</ae:parameter>
						</ae:parameters>
					</ae:parameter>
					<ae:parameter name="load_models">%core.lib_dir%/doctrine</ae:parameter>
				</ae:parameters>
			</database>
 
		</databases>
	</ae:configuration>
 
</ae:configurations>

Entwicklungsumgebung

Hier habe ich mir angewöhnt die Sachen für die DB Entwicklung unter dev/db ab zuspeichern. Hier sollten folgende Verzeichnisse erstellt werden.

mkdir -p dev/db/{data,data/fixtures,data/sql,migrations,models,schema}

Zudem erzeugen wir in dev/db noch die Datei doctrine.php, welches wir zur Konfiguration der Doctrine CLI verweden werden. Auch hier gilt, bitte anpassen!

<?php
// Backup argv, otherwise stripped by agavi
$args = $_SERVER['argv'];
 
require('../../libs/agavi/agavi.php');
require('../../app/config.php');
 
Agavi::bootstrap('development.benjamin');
spl_autoload_register(array('Doctrine', 'autoload'));
// Let Agavi create the connection
$con = AgaviContext::getInstance('console')->getDatabaseConnection();
 
$dir = dirname(__FILE__);
 
$config = array(
	'data_fixtures_path'  => AgaviConfig::get('doctrine.fixture_dir', $dir . '/data/fixtures'),
	'models_path' => AgaviConfig::get('core.lib_dir') . '/doctrine',
	'migrations_path' =>  AgaviConfig::get('doctrine.migration_dir', $dir . '/migrations'),
	'sql_path' => AgaviConfig::get('doctrine.migration_dir', $dir . '/data/sql'),
	'yaml_schema_path' =>  AgaviConfig::get('doctrine.schema_dir', $dir . '/schema/schema.yml'),
	'generate_models_options' => array(
		'suffix' => '.class.php'
	)
);
 
// Configure Doctrine Cli
$cli = new Doctrine_Cli($config);
$cli->run($args);
?>

Kommen wir nun zur letzten kleine Hürde. Wir brauchen noch eine entsprechende Datei die uns die doctrine.php von oben aufruft. Diese platziere ich immer in dev/ und sie sieht so aus.

#!/usr/bin/env php

Noch ein abschließendes chmod +x doctrine und man kann los legen.

Keine verwandten Artikel gefunden.

Keine HTML Special Charaters verwenden

Warum nicht? Nun ja, ich habe mein Output auf XHTML & UTF-8 eingestellt, so dass ich mit dem FPF meine Formulare dynamische ausfüllen kann. Nun ist das Problem, wenn man z.B. eine Navigation erstellt, dass man Sonderzeichen wie “>>” oder “<<” benutzen möchte für Vor und Zurück. Das Problem welches hierbei auftritt ist, dass der FPF denkt, dies seien Open- bzw. Endtags was ihn letztendlich aus der Bahn wirft und uns einer Exception beschert. Aber nicht nur diese Zeichen auch an “&rarr;” verschluckt sich der FPF.

Deswegen ist es am besten, wenn man Sonderzeichen benutzen möchte, den numerischen Code dieser zu verwenden. Eine gut strukturierte Übersicht findet der interessierte Leser unter http://webdesign.about.com/library/bl_htmlcodes.htm

Keine verwandten Artikel gefunden.