Leider muss ich zugeben, dass ich in den letzten Wochen nicht wirklich vorwärts gekommen war. Fehlende Motviation und Wissen waren wohl die Gründe. Momentan begreife ich die Objekt-Orientierung in JavaScript, die doch relativ schwierig zu entdecken ist, zumindest war sie das für mich. Wohl einfach aufgrund der größtenteils funktionalen Verwendung von JS. JS OOP programmiert sich zudem ganz anders wie PHP OOP, weil JavaScript vorallem auf Prototypen setzt.

Bei einer Website können mittlerweile client- und serverseitig Skripte aufgerufen werden, der Trend tendiert zur Zeit vor allem zur Clientseite, wobei es immer noch der Server ist, der die wirkliche Validation übernehmen muss. Der Client bleibt manipulierbar und somit unsicher. Auch ich habe mich dem Trend angeschlossen. Dabei setze ich vor allem auf OOP in JS und verlagere so viel wie möglich in den Browser. So wird die Seite bei mir von JavaScript generiert und läd nicht neu. Alles läuft über XHR (XMLHttpRequests – AJAX) und JavaScript. JS bestimmt wie die Seite aussieht, der Server gibt nur noch den Rahmen vor, erlaubt bestimmte Dinge (Zugriffe auf Daten), die Aufbereitung übernimmt der Browser.

Im MVC Modell gesehen verwaltet JavaScript hier die Views und bekommt dafür auch Models zur Verfügung gestellt, wenn auch eingeschränkter als auf PHP-Seite. Die Models stehen trotzdem in einer gewissen Verbindung, auch wenn diese nicht stetig ist, weil ich nicht andauernd unnötige Requests abschicken will, das würde nur zu einer Serverüberlastung führen. Gleichzeitig erzeugt dies einen sehr praktischen clientseitigen Cache, den ich vielleicht von Google Gears unterstützen werde.

Momentan schreibe ich an der Verbindung zwischen Client und Server, die möglichst abstrahiert werden soll (zusammengefasst und einfach verfügbar gemacht) – auch für weitere Entwicklungen.

Für zukünftige Entwickler wird somit auf jeden Fall PHP sowie JS Erfahrung vorrausgesetzt werden. Das schöne an einem Framework ist allerdings, dass man es nicht verstehen muss um es zu benutzen, wenn es gut geschrieben ist und auf kritische Stellen hingewiesen wird. Dafür gibt es zum Glück dann eine Community und Tutorials, die geschrieben werden [uA von mir]. Daher keine Angst, wenn das jetzt alles wie spanisch klang, es wird viele Erklärungen geben.

Ich freue mich schon auf das Verbesserungspotential, das eine Community bietet, wenn man als OpenSource veröffentlicht. Diese Idee treibt mich auch weiterhin an, ich habe aber noch einige schwierige Dinge zu schreiben bevor ich mich überhaupt endlich dem Spielinhalt widmen kann, denn zur Zeit schreibe ich immer noch am Grundgerüst des Spiels, das möglichst variabel und erweiterbar sein soll.

Beispiel: JavaScript Templateparser

Ich stehe immer noch zu OOP und auch JavaScript untersützt OOP hochgradig, allerdings in einer für PHPler ungewohnten Form: mit Prototypes, ohne Klassen. Überhaupt ist in JavaScript alles ein Objekt oder – noch besser – eine Funktion! Ich habe hier keine Zeit eine JavaScript Einführung zu geben, ich bitte daher um selbständige Fortbildung um diesen Artikel verstehen zu können.

AJAX Requests sind asynchron, laufen also immer mit Callbacks. Ich verwende jQuery als JS-Framework.

$.get(url, function(data) {
    // callback code
});

Wenn ich nun mehrere Requests brauche, weil ich – im Falle des Templateparsers – Template, Sprache und Daten brauche, dann gibt das eine häßliche Verschachtelung:

$.get(tplurl, function(tpl) { // hole Template
    $.get(lngurl, function(lng) { // hole Sprache
        $.get(url, function(data) { // hole Daten
            $.bindTo(tpl, data, lng, '#content'); // parse das Template mit den Daten und der Sprache nach #content
        });
    });
});

Und das ist noch vereinfacht… Dabei hätte ich viel lieber, wobei die Templates und die Sprache gecacht werden sollen:

$.get(url, function(data) {
    $tpl(tplID).bindTo(data, lngID, '#content');
});

Nun.. wie bekommen wir das Callback weg?

Analyse des Problems:

Wir wollen anstatt eines Callbacks eine Verkettung per Punktschreibweise (Objektmethodenaufrufe), das bedeutet die Befehle die auf das Templateobjekt ausgeführt werden, werden höchstwahrscheinlich AJAX Requests beinhalten, auch wenn der Cache verwendet werden kann, müssen wir innerhalb mit Callbacks arbeiten, aber wir können sie nach außen hin verstecken, solange dem Coder gewahr ist, dass der bindTo-Aufruf auch asynchron ist. Für den Fall, dass man doch weiter abhängigen Code hat, führt kein Weg an weiteren Callbacks vorbei.

$tpl(tplID, callback).bindTo(data, params{lang,callback…})

Trotzdem wird das Aussehen komprimiert und etwas lese- und schreibfreundlicher.

Nun, wie ist das im Inneren gelöst?

Wir definieren zuerst eine Funktion get() (private), die das Template auftreibt, sei es aus dem Cache oder per Request. In beiden Fällen führt sie (oder der zugehörige Request) das interne Callback aus, sofern es gesetzt ist.

Das Objekt besitzt nun die public Methode bindTo, welche zuerst das interne Callback definiert (mit dem echten internen bindTo Code) und dann get() aufruft. Dazu kommen noch die beiden äußeren Callbacks von $tpl und bindTo, die wie das interne Callback am Ende von get() aufgerufen werden, sofern sie definiert sind.

Folge: Beim Aufruf von $tpl(tplID) passiert noch nichts besonderes, außer das ein Objekt zu Rückgabe gebildet wird. Der Aufruf von bindTo() auf dem Objekt stößt nun den Request an, welcher danach das echte bindTo ausführt!

So. Das wollte ich loswerden , vielleicht hilft es ja irgendwem oder animiert Leute JavaScript zu lernen…

Bei echtem Verwendungsinteresse des Codes einfach Mail an mich.