Letzte Woche habe ich mal grundsätzlich ein Markup auf gesetzt, bisher sind die Widgets (Menü, Planet, Resourcen, Gebäudeliste) aber noch statisch. Ich brauche dann auch bald einen Designer, damit ich mich nicht ewig mit dem CSS rumschlagen muss. Ich möchte auch ein Touch-Interface für Smartphones, damit man das Spiel gut unterwegs spielen kann.

Als nächstes möchte ich das Interface ein bischen dynamischer gestalten. Die Ressourcenverwaltung habe ich schonmal früher geschrieben, da waren jetzt aber noch eine Änderungen notwendig. An der Ressourcenberechnung habe ich schon lange gearbeitet (Implementierungen in PHP, MySQL und JavaScript).

Über die Gebäudeliste soll man dann als nächstes bauen können.

Ich habe mir mit der async Bibliothek einen eigenen Build Prozess gebaut, der meinen Code zusammenfasst und kompressieren kann und mich ein an die asyncrone I/O und den Callback-Stil gewöhnt. Nebenbei lerne ich an der Uni in Programmierparadigmen Haskell, die funktionale Sprache überhaupt. JavaScript mischt objektorientiert und funktional. Funktionale Programmierung hat durchaus gute Seiten, obwohl der Einstieg oder Umstieg von zB. Java schwierig sein kann. Besonders in Haskell ist Code deutlich kürzer, viele Dinge lassen sich mit einem Einzeiler erledigen. Sehr gut, dass in JavaScript Funktionen erster Klasse (first-class) sind.

Ich beobachte einige NodeJS Projekte über die Mailingliste und github, und habe begonnen einige auszuprobieren. Leider nicht immer mit Erfolg. Man merkt doch noch sehr, dass NodeJS noch sehr jung ist.

Erfolgreich habe ich live.js und underscore eingebunden. Mein Buildprozess ist in der Lage Dateien zu beobachten und live.js aktualisiert ständig HTML, CSS und JavaScript, so kann man Codeänderungen direkt im Browser beobachten.

So wirklich funktioniert browserify für mich nicht, ich werde wohl bei meinem eigenen Buildprozess bleiben und Dateien manuell hinzufügen. Ich brauche aber definitv eine Implementierung für require() im Browser, da werde ich evtl. ein wenig Code übernehmen.

Im letzten Artikel habe ich bereits über erste Erfahrungen mit NodeJS gesprochen: http://ugamela-blog.pheelgood.net/2011/04/29/nodejs/

Hier soll nun, ähnlich wie letztes Mal, ein Vergleich von Programmiersprachen stattfinden, wieder hinsichtlich der Entstehung eines Browsergames. Dies ist kein allgemeiner Vergleich und teils eine subjektive Meinung.

Des weiteren geht es um die Erschaffung eines OpenSource-Browsergames. Mit der Architektur stellt sich auch die Frage der richtigen Programmiersprache, die für diesen Fall am besten geeignet ist.

Die Platform ist für den Client – den Spieler – sein Browser, somit eine Website oder gar WebApplication. Hier steht nur eine Sprache zur Wahl: JavaScript. (Ich hasse Flash).

JavaScript wird mittlerweile von entwickelten Engines optimiert und sogar teils compiliert, auch größere Konstrukte sind im Browser möglich, es kann Rechenlast (Server->Client) ausgelagert werden.

Serverseitig ist die Auswahl größer. Letztlich lässt sich in fast jeder Sprache ein Server schreiben. Die meistverwendetsten sind wohl PHP, Java, Ruby, Python und Perl.

Java bleibt hier außen vor, und über Ruby (zu langsam) und Perl (zu häßlich) möchte ich nicht schreiben.

Entstehung:

JavaScript, PHP und Python hatten verschiedene Entstehungsbedingungen und Intentionen, sind daher auch für verschiedene Aufgaben geeigneter.

• PHP: Hypertext-Preprocessor. Als Templatesprache gedacht und dann für Webprogrammierung ausgeweitet.
• Python: Für besonders gute Lesbarkeit entwickelt. Allzwecksprache.
• JavaScript: Mehr Möglichkeiten zur Benutzerinteraktion auf Websites, HTML und CSS sind nicht turingvollständig. Komplizierte Entwicklung.

Zuletzt ist JavaScript stark beeinflusst durch den Browserkrieg. PHP ist etabliert, Python ist einfach schön.

Stil:

Prozedural, funktional, objektorientiert – das können alle drei, wobei prozedurale Programmierung in Python wohl Missbrauch wäre und PHP objektorientierte und funktionale Aspekte vor nicht allzu langer Zeit gelernt hat. JavaScript kommt mit einem minimalen Wortschatz aus und ist zudem klassenlos, kann aber Klassen ohne viel Aufwand nachbilden. Für mich ist ordentliche Objektorientierung wichtig. Der Prototypenbasierte Ansatz bei JavaScript gefällt mir.

Bedingungen:

Bei einem Browsergame ist eine Menge Kommunikation von Programmen erfordlich (Client-Server), besonders wenn es ein verteiltes System werden soll. Wobei jeder Server zumindest 100-1000 Spieler gleichzeitig aushalten sollte.

Platform:

PHP wird meist über (FastCGI) an einen Apachen oder anderen Webserver angebunden, der für jede Anfrage einen neuen Thread aufgemacht, der die Anfrage dann verarbeitet. Ein Thread hat jeweils einen eigenen Adressraum, teil sich keinen Arbeitsspeicher mit den anderen Threads. Für 100-1000 simultane Spieler braucht man dann halt einen leistungsstärkeren und teureren Server. Gleichzeitig konkurieren die Threads die ganze Zeit um die Datenbank.

NodeJS unterscheidet sich deutlich in der Architektur, welche aus dem Browser abstammt. Es gibt zwar die Möglichkeit Arbeit in Threads auszulagern, die sollte aber normalerweise nicht notwendig sein. Die Verarbeitung von Requests erfolgt ereignisgesteuert, Timeouts und Events werden von einer Schleife ausgeführt, die die ganze Zeit läuft (ein einziger Prozess). Abfragen mit verknüpfter Wartezeit (Datenbank, Dateisystem) werden asynchron ausgeführt. Während gewartet wird, widmet sich der Prozess eventuell bereits der nächsten HTTP-Anfrage.

Auch kommt hier eine Möglichkeit hinzu, die mir bei PHP gar nicht in den Sinn kam: Alle Requests teilen sich einen Adressraum und können auf den selben Arbeitsspeicher bzw. die selben Objekte im Code zugreifen. Deadlocks sind relativ unproblematisch, weil eh nur eine Anfrage zur Zeit verarbeitet wird. Natürlich gibt es Bibliotheken die auch für PHP Objekte im RAM cachen können, doch insgesamt gestaltet es sich deutlich einfacher in NodeJS. Das Array einfach eine Scope-Ebene drüber deklariert, und schon können alle darauf zugreifen. Ich plane die Datenbank komplett im RAM zu halten und alle paar Sekunden eine Schreiboperation an eine simple Datenbank zu schicken, die die Objekte versioniert (so kann dann im Falle eines Absturzes das Spiel wiederhergestellt werden).

Python ist auch in der Lage Objekte über den Applicationscope zu teilen.

Verbreitung:

Deutlich für PHP und Python spricht ihr Alter und ihre Verbreitung. Doch NodeJS ist gut dabei bald in die selbe Liga aufzusteigen. Gerade auch mit dem Cloud-Hype wird NodeJS immer beliebter. Ein kleiner Server mit NodeJS ist in der Amazon Cloud schnell installiert, aufrüsten gestaltet sich deutlich einfacher als auf einem normalen Server.

Frameworks:

Frameworks bilden sich für NodeJS erst langsam, da ist bei PHP und Python schon deutlich mehr Auswahl und Umfang enthalten. Mit Frameworks lässt sich natürlich Arbeit sparen, andererseits bläht es das System aber auch unnötig auf. Wieso ein großes Framework verwenden, wenn man denn doch nur einen kleinen Teil der Funktionalität braucht.

Fazit:

Es gibt keinen eindeutigen Sieger. Für mich selbst hat PHP allgemein verloren, weil ich an seine Grenzen gestoßen bin. Mit Python lässt sich in diesem Fall auch arbeiten, aber dann müssen Server- und Clientseite separat implementiert werden. NodeJS unterscheidet sich vor allem in der Herangehensweise und grundsätzlich in der asynchronen Architektur, da ist erstmal umdenken angesagt, wenn man vorher nur synchron programmiert hat.

Nach guten JavaScript-Prinzipien arbeitend, möchte ich natürlich nicht den globalen Namespace verschmutzen. Ich führe nur zwei Globals ein: Game und Phlame. Phlame ist das Framework, das ich baue. Grundlegende Abstraktionen werden dorthin ausgelagert. Bisher ist es nur eine Vorgabe für das MVC-Pattern, welche Klassen in Zukunft dorthin ausgelagert werden, habe ich noch nicht festgelegt. Wahrscheinlich wird dort auch die grundlegende Kommunikation mit dem/n Server/n abgelegt.

Ordnerstruktur:

/cfg Konfigurationsordner, ermöglich einfache Modifikationen am Spiel
/lib Library
    /Phlame Dateien des Phlame-Frameworks
    jquery.js
    ...
/style Aussehen des Spiels: Bilder, Cascading-Style-Sheets
/lang Sprachdateien
    /de
/src Source des Spiels
    /clientside
        /views
        ...
    /serverside
        ...
    ...
/spec jspec Tests
index.html Startseite
game.html Spielintern
admin.html Adminintern (externer Login)

Dateistruktur (Beispiel einer View):

(function() { // module pattern

//import
var $ = jQuery;
var View = Phlame.views.View;

//class or object declaration
function SolarsystemView(args) {
    View.apply(this); // inheritance
    var privateVar;

    this.priviledgedMethod = function() {
         // do something with privateVar
    };
}
//prototype inheritance
SolarsystemView.prototype = new View();
SolarsystemView.prototype.commonMethod = function() {
    // "this" available, but no privateVar(s)
};

//export
Game.views.Solarsystem = SolarsystemView;

})(); // end closure (module pattern)

Wie zusehen, verwende ich keinen Sugar für Klassendeklaration und Vererbung, weil ich finde, dassdiese Schreibweise nicht viel umständlicher ist und man so näher an der Natur von JavaScript arbeitet. Den einzigen Sugar, den ich mir leiste sind ECMA-262-3 Funktionen Object.prototype.create() und Function.prototype.bind().

Nachdem ich mich jetzt während des Sommers mit Objektorientierung, Softwarearchitektur und Entwurfsmustern beschäftigt hatte, suchte ich auch in JavaScript nach Mustern und Best Practice, und  nun möchte ich diese Erfahrungen auf meinem Blog teilen.

Vorab sollte erwähnt werden, dass JavaScript in mehreren Aspekten eine besondere Sprache ist. Es wird nicht umsonst geschmäht aufgrund unerklärlichen Verhaltens. Man sehe sich nur mal wtfjs an! Dennoch ist JavaScript auch sehr mächtig als objektorientierte Sprache. Closures und Prototypen sind recht unbekannt in der sehr von Java geprägten objektorientierten Welt. Die Umgewöhnung kann schwer fallen, auch ich hatte da meine Probleme. Zum Glück gibt es zum Beispiel Videos von Douglas Crockford auf YUI Theater, die einem helfen einen Einstieg zu finden.

Ich möchte nun hier zwei Funktionen vorstellen, die es auch in die neue ECMAScript Spezifikation geschafft haben: Function.prototype.bind und Object.create. Beide lassen sich mit einigen Tricks auch auf dem momentan verbreiteten JavaScript verwenden, bei Frameworks gehören sie zum Grundrepertoire.

Viel kann ich noch nicht zu prototypenbasierter Programmierung sagen, da ich selbst noch nicht ganz auf den Trichter gekommen bin, trotzdem habe ich schon Anwendungen gefunden und ziehe Nutzen in meinem sonst noch recht klassenbasierten Stil.

Object.create

if (typeof Object.create !== 'function') {
    Object.create = function (o) {
        function F() {}
        F.prototype = o;
        return new F();
    };
}

Diese schöne Funktion erzeugt ein Objekt auf Basis eines anderen Objekts, welches zum Prototypen wird. Vorsichtig muss man sein, wenn man lokale/private Variablen im Prototypen verwendet, da sich die beiden Objekte diese teilen. Der Prototyp sollte also ein neues Objekt sein, dass sonst nicht genutzt wird, oder die vermeintlichen Methoden müssen neu initialisiert werden, wie ich es in vorigem Blogeintrag mit dem aufrufen eines Konstruktors mache.

Ich möchte das Beispiel auch nochmal aufgreifen, wobei ich mittlerweile nochmal refaktorisiert habe.

Resource.prototype.create = function(newAmount) {
    var newResource = Object.create(this);
    Resource.call(newResource, newAmount, this.getType());
    return newResource;
};

Mit dieser Methode ist es möglich Objekte der selben Resource anhand einer vorliegenden zu erstellen. Theoretisch könnte ich diese Methode auch clone() nennen, da ich aber gleichzeitig das neue Objekt initialisiere, behalte ich den namen der Basisfunktion – create(). clone() lässt sich damit aber recht leicht verwirklichen, man muss nur die Eigenschaften vom alten Objekt übergeben.

Resource.prototype.clone = function() {
    return this.create(this.getAmount());
}

Schön, jetzt habe ich ein paar tolle neue Möglichkeiten Objekte zu erzeugen, was soll das nun?
Unter den Entwurfsmustern gibt es eine Untermenge: Creational Patterns, Muster zur Konstruktion. Einige Muster, die sich mit verschiedenen Möglichkeiten der Konstruktion von Objekten beschäftigen. Alle vermeiden die Konstruktion mittels “new <Klassenname>”, weil dies (unter anderem) zu statisch ist.
Wenn ich ein Objekt mit einer create() Methode übergebe, dann übergebe ich gleichzeitig die Möglichkeit ein neues Objekt des selben Typs zu erstellen, ohne mich explizit an den Typ zu binden. Die Konstruktion ist dynamisch. Aus diesem Grund kann ich auch leicht Vererbung anwenden ohne danach meinen ganzen Code nach “new <Elternklassenname>” durchsuchen zu müssen.

Function.prototype.bind

if (typeof Function.prototype.bind !== "function") {
    Function.prototype.bind = function(context) {
        if (arguments.length < 2 && typeof arguments[0] === "undefined") {
            return this;
        }
        var method = this, args = Array.prototype.slice.call(arguments, 1);
        return function() {
            var a = merge(args, arguments);
            return method.apply(context, a);
        };
    };
}

Den Code dieser Funktion habe ich mir aus dem Prototype Framework geholt und von Abhängigkeiten befreit. Jede Funktion und insbesondere Methode ist ab jetzt mit der Funktionalität ausgerüstet, unabhängig von ihrem Objekt gemacht zu werden.
Schonmal das probiert?

var func = someObject.someMethod;
func();

Das geht schwer in die Hose wenn someMethod “this” verwendet, “this” is dann nämlich “window” – eine der Freuden an JavaScript.
Stattdessen verwendet man besser:

var func = someObject.someMethod.bind();

Theoretisch kann man auch bereits Parameter mitgeben.
Diese Funktion findet häufig Verwendung, wenn man bei AJAX oder Effekten Callbacks übergibt und spart jedes Mal manuelles Umwickeln mit einer anonymen Funktion.

Die Tiefe von Patterns habe ich mit diesem Artikel wohl nicht erreicht, aber ich hoffe er ist trotzdem einigen Leuten hilfreich. Die vorgestellten Funktionen würde man wohl als Sugar (“Zucker”) bezeichnen.

Gleichzeitig handelt es sich um das Muster Wertobjekt (ValueObject), welches unveränderlich ist.

Vorweg muss noch gesagt werden, dass alle Attribute als Konvention protected gelten, public wird nicht benötigt und private lässt sich über Closures realisieren. Einfache Attribute tragen zudem den Anfangsbuchstaben ihres Typs (z.B. s für String).

Objekte der Klasse stellen eine Menge eines Rohstoffs dar.

/**
 * Represents an amount of a resource
 * @param {number} amount
 * @param {string} type
 */
function Resource(amount, type) {
    var nAmount = amount;
    var sType = type;

    if (amount < 0) {
        throw new IllegalArgumentException("amount has to be positive");
    }

    /**
     * @method Resource
     * @return {number} amount of the resource
     */
    this.getAmount = function() {
        return nAmount;
    };

    /**
     * @method Resource
     * @return {string} resource type
     */
    this.getType = function() {
        return sType;
    };
}

/**
 * Addition of two resources produces a new resource with the sum amount
 * the new object uses the old one as prototype
 * @param {Resource} resource
 * @return {Resource} new Resource object
 */
Resource.prototype.plus = function(resource) {
    if (!(resource instanceof Resource && this.getType() == resource.getType())) {
        throw new IllegalArgumentException("resources don't match.");
    }
    var newRes = Object.create(this); // create a new object based on the current one
    // execute the Resource constructor on it
    Resource.call(newRes, this.getAmount() + resource.getAmount(), this.getType());
    return newRes;
};

/**
 * Subtraction of two resources produces a new resource with a smaller amount
 * @param {Resource} resource
 * @return {Resource} new Resource object
 */
Resource.prototype.minus = function(resource) {
    if (!(resource instanceof Resource && this.getType() == resource.getType())) {
        throw new IllegalArgumentException("resources don't match.");
    }
    if (this.getAmount() < resource.getAmount()) {
        throw new IllegalArgumentException("can't substract a higher amount");
    }
    var newRes = Object.create(this);
    Resource.call(newRes, this.getAmount() - resource.getAmount(), this.getType());
    return newRes;
};

Interessant ist vor allem die Stelle, an der dynamisch neue Objekte der selben Klasse zurückgegeben werden (plus() und minus()), ich möchte Resource noch erweitern können und evtl. für die verschiedenen Rohstoffsorten eigene Klassen ableiten, daher sollten diese Methoden dann nicht nach einer mathematischen Operation auf die Klasse Resource zurückschrumpfen. In PHP kann man “new” einfach einen String übergeben, in Java muss man einen Umweg über eine Factory oder Reflection machen.

In JavaScript bietet es sich an, das momentane Objekt als Prototyp für das neue zu verwenden und dieses durch den Resource Konstruktor zu initialisieren.

Ich weiß noch nicht, ob mir dieses Pattern noch öfter begegnen wird, aber vor allem bei Wertobjekten (ValueObject), die mit Vererbung erweiterbar bleiben sollen ist dies praktisch. Allgemein wenn man ein neues Objekt des selben Typs wie das momentane zurückgeben möchte.

Jetzt kann ich eine Kindklasse ResourceContainer schreiben, die noch Funktionalität für Gewicht und Volumen des Rohstoffs bereitstellt (z.B zum Beladen von Schiffen):

/**
 * stores resources, adds weight and volume to a resource object
 * @inherits Resource
 * @param {Object} amount
 * @param {Object} type
 */
function ResourceContainer(amount, type) {
    Resource.call(this, amount, type); // inherit priviledged Resource methods
}
ResourceContainer.prototype = Object.create(Resource.prototype); // inherit nonpriviledged Resource methods

Resource.DESITY.metal = 7.85;
Resource.WEIGHT.metal = 1000;

/**
 * @return {number} weight of the resoure amount
 */
ResourceContainer.prototype.getWeight = function() {
    return this.getAmount() * Resource.WEIGHT[this.getType()];
};

/**
 * @return {number} volume of the resource amount
 */
ResourceContainer.prototype.getVolume = function() {
    return this.getAmount() * Resource.DENSITY[this.getType()];
};

Ich beginne langsam die Prototypennatur von JavaScript zu verwenden, bin aber immer noch sehr von Klassen von PHP und Java geprägt.

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.

Nun verwende ich zu großen Anteilen die zwei verbreitetsten Websprachen, die beide von vielen Leuten verachtet werden, weil sie vor allem von Amateuren verwendet werden.

Besonders JavaScript scheint eine interessante Vorgeschichte zu haben. Vor einigen Monaten, als ich anfing JS zu lernen, kam ich auf D. Crockford und habe mir seine Videovorträge angesehn. Ich habe JS somit direkt OOP gelernt, wie es sich eigentlich gehört. JS ist sehr objekt-orientiert, Crockford nennt sie “ausdrucksstark”. Die genau Übersetzung ist mir unklar, ist aber auch egal, denke ich.

Ich kann diesen Artikel nur empfehlen, notfalls auch übersetzt, für diejenigen die weniger gut Englisch können. Um Englisch kommt man aber beim Programmieren kaum herum und Crockford schreibt und redet eigentlich ein sehr gut verständliches und deutliches Englisch. Auch seine Videos kann ich nur weiterempfehlen, es lohnt sich!

Ich entwerfe also ein kleines Grundgerüst in JavaScript, das mit dem serverseitigen Teil, den ich in PHP geschrieben habe, zusammenarbeitet. Dabei ist vor allem der ganze AJAX-Kram sehr nervig. Da alles asyncron ist, muss man ständig mit Callbacks arbeiten (Man übergibt die Funktion, die ausgeführt wird, sobald der Request abgeschlossen ist und die Daten zur Verfügung stehen), was ständig zu Verschachtelungen führt, die ich eigentlich umgehen möchte.

Derweil feiere ich mein Abi und mache ein wenig Urlaub mit Freunden. Ich werde also nicht permanent hieran arbeiten, aber hoffentlich dennoch vorwärts kommen.

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.

Ich werde das Parsen der Templates auf den Client verlegen. Neuladen soll die Seite sowieso nicht mehr, Ajax wird eine große Rolle spielen.

Der Client läd zweierlei Dinge wenn er eine Seite anzeigen soll:

• Das Template, HTML Code mit Platzhaltern
• Die Daten als JSON oder XML

Der Browser füllt dann die Daten in das Template. Dabei kann man auch Schleifen für Listen verwenden.

Dabei wird praktischerweise der Server entlastet. Weniger Traffic und schnelleres Seitenladen sind weitere Folgen. Für Widgets, die sowieso oft aktualisiert werden müssen, wird nicht immer wieder das Template neu geladen, sondern immer nur neue Daten eingefüllt.

Dennoch werden einige Dinge nicht einfach zu implementieren. Erstens möchte ich mir nicht alles verbauen, das Spiel, wenn auch minimal ohne JavaScript laufen zu lassen, zumal es immer noch einige Browser gibt, die das nicht können (Handys). Des weiteren muss eine Art zurück/vorwärts-Funktion erstellt werden, da ja das Neuladen der Seite wegfällt.

Ich muss Wege finden, vereinzelte kleine Abfragen schnell durch den Komplex des Spiels zu schicken oder diesen zu umgehen um Zeit und Rechenleistung zu sparen. Dabei dürfen keine Sicherheitslücken entstehen.