$product->setWurst("Salami");
echo $product->getWurst();

Nach ein wenig Überlegung macht das Ganze auch in den Layouts Sinn.Beispiel: Im Header soll ein anderes Hintergrundbild angezeigt werden, wenn der Benutzer im Warenkorb ist. Gelöst wird sowas natürlich mittels einer CSS-Klasse für den Header. Der alte Weg würde so aussehen, dass man im Template header.phtml in etwa sowas einbaut:

<div id="header" class="<?php echo ($warenkorbAnzeige) ? "header-cart" : "header-default"; ?>">

Das ist natürlich nicht so schön, wenn es mehr als 2 Klassen gibt. Magento löst das jedoch schöner. Im Template schreibt man einfach:

<div id="header" class="<?php echo $this->getHeaderClass(); ?>">

Den Wert für HeaderClass kann man direkt in den Layouts setzen.

Beispiel in page.xml für alle Seiten:

<block name="top.container" as="topContainer" translate="label">
<action method="setHeaderClass"><value>header-default</value></action>
</block>

Beispiel in cart.xml für die CSS-Klasse im Warenkorb

<checkout_cart_index>
<reference name="topContainer">
<action method="setHeaderClass"><value>header-cart</value></action>
</reference>
</checkout_cart_index>

Ein Blick unter die Haube:

Eigentlich passiert nichts weiter, als dass die im XML angegebene Method für die Instanz des Blocks ausgeführt wird. Da jeder Block auf Varien_Object zurückzuführen ist, funktionieren die magischen Setter und Getter auch. Des Weiteren können auch alle public function einer Block-Klasse aus dem XML aufgerufen werden, auch wenn sie mehr als einen Parameter erfordern.

Beispiel:

1. Block-Klasse

<?php
 
Class FiveDigital_TestModul_Block_Foo extends Mage_Core_Template {
 
private $foo;
private $bar;
 
public function changeFoo($baz, $someVar) {
	$this->foo = $baz;	
	$this->bar = $someVar;
}
 
public function showFoo() {
	echo $this->foo." - ".$this->bar;
}
 
}
 
?>

2. Layout-XML

<testmodul_index_index>
	<reference name="content">
		<block type="testmodul/foo" name="fooBlock">
			<action method="changeFoo">
				<foo>Lorem</foo>
				<somevar>Ipsum</somevar>
			</action>
		</block>
	</reference>
</testmodul_index_index>

3. Template

<h1>Foo:</h1>
 
<p><?php echo $this->showFoo(); ?></p>

Update: Mein liebenswerter Kollege Alex hat mich auf einen kleinen Fehler im Beispiel hingewiesen, den ich nun korrigiert habe. Vielen Dank!

[Bindable]
 [Embed("images/icons/folder.png")]
 protected var MyFolderIcon:Class;
 
[Bindable]
 [Embed("images/icons/folder-open.png")]
 protected var MyFolderOpenIcon:Class;
 
<mx:Tree id="tree" defaultLeafIcon="{MyFolderIcon}"
 folderOpenIcon="{MyFolderOpenIcon}"
 folderClosedIcon="{MyFolderIcon}">

Durch den Einsatz von eigenen Grafiken für Blätter und Knoten wurde ein einheitliches Aussehen geschaffen. In der von mir entwickelten Anwendung löst ein Klick auf ein Element des Trees ein Event aus, das dazu führt das ein Datagrid alle Objekte die zu der ausgewählten Kategorie gehören, anzeigt.

Der Tree bietet die Möglichkeit, dass Elemente mittels Drag & Drop neu zu arrangieren. Dazu müssen lediglich einige Eigenschaften des Trees gesetzt werden.

<mx:Tree id="tree" defaultLeafIcon="{MyFolderIcon}"
 folderOpenIcon="{MyFolderOpenIcon}"
 folderClosedIcon="{MyFolderIcon}"
dragMoveEnabled="true" dragEnabled="true" dropEnabled="true">

Und schon kann der Tree beliebig sortiert werden. Ein Beispiel dazu liefert Adobe. Doch kann wirklich beliebig sortiert werden? Nein! Warum? Es ist nicht möglich ein Element “in” ein anderes herein zu schieben. Was bedeutet das für die Darstellung von Kategorien? Es ist nicht möglich eine Kategorie in eine andere Kategorie, die keine Kinder hat, zu verschieben. Dies fällt nicht nur mir auf, auch bei FlexExamples wurde dieses Verhalten bemängelt:

Rob McKeown November 30, 2007 at 2:12 pm

One thing to note about the tree is that it is really just a list in which items are displayed. What that means is, you can’t really drop somthing “into” folder unless the folder is open. Even in that case the user experience isn’t quite right. So try moving everything out of one of the folders and then collapse that empty folder. If you drop something “on” the folder, it actually winds up between the target folder and the one below or above. This is indicated by the black line showing up as you move the mouse over the folders. If you “open” the folder (the only way to tell it is open is by the arrow) and then try it, you end up with an additional drop zone that is basically the bottom half of the opened, empty folder. This is also indicated by the black lines position.

It would be better if the middle section of any item could always be the drop zone for “add to this folder” and the top and bottom edges could be for dropping above or below respectively.

Besser kann ich das Verhalten des Trees nicht beschreiben. Leider habe ich dieses Verhalten erst festgestellt, als ich das Verschieben der Kategorien bereits in Flex und im Webservice implementiert habe. Alles funktioniert, jedoch war es nicht möglich, eine Kategorie in eine andere ohne Kinder zu verschieben. So konnte es nicht bleiben, eine Workaround wurde benötigt.

Nach einigem Probieren kam ich zu dem Entschluss, dass es am einfachsten zu realisieren ist, indem einer Kategorie ein Kind hinzugefügt wird, wenn sie keiner Kinder besitzt. Der Ablauf sieht wie folgt aus:

• Der Benutzer zieht eine Kategorie
• Jedes mal, wenn der Benutzer die gezogene Kategorie über eine andere Kategorie zieht, wird ein Timer gestartet um zu messen, wie lange er über der Kategorie verweilt
• Ist eine bestimmte Zeit (in meiner Anwendung 2 Sekunden) erreicht und hat die Kategorie über der der Benutzer verweilt, wird der Kategorie ein Kind mit dem Titel “Als Unterkategorie einfügen” hinzugefügt
• Bewegt der Benutzer die gezogene Kategorie weiter, wird das neu hinzugefügte Kind wieder entfernt
• Nach erfolgtem Verschieben wird das Kind ebenfalls entfernt

Durch diese Technik ist es möglich geworden, dass Kategorien auch in andere, die keine Kinder haben, zu verschieben. In meinem nächsten Posting werde ich mich der Implementierung widmen. Dabei werden neben der, in diesem Posting beschriebenen, Problematik auch weitere Probleme behandelt. Wie verhindere ich, dass eine Kategorie in eine eigene Unterkategorie – und damit in sich selber, verschoben wird? Wie lese ich aus, wohin die Kategorie verschoben wurde, wenn die Datenquelle des Trees kein XML ist? Wie setze ich das Verschieben auf Seiten des Webservices um?

Setzt man Klassen ein, die Namespaces nutzen, wird der Namespace der Funktion übergeben. Benutzt man für sein Script eine Ordnerstruktur, die den Namespaces entspricht, ist es einfach aus dem Namespace heraus auf den Ordner in dem die Klasse liegt zu schließen.

Hier ein Beispiel:

function __autoload($className) {
 
	// Die Backslashes des Namespaces zu Slashes umwandeln
	$fileName = str_replace("\\", "/", $className).".php";
 
	if (file_exists($fileName)) {
		require_once $fileName;
	}
}

Natürlich setzt dieses Beispiel voraus, dass der Dateiname dem Klassennamen entspricht. Diese Konventionen sind in anderen Sprachen üblich. Noch einfacher geht es jedoch mittels der neuen SPL Funktionen. Dadurch reicht der folgende Aufruf:

spl_autoload_extensions(".php");
spl_autoload_register();

Die Funktionalität ist dieselbe, wie in der zuvor vorgestellten __autoload() Funktion, jedoch schneller, wie man einem Kommentar im PHP Manual entnehmen kann.

Ein Beispiel

Datei: \com\my\app\foo\Foo.php

namespace com\my\app\foo;
 
class Foo {
 
}

Datei: \com\my\app\bar\Bar.php

namespace com\my\app\bar;
 
class Bar {
 
}

Datei /index.php

use \com\my\app\bar as Bar;
 
spl_autoload_extensions(".php");
spl_autoload_register();
 
$foo = new \com\my\app\foo\Foo();
$bar = new Bar\Bar();

Wie dieses kleine Beispiel zeigt, funktioniert das Autoloading auch, wenn Namespace-Aliase eingesetzt werden.

Häufig jedoch ist dies nicht gewünscht und der Webservice muss abgesichert werden. Dazu gibt es viele Möglichkeiten, die alle ihre Vor- und Nachteile mit sich bringen. Für eine Anwendung an der ich zurzeit arbeite, greife ich auf eine bestehende Benutzerdatenbank zu. Wie es üblich ist, erfolgt der Login über eine E-Mail Adresse und ein als MD5 Hash in der Datenbank gespeichertes Passwort.

In diesem Artikel möchte ich auf die Authentifizierung mittels des Zend Frameworks eingehen.

Die Anwendung setzt auf Remote Objects und nutzt den Zend AMF Server als Gateway. Nachdem ein erster Entwurf der Anwendung angefertigt und der Webservice konzipiert und umgesetzt wurde, fehlte noch der Login auf meiner Liste. In vielen Tutorials wird mit einem Value Object für den Login gearbeitet. Das Login Fenster sendet Username und Passwort an den Webservice und wenn beide Angaben korrekt waren, wird die UserID (oder das User Objekt usw.) in der Session gespeichert.

Dieser gängige Ansatz hat jedoch den Nachteil, das ein neuer Login erforderlich ist, sobald die Session abgelaufen ist. Ein weiterer Nachteil ist es, dass für diesen Ansatz Cookies benötigt werden. Doch wieso nicht das Authtifizierungsmodell des AMF Protokolls benutzen? Der Zend AMF Server bietet seit geraumer Zeit Unterstützung dafür. In diesem Beitrag möchte ich auf die Implementierung eines solchen Authtifizierungsmodells eingehen.

Dabei kommen der aktuelle Flash Builder Beta 2 sowie das Zend Framework 1.9.5 zu Einsatz.

Der PHP Teil

In Kapitel 3.2.7. “Authentication” der Zend Framework Dokumentation wird in groben Zügen beschrieben, wie die Authentifizierung funktioniert:

Um Authentifizierung zu definieren, muß der Benutzer einen Authentifizierungs-Adapter anbieten der die abstrakte Klasse Zend_Amf_Auth_Abstract erweitert. Der Adapter sollte die authenticate() Methode implementieren so wie jeder normale Authentifizierungs-Adapter.

An dieser Stelle wird leider nicht weiter auf die Implementierung des Authentifizierungs-Adapters eingegangen. Es folgt noch ein kurzer Hinweis, wie die eigenen Authentifizierungs Klasse eingebunden wird:

$server->setAuth(new My_Amf_Auth());

Ein guter Hinweis ist die Klasse Zend_Amf_Auth_Abstract, die sich als reichlich simpel entpuppt:

abstract class Zend_Amf_Auth_Abstract implements Zend_Auth_Adapter_Interface
{
    protected $_username;
    protected $_password;
 
    public function setCredentials($username, $password) {
		$this->_username = $username;
		$this->_password = $password;
    }
}

Des Weiteren heißt es “Der Adapter sollte die authenticate() Methode implementieren” – richtig ist jedoch: Der Adapter muss die authenticate() Methode implementieren.  Es wäre schön, wenn die Klasse eine abstrakte Funktion authenticate() beinhalten würde.

Denn wenn der Zend AMF Gateway aus der Flex Anwendung die Credentials (Username und Passwort) gesendet bekommt und eine Auth Klasse gesetzt ist, wird automatisch die setCredentials() und anschließend die (von der eigenen Klasse implementierte) authenticate() Methode aufgerufen.

In Kapitel 5.1.1. der Zend Framework Dokumentation finden wir ein Beispiel, für eine authenticate() Methode:

    /**
     * Führt einen Authentifizierungs-Versuch durch
     *
     * @throws Zend_Auth_Adapter_Exception Wenn die Authentifizierung nicht
     *                                     durchgeführt wurde
     * @return Zend_Auth_Result
     */
    public function authenticate()
    {
        // ...
    }

Wieder ein Stück weiter ist jetzt bekannt, dass diese Methode ein Zend_Auth_Result Objekt zurück liefern muss. Ein Zend_Auth_Result Objekt erfordert (mindestens) 2 Parameter: Einen Code und eine Rolle. Auf die Rollen des Zend Frameworks möchte ich in diesem Beitrag nicht näher eingehen, deswegen kann an dieser Stelle ein beliebiger String oder ein beliebiges Objekt übergeben werden. Ein Beispiel für die zu verwendenden Codes befindet sich in Kapitel 5.1.2.

Die Zuvor erwähnt Klasse My_Amf_Auth könnte demnach wie folgt aussehen:

class My_Amf_Auth extends Zend_Amf_Auth_Abstract {
 
    public function authenticate() {
		$user = mysql_fetch_object(mysql_query("SELECT * FROM users WHERE username = ".$this->_username));
 
		// Username ungültig
		if (!is_object($user)) {
			return new Zend_Auth_Result(Zend_Auth_Result::FAILURE_IDENTITY_NOT_FOUND, "guest");
		}
 
		// Passwort ungültig
		if ($user->password != $this->_password) {
			return new Zend_Auth_Result(Zend_Auth_Result::FAILURE_CREDENTIAL_INVALID, "guest");
		}
 
		// User ist kein Admin
		if (!$user->isAdmin) {
			return new Zend_Auth_Result(Zend_Auth_Result::FAILURE_IDENTITY_AMBIGUOUS, "guest");
		}
 
		// User ist ein Admin
		return new Zend_Auth_Result(Zend_Auth_Result::SUCCESS, "admin");
	}
}

Der Flex Teil

Nachdem die Daten nun auf dem Server verarbeitet werden, stellt sich natürlich noch die Frage, wie Username und Passwort per Flex an die Remote Klassen gesendet werden können. Wenn man seine Webservice Abfragen mit dem eingebauten Daten/Dienste Manager erstellt hat, findet man in dem Paket des Services zwei Dateien: _Super_MyService.as und MyService.as. Die Super Klasse darf, wie man dem Quellcode auch entnehmen kann, nicht bearbeitet werden. Diese Datei wird automatich beim Aktualisieren der Services überschrieben. Stattdesses erweitert man die bisher noch leere MyService.as:

package services.myservice
{
	import mx.core.FlexGlobals;
 
	public class MyService extends _Super_MyService
	{
 
	}
}

In dieser Klasse mann man einen Konstruktor einfügen, der die Credentials setzt:

package services.categoryservice
{
	import mx.core.FlexGlobals;
 
	public class MyService extends _Super_MyService
	{
		public function MyService () {
			this._serviceControl.setCredentials("Username", "Password");
		}
	}
}

this._serviceControl ist das in der Super Klasse instanzierte RemoteObject:

_serviceControl = new RemoteObject();

Erzeugt man nun in einer Komponente eine neue MyService Instanz, werden Benutzername und Passwort automatisch gesetzt:

<fx:Declarations>
<s:CallResponder id="myResult" result="myResult_resultHandler(event)"/>
<myservice:MyService id="myData" showBusyCursor="true" fault="myService_faultHandler(event)"/>
</fx:Declarations>

Schöner ist es natürlich, Benutzername und Passwort nicht im Klartext in die Klassen einzutragen, sondern sie als Variablen über ein Loginfenster an die Klassen zu binden. Etwaige Fehler bei der Authentifizierung können mittels eines myService_faultHandler(event:FaultEvent) Listeners des MyService Objektes abgefangen werden.

Jetzt werden die Credentials im Header jeder AMF Anfrage mitgesendet. Ich empfehle, dass Passwort auf jeden Fall verschlüsselt zu senden, in meinem Fall als MD5 mittels des as3corelibs und den Webservice über ein HTTPS Protokoll anzusprechen. Mehr dazu gibt es in einem späteren Beitrag.

Sollte Interesse bestehen, kann ich auf weitere Aspekte dieses Authentifizierungsmethode eingeben und beantworte Fragen in den Kommentaren gerne so gut ich kann.