Heute geht es darum, wie wir uns eine einfache Plugin-Schnittstelle für unsere Objekte bauen können. Als Beispiel, wie sollte es auch anders sein, eignet sich unsere Custom_Model-Klasse aus meinen vergangenen Artikeln.
Zum Abschluss dieser Woche werden wir heute noch schnell das Observer-Pattern verbauen und dazu das passende Interface SplSubject implementieren. In dem Zusammenhang findet dann auch die Klasse SplObjectStorage eine sinnvolle Verwendung.
Nachdem sich unsere Klasse Custom_Model während der letzten Artikel gut entwickelt hat, werden wir daran heute gleich anknüpfen und das Iterator-Interface implementieren.
Was kann unser Model dann, was es vorher noch nicht konnte? Durch die Verwendung des Interfaces können wir die gespeicherten Daten in einer foreach-Schleife verarbeiten. Das kann z.B. beim erzeugen von Tabellen erforderlich sein.
Wie ich ja vor kurzem schon berichtet habe, bin ich dabei mich in die Shopsoftware Magento einzuarbeiten und dabei stolpere ich noch hin und wieder über das eine oder andere Feature. So zum Beispiel hatte ich den Fall, dass ich einen eigenen Observer nach einer Speicheraktion verwendet habe, der aber nicht im Adminbereich reagierte.
Die Lösung ist deratig einfach, wenn man es weiß… Die Einstellung für das jeweilige Event muss natürlich im richtigen Scope in der config.xml gemacht werden.
Ist der Beobachter nun also global eingestellt, klappt es auch in allen Bereichen. Andersherum lässt sich so aber auch eine unterschiedliche Verarbeitung für das selbe Ereignis einstellen.
Im Moment bin ich mit voller Begeisterung dabei, mich in die Magento Shopsoftware einzuarbeiten. Dass die Entwickler jedoch nicht nur die Software, sondern auch den Programmcode sehr flexibel gestaltet haben, macht die Sache leider nicht einfacher.
Viele Methoden sind mit __call() implementiert und das hat die Nachteile, dass z.B. die Codecompletion, Reflection, automatische Dokumentation oder die Navigation in der IDE ausgehebelt werden.
Zum Glück können wir das ja zum Teil in vererbten Klassen wieder abfangen, ohne die ursprünglichen Klassen umschreiben zu müssen, z.B. weil wir die fremden Libraries zwecks späterer Updates nicht verändern wollen.
<?php
class A
{
public function __call($method, $args)
{
echo __METHOD__ . ' ' . $method;
}
}
class B extends A
{
public function machWas()
{
parent::machWas();
}
}
$b = new B();
$b->machWas();
Die Methode B::machWas() delegiert den Aufruf an die magische Methode, wobei sich das Verhalten nach außen nicht verändert, jedoch alles andere wieder funktionieren wird.
Warum schreibe ich als Entwickler einen Artikel darüber, wie man einen vermeintlichen Schutzmechanismus umgeht? Ganz klar, weil die Dinger mich als Anwender nerven und ich sie auch als Entwickler nicht sinnvoll finde. Bevor ich aber nun einen Glaubenskrieg um Captcha-Bildchen entfache, werde ich nachfolgend erklären, warum diese nicht so sicher sind.
Heute geht es mal um ein Problem, dass in erster Linie neue Community-Portale betrifft. Eine Community lebt durch ihre Benutzer und gerade die haben wir am Anfang nicht. Ohne belebte Foren oder interessante aktive(!) Profile ist es auch schwer, neue Benutzer zu finden und diese zu überzeugen. Wir haben also ein Henne-Ei-Problem. Speziell für Seiten, deren Schwerpunkt die bezahlte Partnersuche ist, ist es natürlich lebenswichtig, ihre Nutzer lange bei Laune zu halten. Starthilfe ist gefragt!