Dez 18
JavaScript Template Parser
Bin eigentlich zur Zeit weniger mit dem Template beschäftigt und dachte, dass ich mir bereits sicher sei, wie ich es lösen würde, doch mir kommt nun eine neue Idee:
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.
Dezember 21st, 2008 at 23:41
Geniale Idee(!), ABER der Engpass ist die Datenbank daran wird sich so auch nichts ändern. Da die Templates auch Schleifen, If’s usw enthalten würde sich, meiner Meinung nach, der Traffic eher vergrößern.
Dezember 22nd, 2008 at 13:41
schließe mich meinem Vorposter an! Aber was verbesserte Seiten-Ladezeiten angeht.. bist du sicher? js ist nach meinen erfahrungen nicht gerade zu schnell…. wenn man nen ordentlichen server hat, der nicht überlastet ist, sollte das ganze bei nem ordentlichen php-aubau meiner meinung nach wesentlich schneller laufen, oder?
Dezember 22nd, 2008 at 14:23
Nehmen wir an, auch wenn das wahrscheinlich nicht die Endlösung sein wird, dass die Templates mit freiem Lesezugriff auf dem Server liegen, das gleiche gilt für die Sprachdateien. Das JS der Hauptseite läd automatisch das Template, ohne auch nur den Apachen anzustoßen, und füllt die Sprachvariablen ein. Nun (oder derweil) setzt es einen Request an ein PHP Script ab, das die dynamischen Daten erzeugt, welche dann ins Template gefüllt werden. Für einen Refresh müssen nun nur erneut die dynamischen Daten geladen werden, der Rest bleibt wie er ist. Besonders bei Widgets (zB Anzeige der PNs oder Angriffe) werden öfter aktualisiert. Dabei würde dann weniger Traffic entstehen und PHP muss selbst nicht mehr parsen.
Der Geschwindigkeitsvorteil wäre nicht übermäßig, aber vielleicht dennoch spürbar. Viel wichtiger ist das Sparen von Ressourcen.
Januar 15th, 2009 at 10:42
> Das JS der Hauptseite läd automatisch das Template, ohne auch nur den Apachen anzustoßen…
Wie soll das denn gehen, hast du noch ein anderen HTTP Server, der die Templates ausliefert?
Januar 15th, 2009 at 19:57
Gut, ob der Apache jetzt angestoßen wird oder nicht, jedenfalls verrichtet er keine Arbeit. Die Templates könnte man dann auch auslagern, ja.
März 2nd, 2009 at 22:56
[…] nun folgt die Entwicklung des MVC Modells, vor allem zugehörige JavaScript Algorithmen und mein JS-TemplateParser. Schätzen, wann es fertig wird traue ich mich noch nicht, besonders weil mein Abitur […]
April 4th, 2009 at 15:13
[…] Beispiel: JavaScript Templateparser […]
Juli 24th, 2009 at 20:59
Schau dir dann doch mal fertige JS-Frameworks an, ich hab für mich sehr gute Erfahrungen mit jQuery gemacht, da gäbe es auch entsprechende Plugins für ein JS-Template sowie eine History-Funktion, die so ähnlich wie das bei Facebook funktioniert (mit der eigentlichen URL hinterm # in der URL)
Juli 24th, 2009 at 21:36
Ich arbeite teils mit jQuery, aber bisher nur wirklich mit den Ajaxfunktionen, werde aber wahrscheinlich noch visuelle Spielereien mit jQuery einbauen. jBind (jQuery-Plugin) hat leider nicht meine Zwecke erfüllt, hab mittlerweile selbst etwas geschrieben und musste feststellen, dass dieses Plugin nicht gut geschrieben ist, noch ein Grund es nicht zu verwenden.
Als History werde ich dshistory verwenden.