In den 2 Monaten habe ich mich relativ schnell eingelebt und fühle mich hier rundum pudelwohl! Nicht nur die Kollegen sind der hammer, auch die Projekte die mir anvertraut wurden sind äußerst interessant und bieten jede menge Herausforderungen. Auf Qualität wird hier umheimlich geachtet was die starke Kundenzufriedenheit denke ich auch ausmacht. Ich selbst bin ja seit knapp einem halben Jahr auf einem Qualitätstrip, daher ist mir dieser Aspekt hier ziemlich schnell und positiv aufgefallen.

Als TYPO3 Association Silver Member ist die Bergisch Media dieses Jahr mit 3 Mitarbeitern auf den TYPO3 Developer Days vertreten. Ich freue mich dann dort das erste mal für Bergisch Media unterwegs zu sein!

1. Platz
Aktuelle Ausgabe des Magazins „Zukunft – leckere Webtrends“ + ein Open-Source T-Shirt

2 + 3 Platz
Aktuelle Ausgabe des Magazins „Zukunft – leckere Webtrends“

Einen Einblick in die aktuelle Ausgabe gibt es hier!

Ok, wie könnt Ihr teilnehmen ? Das ist relativ einfach, hinerlasst hier einen Kommentar oder ein Track-/Pingback auf dieses Seite. Ich werde dann nach dem Zufallsprinzip die jeweiligen Gewinner bestimmen.
Die Gewinne werden dann direkt von t3n versendet. Damit ich Kontakt zu den Gewinnern aufnehmen kann ist es wichtig das Ihr eine gültige E-Mail Adresse hinterlasst!

Den Gewinner des Platz 1. wird am 11.06 bestimmt und kontaktiert.
Die Gewinner von Platz 2 und 3 werden am 18.06 bestimmt und kontaktiert.

Viel spass und glück :-)

PS: Wenn Ihr das Magazin dann habt, schenkt den Seiten 122/123 besonders Aufmerksamkeit… der Artikel ist von mir :-) “TYPO3 und AJAX”

EDIT: Alle Gewinner wurden informiert! Damit ist das Gewinnspiel offiziell vorbei :-) Aber schon bald wird es ein neues geben!

In diesem Jahr läuft alles unter dem Motto “Getting things done” was bedeuten wird, das es keine gewohnten Vorträge mehr gibt, sondern  eher Workshops. Jeder Workshop soll dabei auf maximal 20 Teilnehmer begrenzt werden und knapp 4 Stunden gehen. Es soll jeweils 3 verschiedene Worksphops parallel ablaufen.

Ich werde da sein und bestimmt den ein und anderen Blog Eintrag live aus Elmshorn posten!

Wollen wir auch sofort zum Thema kommen! Um es in einem Satz zu sagen: Exceptions sind Ausnahmezustände die eine Möglichkeit bieten auf verschiedene kritische Bedingungen bzw. Fehler während des Programmablaufs zu reagieren. BAM!

Geschnallt ? :-) Wenn nicht, nicht schlimm! Der Artikel fängt ja jetzt erst richtig an!

Um bei meiner lieblings Sprache zu bleiben, das Exception Handling gibt es in PHP erst seit der Version 5. Dort ist Sie standardmäßig dabei! Es muss also nix installiert, konfiguriert oder aktiviert werden! Wenn Ihr also noch mit PHP 4 arbeitet, leuteee, geht mit der Zeit :-)

Ok, das Exception Handling bietet uns also eine Möglichkeit! Wie sieht diese Möglichkeit aus? In PHP und auch in andere Sprachen gibt es das try und catch Konstrukt. Mit throw werfen wir einen Fehler und mit catch fangen wir diesen Fehler und können entsprechend auf diesen reagieren! Um das Fangen von Exceptions zu ermöglichen, muss der jeweilige Code in dem wir einen Fehler vermuten würden in einem try Block umschlossen werden. Dabei muss jeder try Block mindestens einen catch Block besitzen! Mehrere catch Blöcke sind dabei natürlich zu genaueren Filterung von Fehlern möglich.

Damit wir uns das ein bischen besser vorstellen können gibts dazu auch direkt ein Beispiel

class TestClass {
    public function sayHello($name) {
        if (!$name) {
            throw new Exception('Der Name fehlt!');
        } else {
            echo 'Hello ' . $name;
        }
    }
}

$object = new TestClass;

try {
    $object->sayHello('Julian');
    $object->sayHello('');
    $object->sayHello('David');
} catch (Exception $error) {
    echo 'Exception abgefangen: ' . $error->getMessage();
}

echo 'Schönen Tag wünsche ich!';

Wir haben also eine Klasse TestClass. Diese besitzt eine Methode sayHello die uns freundlicherweise begrüßt wenn wir Ihr als Parameter einen Namen mit übergeben. Nette Methode oder ? Doch wenn wir Ihr unseren Namen nicht veraten ist das recht unfreundlich, daher wird Sie uns auch nicht Hallo sagen sondern wird mit einem Fehler schmeißen und uns darauf aufmerksam machen wollen!

Wir instanzieren also ein Objekt der Klasse TestClass. Dann kommt der try Block in dem wir unseren Code schreiben in dem wir evtl einen Fehler vermuten würden. Wir rufen die Methode sayHello auf und übergeben Ihr einen Namen “Julian”. “Julian”, in dem Fall ich, wird begrüßt! Dann rufen wir die Methode auf vergessen Ihr aber unseren Namen zu sagen! Oh Oh… Was macht die Methode, Sie wirft per throw eine Exception! Unser try catch Block bekommt davon sofort Wind und fängt diesen Fehler per catch ab!

Wie sieht unsere Ausgabe eigentlich aus ?

Hello Julian
Exception abgefangen: Der Name fehlt!
Schönen Tag wünsche ich!

Aber hey, ich habe nachdem ich bemerkt habe das ich meinen Namen vergessen hab doch direkt einen weiteren Aufruf hingeknallt! Warum wird David also nicht begrüßt ? Das ist ganz einfach! Nachdem in einem try Block eine Exception geworfen wurde wird innerherhalb des try Blocks nichts mehr ausgeführt! Der try Block wird also sofort verlassen und der rest des Scripts wird ausgeführt, daher wird uns also noch ein schöner Tag gewünscht!

Gut das Beispiel ist etwas blöd um den Sinn hinter dem Exception Handling zu demonstieren weil in diesem Beispiel hätten wir ja auch alles einfach über eine if else Bedingung steuern können. Exception Handling ist eigentlich auch nichts anderes wenn man es man grob betrachtet. Aber es bringt doch etliche Vorteile mit! Man braucht sich nicht mehr um Rückgabewerte kümmern, man schmeisst per throw einfach den Fehler! In etwas komplexeren Szenen kommt dort der Sinn und Zweck schon deutlich zum Vorschein! Würdet Ihr mit dem if Konstrukt arbeiten würdet Ihr sehr schnell in einem tiefen verschachtelten Dschungel landen :-)

Wollt Ihr verschiedene Arten von Fehlern behandeln, empfiehlt es sich, mit unterschiedlichen Fehlerklassen zu arbeiten. Höö?
Ja Ihr werdet staunen, aber wir können sehr einfach eigene Exception Klassen erstellen. Beispiel:

class unfreundlicherUser extends Exception {
    public function __construct($message) {
        parent::__construct($message);
    }
}

Wichtig dabei ist das a) unsere Klasse von der Basisklasse Exception erbt und b) das wir einen Konstruktor definieren damit die Fehlermeldung aufgenommen werden kann!
Unseren obigen Code könnten wir also wie folgt ändern, Ausgangsbasis ist, das uns der User verarschen will und einfach ein “x” eingibt weil er weiss das er was übergeben muss! Aber unser Programm soll auf eine Eingabe von einem “x” mit einem Fehler um sich schmeißen :-)

class TestClass {

    public function sayHello($name) {
        if (!$name) {
            throw new Exception('Der Name fehlt!');
        } elseif ('x' === $name) {
            throw new unfreundlicherUser('Ah Mr. X will uns seinen Namen nicht veraten!');
        } else {
            echo 'Hello ' . $name;
        }
    }

}

$object = new TestClass;

try {
    $object->sayHello('Julian');
    $object->sayHello('x');
} catch (Exception $error) {
    echo 'Exception abgefangen: ' . $error->getMessage();
} catch (unfreundlicherUser $error) {
    echo 'Exception abgefangen: ' . $error->getMessage();
}

$object->sayHello('David');

Wie wir sehen hat sich der Code erweitert. In der Methode sayHello wurde die Abfrage eingebaut wo der Name mit dem “x” verglichen wird. Hat der User also nur ein “x” eingegeben wird eine Exception vom Typ unfreundlichenUser geschmissen die wir vorher selbst definiert haben. An unseren ersten catch Block haben wir einen weiteren gehangen in dem die Fehler vom Typ unfreundlichenUser gefangen werden.

Ist doch super! Wir können also auf alle verschiedenen Fehler verschiedenen reagieren!

In unserem catch Block haben wir nebem getMessage noch mehrere Methoden die uns zur Verfügung stehen.
Darunter zählen

- getCode() zur Ausgabe eines Fehlercodes
- getFile() zur Ausgabe des Dateinamens in dem der Fehler geschmissen wurde
- getLine() die Zeile in dem der Fehler geschmissen wurde
- getTrace() liefert ein Array mit dem Stacktrace
- getTraceAsString() liefert den Stacktrace nicht als Array sondern als String

Wir sehen, es stehen uns reichlich Mittel zur Verfügung um auf jeden Fehler zu reagieren!

Ich hoffe mein Kollege David konnte sich mit dem Thema Exceptions jetzt ein wenig anfreunden und wird es in Zukunft in allen Projekten einsetzen :-)
Ich bin gespannt hehe… und euch hat es hoffentlich auch gefallen! Ein Kommentar und eine Bewertung hier unten würde mich wie immer freuen!

1) Vermeide SELECT * (sternchen)

Über SELECT * werden ALLE Spalten einer Tabelle eingelesen! Aber nicht immer benötigt man wirklich alle Spalten aus einer Tabelle! Meißt benötigt man nur 2-3 Spalten wie den “title” oder die “id” und trotzem ist man zu faul die Spaltennamen auszuschreiben. Also knallen wir einfach mal das * (sternchen) hin, ist ja einfacher nicht wahr?! Jaha… nur bei einem * (sternchen) werden wie gesagt ALLE Spalten einer Tabelle eingelesen und das kostet Performance.

Benötigen wir also zum Beispiel aus einer Tabelle nur die Spalte “id” und “title” sollten wir unbedingt darauf achten auch nur diese beiden Spalten einzulesen:

// Nicht empfehlenswert
$result = mysql_query('SELECT * FROM tabelle WHERE id = 1');

// Empfehlenswert
$result = mysql_query('SELECT id, title FROM tabelle WHERE id = 1');

2) Vermeide ORDER BY RAND()

Ein sehr beliebtes Feature! Sie möchten auf Ihrer Webseite per Zufall “einen” Artikel aus Ihrer Tabelle darstellen!
Was schreiben wir also, ganz easy:

$result = mysql_query('SELECT title FROM tabelle ORDER BY RAND() LIMIT 1');

Sehr cool! Wir bekommen also per Zufall immer nur einen Artikel (eine Row), ganz wie wir es uns vorgestellt haben!
Jedoch muss ich euch sagen, ORDER BY RANDOM() ernährt sich unheimlich gerne von unserer köstlichen und wertvollen Zutat namens Performance. Wie also können wir unsere Abfrage so optimieren dass wir das gleiche Ergebnis bekommen ?

Ganz einfach, wir besorgen uns erstmal die Anzahl aller verfügbaren Zeilen, generieren uns dann eine Zufallszahl zwischen 0 und der Gesamtanzahl und nutzen LIMIT :-)

Moment, *taschenrechner.. klick klick*… hum, das sind ja jetzt mehr Zeilen als mein schöner Einzeiler da! Ja richtig, aber er frist garantiert nicht so viel Performance! Also, hier der Code:

$result = mysql_query('SELECT COUNT(*) FROM tabelle);
$row = mysql_fetch_row($result);
$randomizeNumber = mt_rand(0, $row[0]-1);
$result = mysql_query('SELECT title FROM tabelle LIMIT ' . $randomizeNumber . ', 1');

Diese 4 Zeilen führen zum gleichen Ergebnis und sind nicht so Performancelastig.
Hier wird gezielt per LIMIT nur eine Row gelesen. Bei ORDER BY RAND() werden erst ALLE Rows gelesen und dann erst per LIMIT begrenzt.

3) Benutze LIMIT 1 bei eindeutigen Abfragen

Es kommt sehr oft vor das wir genau wissen welche Zeile wir brauchen. Also schreibt man folgende Query

$result = mysql_query('SELECT title FROM tabelle WHERE title = "Hello World"');

1 row in set (0.36 sec)

Wir wissen also daß wir nur eine Zeile zurückbekommen!
Auch hier können wir ein minimale Performacesteigerung erzwingen, und wie ? Naja, wir wissen das es nur eine Zeile gibt, lasst uns also ein LIMIT 1 dran hängen:

$result = mysql_query('SELECT id, title, crdate FROM tabelle WHERE title = "Hello World" LIMIT 1');

1 row in set (0.17 sec)

Auch wenn nicht wirklich spürbar, aber der Query ist schneller!
Wenn wir nach einer Spalte suchen die einen Index hat, wie zB die Spalte id, diese ist ja unique, macht es keinen Sinn da über den Index das Ergebnis schon rasend schnell geliefert wird.

4) Query Cache nutzen

Seit MySQL Version 4 steht uns der MySQL Query Cache zur Verfügung der in den meisten Fällen unsere Abfragen beschleunigt. Vorausgesetzt ist natürlich das dieser aktiviert und konfiguriert ist! Die Betonung im ersten Satz liegt übrigens auf “in den meisten Fällen” ;-)

Was macht dieser Query Cache genau ?
Hier werden Querys und deren Ergebnismengen abgespeichert. Wenn die gleiche Abfrage mehrmals benutzt wird und sich die betroffenen Datensätze nicht geändert haben, wird das Ergebnis aus diesem Cache geliefert anstatt eine neue Abfrage zu generieren.

Jetzt ist es so das wir als Programmierer eigentlich nichts spezielles beachten müssen. Unsere Querys landen eigentlich automatisch im Cache. Stop! Nicht immer! Nutzen wir in unserer Abfrage eine nichtdeterministische Funktion wird der Cache nicht benutzt!

Ok, halten wir mal kurz an! Ihr fragt euch jetzt bestimmt: “Was für eine Funktion ? nichtdeterwas ?” :-) hehe! Hier ein kleines Zitat aus der MySQL Doku:

Eine Prozedur oder Funktion gilt als “deterministisch”, wenn sie für gleiche Eingabeparameter immer gleiche Resultate erzeugt; ansonsten ist sie “nichtdeterministisch”. Wenn in der Definition der Routine weder DETERMINISTIC noch NOT DETERMINISTIC steht, ist die Voreinstellung NOT DETERMINISTIC.

Soweit klar ? Super… dann können wir ja weiter machen.
Also, sobald wir eine solche Funktion in unserer Abfrage nutzen wird nicht mehr mit dem Cache gearbeitet! Soweit klar, hier ein Beispiel:

$result = mysql_query('SELECT title FROM tabelle WHERE myDate <= CURDATE()');

Mit diesem Query holen wir uns alle Zeilen wo die Spalte “myDate” kleiner gleich dem aktuellen Datum ist! CURDATE ist in diesem Fall eine nichtdeterministische Funktion! NOW() oder RAND() wären andere Beispiele!

Diesen Query können wir natürlich optimieren. Und zwar so das auch der Cache benutzt wird. Wir verzichten einfach auf diese komische nichtdeterministische Funktion und nutzen ein wenig PHP

$curdate = date('Y-m-d');
$result = mysql_query('SELECT title FROM tabelle WHERE date <= ' . $curdate);

5) Nutze das Werkzeug EXPLAIN

Wenn man einer SELECT Anweisung das Schlüsselwort EXPLAIN voranstellt, zeigt MySQL Informationen des Optimierers zum Ausführungsplan der Abfrage an. MySQL erläutert also, wie es die SELECT-Anweisung verarbeiten würde, und gibt zudem an, wie und in welcher Reihenfolge Tabellen miteinander verknüpft werden.

Zitat aus der MySQL Doku : http://dev.mysql.com/doc/refman/5.1/de/explain.html

Super, bedeutet wir haben ein Werkzeug mit dessen Hilfe wir Step by Step einen SELECT Query optimieren können!

Wir können jetzt also beim entwickeln unserer Applikation jedes mal wenn wir einen SELECT bauen direkt schauen ob dieser performant ist! Da wir die Applikation ja gerade erst bauen, die Datenbank nur ein paar Testeinträge besitzt, geht alles in allem recht flot und wir stempeln unseren Query als Performant ab!

1 Jahr später, die Applikation ist gut besucht, die Datenbank ist fett mit wunderbaren Informationen gefüllt, fragen wir uns, warum ist meine Webseite so langsam. Als ich die gebaut hab war doch alles so schnell. Mit der Zeit hat sich viel verändert, als wir beim entwickeln getestet haben hatten wir auch noch keinen Bezug auf die Realität, keine volle Datenbank, keine X-hundert Hits am Tag!

Wir wollen also versuchen unsere Webseite im MySQL Bereich zu optimieren. Um jetzt nicht jede einzelne Query wieder zu suchen und von Hand zu testen nutzen wir ein wunderbares Feature! Wir können MySQL sagen ab welcher Ausführungszeit eine Abfrage als “zu langsam” gilt. Und diese lassen wir dann mitloggen! Extrem cool nicht war.. wir haben also jetzt eine Möglichkeit Querys ausfindig zu machen die langsam sind. Diese nehmen wir uns jetzt genauer unter die Lupe und zwar mit unserem Werkzeug EXPLAIN!

EXPLAIN analysiert unsere Abfrage und stellt dar was die Datenbank mit der Abfrage genau macht.
Beispiel:

$result = mysql_query('EXPLAIN SELECT title FROM tabelle');

Was uns das Ergebnis genau sagt können wir auf der MySQL Seite nachlesen: http://dev.mysql.com/doc/refman/5.1/de/explain.html eine ausführliche Antwort um dieses zu verstehen würde sonst diesen Beitrag sprengen :-)

6) Suchfelder indizieren

Oft müssen wir per MySQL nach irgendwelchen Sachen suchen. Nehmen wir an, wir haben einen selbstprogrammierten Blog. Der User möchte nach einem Artikel suchen wo er sich nur schwach an den Titel erinnern kann. Irgendwas mit “Hello” war das….

Statisch umgesetzt könnte das so aussehen:

$result = mysql_query('SELECT COUNT(*) FROM tabelle WHERE title LIKE "Hello%"');

Wenn wir uns die Zeit dazu mal anschauen sehen wir das das schon ziemlich lange dauert: 1 row in set (0.31 sec)

Also, legen wir einen INDEX auf die Spalte “title” in der gesucht werden soll:

[mysql]ALTER TABLE tabelle ADD INDEX (“title”);[/mysql]

Führen wir unseren Query erneut aus:

$result = mysql_query('SELECT COUNT(*) FROM tabelle WHERE title LIKE "Hello%"');

sieht unser Ergebnis schon ganz anders aus: 1 row in set (0.07 sec)

Mit einem INDEX kann man also extreme Performancesteigerungen erreichen!

Kleiner Tip: Wo welcher Index verwendet wird können wir ganz einfach mit der Abfrage

SHOW INDEX FROM tabelle;

rausbekommen!

Es gibt bestimmt noch dutzende weitere Möglichkeiten seine Scripte zu optimieren! Ich möchte hier aber erst mal einen Cut machen. Wenn Ihr noch gute Optimierungsmöglichkeiten kennt die ich hier mit aufnehmen sollte, benutzt bitte die Kommentarfunktion!

Jedenfalls hoffe ich das euch der Artikel gefallen und vor allem geholfen hat! Ihr könnt diesen Artikel auch unten Bewerten oder per Twitter ein wenig pushen :-)

Lieben Gruß
Julian

Verständlich oder ? Etwa nicht ? Keine Angst ich werde gleich ein Beispiel zeigen in dem das ganze dann deutlich wird!

Die Polymorphie gibt es in PHP nicht wirklich, warum? Weil PHP eine dynamisch getypte Programmiersprache ist, viele sagen eine typenlose Programmiersprache. Was so viel bedeutet wie, wir müssen den Variablen nicht fest vorgeben was in Ihnen gespeichert wird, ob ein String, ein Integer oder Double oder oder oder. Wir können jederzeit von einem Typ zum anderen wechseln.

In anderen Programmiersprachen wie Java zum Beispiel muss man jeder Variable sagen welcher Typ in Ihr gespeichert wird und diesen kann man dann nicht mal eben ändern bzw man kann keinen String in einer als Integer definierten Variable speichern. Das nennt man dann eine statisch getypte Programmiersprache.

Daher gibt es in PHP keine direkte Polymorphie. Um das ganze jetzt etwas deutlicher zu machen möchte ich euch ein Beispiel aus der Java Welt zeigen.

class MyClassName {

 public void methodName (int variableName) {
 // Es wurde ein Integer übergeben
 }

 public void methodName (String variableName) {
 // Es wurde ein String übergeben
 }

}

Würden wir die Methode “methodName” jetzt aufrufen und Ihr als Parameter einen Integer mit übergeben, würde die erste Methode auufgerufen werden. Rufen wir die gleiche Methode auf aber übergeben Ihr einen String als Parameter, wird die zweite Methode aufgerufen. Es wird also überprüft welcher Typ übergeben wurde und entsprechend mit den Typen der Methodensignatur verglichen.

Das gleiche können wir aber auch mit der Anzahl der Parameter machen

class MyClassName {

 public void methodName (int variableName, String variableName) {
 // Es wurde ein Integer und ein String übergeben
 }

 public void methodName (int variableName) {
 // Es wurde ein Integer übergeben
 }

}

Rufen wir die Methode “methodName” mit nur einem Parameter, einen Integer Parameter auf, wird die zweite Methode aufgerufen. Rufen wir aber die Methode mit einem Integer UND einem String Parameter auf, ja richtig, dann wird die zweite Methode aufgerufen.

Das bedeutet Vielgestaltigkeit!

Soviel dazu, jetzt habe ich aber gesagt das PHP eine typenlose Sprache ist. Daher dann die Deklaration von mehreren Methoden des gleichen Namens nicht verwendet werden. Wie klappt das dann in PHP ?

Es bieten sich folgende Möglichkeiten an:
Eine Methode kann einen Parameter akzeptieren der unterschiedliche Typen enthält. Über eine if Bedingungen überprüfen wir den Typen und agieren entsprechend

class MyClassName {

 public function methodName ($variableName) {
 if (is_string($variableName)) {
 // Die Variable ist ein String
 } elseif (is_integer($variableName)) {
 // Die Variable ist ein Integer
 } elseif (is_array($variableName)) {
 // Die Variable ist ein Array
 }
 // usw.
 }

}

Wenn noch fragen offen sind könnt Ihr gerne die Kommentarfunktion benutzen!

Nein, nicht wirklich. Der TYPO3 Recycler ist ein Backend Modul der einen Papierkorb wiederspiegelt.
Wir alle kennen ja den Papierkorb von unserem Betriebssystem. Löschen wir mal eine Datei bzw. einen Ordner ist dieser nicht wirklich gelöscht.
Er wird in den Papierkorb verschoben. Wir müssten um diese Dateien entgültig zu löschen also den Papierkorb leeren. Haben wir mal eine Datei ausversehen gelöscht, können wir in den Papierkorb gehen und die Datei wiederherstellen. Genauso arbeitet der TYPO3 Recycler. In TYPO3 werden Seiten  …und Seiteninhaltselemente nicht wirklich gelöscht. Sie werden in der Datenbank nur als deleted=1 markiert und sind somit in der Backend Oberfäche und im Frontend nicht mehr sichtbar. Existieren tuen Sie allerdings noch. Und genau diese Dateien zeigt der Recycler an. Wie auch auf dem Betriebssystem könnt ihr also in diesem Recycler Daten wiederherstellen bzw entgültig und unwiederruflich vom System löschen.

Das spannende am TYPO3 Recylcer ist das man rekursive wiederherstellen kann. Hat ein Redakteur oder gar ein Admin die Rechte im System rekursive zu löschen und nutzt diese evtl unwissentlich aus, kann es sein das mal eben der komplette Seitenbaum gelöscht wird. Viele stehen jetzt vor einem Problem. Nicht nur, das die Daten weg sind, Sie müssen es erstmal Ihrem Chef beibringen ;-)

Aber, alles kein Problem. Ein Sysadmin der weiss das die Daten noch in der Datenbank stehen, würde jetzt auf Datenbankebene hingehen und alle gelöschten Daten wiederherstellen. Aber, woher weiss er eigentlich welche er wiederherstellen soll und welche nicht, welche gehörten zum Seitenbaum und welche nicht. Und muss ich jetzt alles einzeln durchgehen, es gibt ja mehrere Tabellen… da kommt die große Frage auf: Wann habe ich endlich feierabend :-)

Diese Problem können wir mit wenigen Klicks umgehen. Recycler installieren, in den Recycler gehen, Weltkugel bzw die Mutterseite auswählen in der euer gelöschter Seitenbaum war. Die Seite auswählen, Wiederherstellen und ein Hacken bei Rekursive setzen, neuen Kaffee holen und warten bis Feierabend ist :-)

Natürlich könnt ihr auch einzelne Dateien wiederherstellen bzw entgültig löschen. Neben diesen Grundfunktionalitäten könnt ihr nach Dateien suchen und filtern.
Das ganze basiert auf dem Javascript Framework extJS.

Der TYPO3 Recycler ist seit der Version 4.3 bestandteil des Cores. Also eine Core Extension. Diese ist Standardmäßig nicht installiert. Ihr müsst also in den Extension Manager gehen und Sie kurz aktivieren. Danach könnt ihr den Recycler benutzen.

Aber noch ein paar Worte zur Entstehung des ganzen.
2005 habe ich mit TYPO3 angefangen. Damals suchte ich nach einem Projekt bei dem ich was lernen konnte und es gleichzeitig mit der Community teilen konnte.
Damals löschte ich ausversehen einen Seitenbaum und merkte schnell das es keine brauchbare Lösung gab. Also hatte ich mein Projekt gefunden. Ich gründete die TER Extension “kj_recycler”. Diese Extension ist mittlerweile recht veraltet und als Obsolete im TER noch zu finden. Schaut lieber nicht rein :-) Der Code stammt von meinen blutjungen Ersterfahrungen :-)

Jedenfalls fiel auf den TYPO3 Developer Days 2008, bei einer Featurewunschliste für TYPO3 4.3, der Satz “Improve record recycling concept”. Natürlich meldete ich mich direkt und übernahm diese Aufgabe. Eine Codeübernahme des kj_recyclers kam für mich nicht in frage da dieser total veraltet war. In der Zeit wurde bekannt das das Javascript Framework extJS fester bestandteil des Cores werden sollte. Das war für mich die perfekte Lösung. der Recylcer muss auf extJS basieren. Schwup die bub fing ich auch damit an. Mit Hilfe von Erik Frister, Steffen Kamper und Oliver Hader wurde aus dem Recycler das was er heute ist. Eine, nein, DIE erste auf extJS basierende TYPO3 Core Extension.

Ich freue mich mit dieser Idee und Umsetzung der Community zu helfen. Schon viele Mails habe ich bekommen in denen sich Leute einfach dafür bedanken das es diese Extension gibt und diese Ihnen in wahrsten Sinne den Arsch gerettet hat :-)

Wo ihr den Recyler finden könnt ?
Ihr benötigt mindestens die TYPO3 Version 4.3, damit habt ihr auch schon den Recycler, dieser muss nur über den Extension Manager aktiviert werden.

Die trunk Version findet Ihr im Forge

Vielleicht hilft diese Extension auch euch irgendwann mal :-)
Für eine kleines Dankeschön hier im Kommentarbereich würde ich mich sehr freuen!

Cheers
Julian

Grundlegend gibt es bei TYPO3 zwei verschiedene Wege im Frontend und einen im Backend über die man einen AJAX Request absetzen kann.
Da wäre im Frontend einmal der so genannte typeNum, wo man per GET Parameter den entsprechenen type mit übermittelt, und zum anderen gibt es den sogenannten eID Mechanismus. Ich werde zu beiden Wegen ein kleines Beispiel zeigen. Im Backend gibt es den Weg über die ajaxID. Dazu werde ich ganz zum Schluß noch ein paar Worte sagen!

Beginnen wir aber erst mit dem Frontend und mit den Grundlagen die beide Wege die ich genannt hatte benötigen.
Bedeutet, wir müssen erst einmal das jQuery Framework einbinden um eine entsprechende AJAX API nutzen zu können. Hierzu verwende ich immer folgendes Script:

jQuerySrc = 'fileadmin/js/jquery-min.js';

// only load jQuery if not present
if (typeof jQuery == 'undefined')  {
    document.write("<script type=\"text/javascript\" src=\"http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js\"></"+"script>");
}

// if Google is down
if (typeof jQuery == 'undefined') {
    document.write("<script type=\"text/javascript\" src=\"" + jQuerySrc + "\"></"+"script>");
}

Was passiert hier:  
Es wird überprüft ob jQuery schon eingebunden wurde. Es kann ja sein das per TypoScript oder einer anderen Extension das jQuery Framework schon in die Seite eingebunden ist und doppelt wollen wir es ja nicht haben. Wenn jQuery also noch nicht eingebunden wurde wird es von der Google API geholt. Sollte die Google API einmal down sein, was zu 99,99% nie der fall sein sollte,  überprüft eine weitere Bedingung erneut ob jQuery eingebunden wurde. Ist die Google API also mal down, lachen wir google erstmal kurz aus und lehnen uns wieder entspannt zurück, den es wird dann unsere lokale Version eingebunden. Ihr müsst dazu natürlich die jQuerySrc Variable entsprechend anpassen.

Soweit so gut, Grundstein ist gelegt, für Kaffee ist gesorgt, oder ? :-) Weiter gehts…

In unserem Beispiel gehen wir davon aus das ein Klick auf einen Button, der die id “triggerButton” als Attribut hat, den AJAX Request auslöst (der sogenannte Trigger – Auslöser).

In jQuery kann das so aussehen:

$('#triggerButton').bind('click', function() {
    // mache was
});

Sehr gut, Putzlappen raus, jetzt kommt AJAX zum Einsatz :-)
Innerhalb des click Events kommt jetzt unser AJAX Request rein der wie folgt aussehen kann

$.ajax({
    url: '',
    success: function(data) {

    },
    error: function(XMLHttpRequest, textStatus, errorThrown) {

    }
});

Das ist ein Aufruf mit grundlegenden Einstellungen, hier gibt es natürlich noch weitere Einstellungen um den Rückgabetyp zu definieren und und und, hier einfach mal in die AJAX API von jQuery schauen.

Die “url” erkläre ich gleich da hier die zwei unterschiedlichen Wege zum Einsatz kommen.
“success” wird aufgerufen wenn der Call erfolgreich war und “error” sofern ein Fehler aufgetreten ist! Beides sind funktionen in denen man dann entsprechende Aktionen auslösen kann!

Ok, fangen wir mit dem ersten Weg an:

Der typeNum!

Der typeNum sollte uns schon etwas sagen, den unsere Webseite basiert auf dem typeNum 0. 0 Ist dabei der default typeNum.
Gibt der user also die Domain euerer Webseite ein und gibt keinen “type” als GET Parameter ein, wird der default typeNum 0 genommen.
Das TypoScript sieht in den meisten Fällen so aus

page = PAGE
page.typeNum = 0
page.bodyTag = <body>

page.10 = TEMPLATE
page.10.template = FILE
page.10.template.file = fileadmin/index.html
page.10.workOnSubpart = DOCUMENT

page.10 {
 subparts {
   CONTENT < styles.content.get
 }

 # usw
} 

Ok, also, wir können also beliebig viele weitere typeNums definieren, diese müssen halt nur einmalig sein, da der letzte sonst immer gewinnen würde. Ihr kennt das Prinzip, TypoScript wird von oben nach unten eingelesen und wenn ihr Definitionen doppelt drin habt gewinnt immer der letzte!

Wunderbar, wir wollen also einen typNum definieren den wir für unsere AJAX Anfrage nutzen. Also, tragen wir folgendes im TypoScript Setup ein:

ajaxCall = PAGE
ajaxCall {
  typeNum = 5000
  10 < plugin.tx_unsereextension_pi1

  config {
    disableAllHeaderCode = 1
    xhtml_cleaning = 0
    admPanel = 0
    debug = 0
    no_cache = 1
  }
}

[Setzt voraus wir haben eine Extension "unsereextension" die installiert ist. Das kann eine recht einfache über den Kickstarter erstellte Extension sein die mindestens eine pi1 enthält]

Das TypoScript bewirkt das, wenn wir eine URL mit dem type=5000 aufrufen, das sofort an das Plugin tx_unsereextension_pi1 weitergeleitet wird und das was dort als return zurück kommt ausgegeben wird. Im Bereich config stellen wir noch ein paar Feinheiten ein, wie zB disableAllHeaderCode = 1 was bewirkt das wir unser Ergebnis als reinen Plaintext wieder bekommen ohne das der von TYPO3 generierte HTML Header etc. mit ausgegeben wird. Da wir auch keine anderen Ausgaben haben wollen deaktivieren wir auch das adminPanel und die debug Ausgabe und deaktivieren das Caching.

In unserer Extension steht aktuell folgendes in der main Methode
typo3conf/ext/unsereextension/pi1/class.tx_unsereextension_pi1.php

// ...

public function main($content, $conf) {
    return 'Das ist ein Test!';
} 

// ...

Um vorab einmal zu testen ob unser neu angelegter typeNum funktioniert rufen wir das ganze manuell auf. Gebt also euere Domain + den neuen type als GET Parameter an: http://www.domain.de/?type=5000

Als Ausgabe müssten wir jetzt sehen “Das ist ein Test!” und wenn wir in den Quellcode der Seite gucken dürfte dort auch KEIN HTML Tag etc. stehen sondern nur der reine Plaintext.

Sollte das nicht funktieren stellt bitte sicher ob ihr den Frontend Cache geleert habt :-) Ein häufiger Fehler wenn man nicht mit dem Template Modul arbeitet. Im Template Modul passiert das nämlich automatisch.

Aber wir gehen davon aus das alles geklappt hat und kümmern uns jetzt um das AJAX
Im AJAX Call tragen wir also in der “url” folgendes ein

$.ajax({
    url: '/?type=5000',
    success: function(result) {
        alert(result);
    },
});

Wenn jetzt auf den Button geklickt wird den wir als Trigger nutzen, müsste ein Alert erscheinen in dem steht: Das ist ein Test!
Ich würde sagen, glückwunsch! Ihr habt es geschafft!
Jetzt könnt Ihr mit jQuery das Ergebnis entsprechend verarbeiten.

Dem AJAX Call kann man natürlich auch noch Daten mit übergeben damit, anhand dieser Daten kann man im AJAX Script bestimmte Aktionen durchgeführen lassen!
Nehmen wir also an ihr wollt die FE User ID eines eingeloggten Users mit übergeben

var useruid = 1; // müsste dann dynamisch gefüllt werden

$.ajax({
    url: '/?type=5000',
    data: 'useruid=' + useruid,
    success: function(result) {
        alert(result);
    },
});

Der Aufruf sieht jetzt aber wie folgt aus: http://www.domain.de/?type=5000&useruid=X
Dementsprechend könnt ihr in euerem AJAX Script auf den GET Parameter zugreifen!

Möchte man die Extension mit mehreren verschiedenen typNums nutzen kann man in der Extension einfach folgendes machen

switch ($GLOBALS['TSFE']->type) {
  case 5000: // fuer typeNum 5000
    break;
  case 5001: // fuer typeNum 5001
    break;
  // usw
}

Der Vorteil bei dem Weg über typeNum ist das uns alle globalen Variablen wie das komplette TSFE mit cObj etc. zur Verfügung stehen. Bei dem Weg per eID musste man vor der TYPO3 Version 4.3 noch ein eigenes TSFE Objekt erzeugen. Seit der 4.3 bietet das das eID Script aber an womit wir direkt zum zweiten Weg kommen!

eID steht für Extension ID

Der eID Mechanismus ist  seit der Version 4.0 dabei!

Angesprochen wird er über einen GET oder POST Parameter. Sobald also eID als Parameter in der URL vorhanden ist, zB. www.domain.de/?eID=schuesselwort, wird der normale Prozess sehr früh abgebrochen und auf ein Script weitergeleitet was von uns vorher registriert wurde. Da der normale Prozess so früh abgebrochen wird kommt es auch noch zu keiner Ausgabe. Es wird nichts gecachet und kein HeaderCode etc. generiert. Wir bekommen also ein blankes Ergebnis unserer main Methode ausgegeben.

Wollen wir uns einmal die index_ts.php (typo3/sysext/cms/tslib/) Zeile 174 bis 185 ansehen.

// *********************
// Look for extension ID which will launch alternative output engine
// *********************
if ($temp_extId = t3lib_div::_GP('eID')) {
    if ($classPath = t3lib_div::getFileAbsFileName($TYPO3_CONF_VARS['FE']['eID_include'][$temp_extId])) {
        // Remove any output produced until now
        ob_clean();
        require($classPath);
    }
    exit;
}

Hier wird überprüft ob es einen GET bzw POST Parameter mit dem Namen eID gibt, sofern vorhanden wird geguckt ob dieser Key registriert wurde und der Pfad zu unserem Script wird in $classPath gespeichert und per require eingebunden. Danach folgt ein exit damit der restliche Prozess von TYPO3 nicht mehr ausgeführt wird.

Wie genau können wir unser Script registrieren ?

Das sagen wir dem System über $TYPO3_CONF_VARS['FE']['eID_include'][$temp_extId]
Wir müssten entweder in die localconf.php oder in eine ext_localconf.php einer Extension folgendes Eintragen

$TYPO3_CONF_VARS['FE']['eID_include']['helloworld'] = 'EXT:meinExtKey/meinScript.php';

Steht jetzt also in der Adresse www.domain.de/?eID=helloworld geht er in die erste if Abfrage und sieht das
$TYPO3_CONF_VARS['FE']['eID_include'][$temp_extId] vorhanden ist und speichert ‘EXT:meinExtKey/meinScript.php’ in die Variable $classPath und includiert unser Script.

Da unser Script noch leer ist bekommen wir eine weiße Seite angezeigt in der auch der komplette Quelltext leer ist.

Damit wir auch ein FE User Objekt, das TSFE Objekt und eine Datenbank Verbindung zur Verfügung haben, geben wir folgendes ein

$feUserObject = tslib_eidtools::initFeUser();
$TSFEObject = tslib_eidtools::getTSFE();

Die erste Zeile initialisert den Frontent User und gibt uns diesen als Objekt zurück. Dabei wird auch eine Verbindung zur Datenbank hergestellt.
Um jetzt noch das komplette TSFE zur Verfügung zu haben rufen wir in der zweiten Zeile die getTSFE Methode auf.
Im Weiteren können wir ganz normal auch TYPO3 Funktionalitäten benutzen und eine entsprechende Rückgabe an unseren AJAX Request geben.

Möchten wir zB explizit JSON als Format zurückgeben können wir im AJAX Call einen dataType definieren und im PHP einfach json_encode($content); zurück geben. Damit kann man in der success Funktion dann auf das JSON Objekt zugreifen. Beispiel:

$.ajax({
    url: '/?eID=helloworld',
    dataType: 'json',
    success: function(result) {
        alert('Hello ' + result.myResult);
    },
});

class unsereKlasse {

    public function main() {
        $feUserObject = tslib_eidtools::initFeUser();
        $TSFEObject = tslib_eidtools::getTSFE();
        return json_encode(array('myResult' => 'World'));
    }

}

$output = t3lib_div::makeInstance('unsereKlasse');
echo $output->main();

Das war es soweit zum Frontend. Kommen wir noch zum Backend, hier hatte ich ja gesagt das es einen Weg per ajaxID gibt.
Machen wir es kurz und schmerzlos :-)

Ihr habt eine Extension in der wir in die ext_localconf.php folgendes eintragen

$TYPO3_CONF_VARS['BE']['AJAX']['tx_extkey::helloworld'] = t3lib_extMgm::extPath($_EXTKEY) . 'classes/class.tx_extkey_helloworld_ajax.php:tx_extkey_helloworld_ajax->sayHello';

OHA, was ist das ;-) Gang einfach, ich schreibe es nochmal so

$TYPO3_CONF_VARS['BE']['AJAX']['tx_extkey::key'] = 'pfad/datei.php:klassenname->methodenname';

Ich denke jetzt ist es verständlicher und bedarf keiner weiteren Worte :-) oder doch ? Ok!
In unserer Datei class.tx_extkey_helloworld_ajax.php die im Ordner classes liegt gibt es also eine Klasse mit dem Namen tx_extkey_helloworld_ajax in der eine
Methode sayHello ist.

Mit dieser Zeile haben wir unser AJAX Script erstmal registriert!
Ein Aufruf aus einem Modul etc. ist jetzt relativ einfach

$url = $this->doc->backPath . 'ajax.php?ajaxID=tx_extkey::helloworld';

Diese Url ruft Ihr jetzt per AJAX API über jQuery oder extJS (seit 4.3 fest im Core) auf. Dabei wird dann die oben gannten Klasse->Methode aufgerufen und liefert das Ergebnis der Methode zurück.

So, der Kaffee ist leer und somit auch das Tutorial zu ende! Ich hoffe ich konnte euch einen kleinen grundlegenden Einstieg verschaffen. Wenn Ihr noch Fragen, Anregungen, Lob oder Kritik habt, nutzt bitte die Kommentarfunktion!

Cheers und bis zum nächsten mal,
Julian

Click here to view the embedded video.

Um sich weitere Eindrücke zu verschaffen gibt es im Forge weitere Screenshots

This book is about creating a remarkable career in software development. In most cases, remarkable careers don’t come by chance. They require thought, intention, action, and a willingness to change course when you’ve made mistakes. Most of us have been stumbling around letting our careers take us where they may. It’s time to take control. This revised and updated second edition lays out a strategy for planning and creating a radically successful life in software development (the first edition was released as My Job Went to India: 52 Ways To Save Your Job).

Das Buch gibt es als Paper und als eBook, für die die nicht so gerne englische Bücher lesen gibt es  eine deutsche Übersetzung vom “mitp” Verlag. Für alle Programmierer die eine Karriere anstreben und nicht auf einer Linie bleiben wollen ist das Buch ein Muss!

Das englische Original gibt es bei “The pragmatic bookshelf” (klick hier)

Die deutsche Übersetzung von Reinhard Engel gibt es beim “mitp” Verlag. (klick hier)

Über euere Meinung zu diesem Buch würde ich mich freuen, schreibt mir oder hinterlasst mir hier einen Kommentar!