Nerdpress.org » Javascript

Push-Mechanismen im Web sind mittlerweile weit verbreitet – die Anforderungen an die Infrastruktur aber recht hoch. Nichts geht ohne Plugins (Flash, Applet, WebSocket) – dann braucht man mindestens einen zweiten Server, der via persistenter Verbindung Nachrichten verteilt.

Bedient man sich herkömmlicher JavaScript-Technik, muss man mit aynchronen Ajax-Requests herumkaspern, sich mit Timeouts, Memory-Leaks und Cross-Domain-Sicherheitspolicen herumschlagen. Und auch hier kommt man nicht herum, den Server zu tweaken oder gleich einen zweiten aufzusetzen, der ausschließlich auf Polls oder Long-Polls trainiert ist.

Gerade in der PHP-Welt ist es nicht einfach, einen üblichen LAMP-Stack soweit zu bringen, dass so etwas auch unter Last funktioniert – Java ist da wie immer weiter und bietet mit JMS ein einheitliches Interface – da gibt es Software für den gewöhnlichen Servletcontainer, im Anwendungsserver muss das laut Spezifikation sogar im Lieferumfang enthalten sein.

Möchte man trotzdem mit “Bordmitteln” mal schnell eine Chatbox aufsetzen, führt Longpolling + Ajax eigentlich schnell zu einem akzeptablen Ergebnis – nichts für Millionen konkurrierende Zugriffe, aber immerhin eine nette Spielerei für zwischendurch. Wäre da nicht ständiges Warten auf die Response, das sich nach einiger Zeit einerseits mit einer merklichen Ruckelorgie bemerkbar macht oder gar den Mauszeiger in eine ewiglich drehende Sanduhr verwandelt.

HTML 5 to the rescue…

HTML 5 kann sogenannte Dedicated Worker – “echte” Workerthreads auf Betriebssystemebene, die man mit einer Zeile spawnen kann.

new Worker('meinScript.js')

Innerhalb eines Threads kann man lang laufende Rechenoperationen im Hintergrund verstecken – warum also nicht auch einen Ajax-Request? Allerdings haben diese Threads einen Nachteil: Aus Sicherheitsgründen laufen sie in einem klar abgegrenzten Scope, in dem sozusagen nichts vorhanden ist. Auch keine Referenz auf das document-Object der Elternseite. Das stoppt die meisten Javascript-Bibliotheken, wie bspw. JQuery. Man muss sich also mit Bordmitteln begnügen.

Eine Methode, die einen Worker initialisiert, könnte so aussehen:

    _initializeLongPoll: function()
    {
      var messenger = this;

      var worker = new Worker('my-ajax-worker.js');
        worker.onmessage = function(event)
        {
          var json = jQuery.parseJSON(event.data);

          // NEUE CHAT-NACHRICHT ERZEUGEN
          messenger.$_list.append($(''
            + '' + json.author + ''
            + '' + json.text + ''));
        };
    }

“my-ajax-worker.js” ist ausschließlich für den Ajax-Request zuständig. Hier wird ein dynamisches Javascript in einem Symfony-Projekt generiert:


    var onLoad = function()
    {
      var output = httpRequest.responseText;
      if (output) {

        // DELEGIERT DIE RESPONSE ZURÜCK.
        postMessage(output.trim());

        // ERZEUGE NEUEN XmlHttpRequest
        httpRequest = initRequest();
      }
    };

    // WIR SPAREN UND DEN X-BROWSER XmlHttpRequest-KRAM
    var httpRequest = initRequest();

Details zum serverseitigen Script möchte ich an dieser Stelle vernachlässigen, im Grunde funktioniert es folgendermaßen: Es arbeitet so lange, bis eine Änderung festzustellen ist. Erst bei Änderung wird die Response an den Client ausgeliefert (darum heißt es “Long-Polling”, weil ein Request ganz schön lange dauern kann):

while(true)
{
  if(newData())
  {
    return getNewData()
  }
  sleep(5);
}

Der Kram funktioniert natürlich nur in HTML5-Browsern, die das Worker-Objekt unterstützen. Dazu zählen Firefox 3.6, Google Chrome und natürlich Safari. Ob Opera es beherrscht, weiß ich nicht, ob der IE 8 es beherrscht, bezweifle ich. Aber wie gesagt: Es ist nur eine Spielerei und keine produktiv geeignete Anwendung. Demnächst schau ich mir auch mal die WebSocket API an…

Known Issues

Vorsicht mit session_start() und konkurrierenden (asynchronen) HTTP-Zugriffen. Im User-Sessionscope wird der Apache immer auf das Schließen einer Session warten, bis er dem nächsten Request erlaubt, die Session wieder “aufzunehmen”. Und im Normalfall dauert eine User-Session genau so lange wie die Request-Lifetime. Das führt dazu, dass bei 4 gleichzeitig abgefeuerten XmlHttpRequests diese trotzdem als Stack nach dem FIFO-Prinzip abgehandelt werden. Man verliert somit den Vorteil der Asynchronität. Es ist also zwingend erforderlich, die Session bereits vor dem Long-Poll-Loop abzuschließen (durch den Aufruf von session_write_close();

Next Level Javascript Error Tracking

Max Girkens — Sat, 10 Apr 2010 12:11:03 +0000

Exceptionhub protokolliert clientseitig auftretende Javascript Fehler.

* Logs all JavaScript errors (local or remote)
* Provides a stack trace to find the cause in all browsers
* Groups errors by cause
* Development and Production modes
* RSS feeds for errors

Einfach einbinden via Javascript im Seitenheader. Dann kriegt man schöne Statistiken über Javascript Fehler mit Browser und OS Infos, Mail-Notifications usw.

Ein bißchen wie Google Analytics.

Das ganze ist (noch) kostenlos während der betaPhase.

Auf die Idee clientseitige Fehler via Ajax auf dem Server zu loggen, wäre ich irgendwie garnicht gekommen. Andere Leute schon.
Trotzdem wundert es mich in Nachhinein fast dass es da nichts verbreiteteres gibt.
Das schreit ja eigentlich nach einem Symfony Plugin, oder?

Googlemap Zoom-Faktor automatisch berechnen

Max Girkens — Mon, 29 Mar 2010 15:03:28 +0000

pushing the boundaries

um den ZoomFaktor auf GoogleMaps dynamisch zu setzen,
je nachdem wie viele Marker man wo hat, kann man GLatLngBounds benutzen.

var bounds = new GLatLngBounds();

Mit jedem Marker der dazukommt erweitert man dann einfach die Grenzen:

bounds.extend( myGLatLng );

und schon kann man komfortabel Zoom und Center-Punkt rausbekommen.
So das alle Marker sichtbar sind.

map.setCenter ( bounds.getCenter(), map.getBoundsZoomLevel(bounds) );

jQuery UI 1.8

Max Girkens — Wed, 24 Mar 2010 14:12:20 +0000

die jQuery UI ist jetzt in Version 1.8 erschienen.

neben einer optimierten Codebasis

jQuery UI Core 71% smaller

gibt es auch wieder ein paar neue Widgets.

Wie z.B. das position widget, das ausgefallenere Positionierungs-Spielereien erlaubt:

“linke obere Ecke von diesem Element -20px 10px von der rechten unteren Ecke von $(‘#parent’) positionieren.”

function position() {
  $('#positionable').position({
    my: 'left top',
    at: 'right bottom',
    of: $('#parent'),
    offset: '-20 10'
  });
}

Kann man dann natürlich auch an Events hängen:

$("#parent").draggable({
  drag: function() { position(); }
});

Auch ein Autocomplete-Widget ist jetzt dabei (endlich !:)
sieht auch gut aus auf den ersten Blick.

Symfony und das Dojo Build System

Johannes Heinen — Sat, 30 Jan 2010 15:18:47 +0000

Das Dojo Toolkit bietet neben den offensichtlichen Features eines Full-Stack-Frameworks unter anderem mehrere “environment aware” Debug-Modi und eine Sammlung vonBuild-Scripten, die es dem Entwickler erlauben, das Framework zusammen mit den eigenen Frontend-Scripten und Stylesheets zu “kompilieren” und somit Bandbreite zu sparen bzw. Ladezeiten zu minimieren.

Dojo Baukausten

Standardmäßig lädt der Dojo-Core alle benötigten Pakete, die mittels dojo.require() angefordert werden, via XmlHttpRequest vom Server. Das kann je nach Projektumfang schonmal einige Sekunden in Anspruch nehmen, wenn plötzlich gefühlte 200 Sub-Requests beim Pageload abgefeuert werden.

Wenn es generell ans Deployment eines Web-Projekts geht, ist man daran interessiert, die Ladezeit von Scriptdateien oder Stylesheets zu minimieren, indem man zum Beispiel im ersten Schritt alle referenzierten Script-/CSS-Dateien in eine große Datei überträgt und damit konsolidiert. Dies kann mitunter mit Aufwand verbunden sein, wenn viele Scripte copied & pasted werden müssen, außerdem scheint diese Vorgehensweise nicht besonders elegant, noch dazu Fehleranfällig.

Im zweiten Schritt nutzt man üblicherweise so etwas wie Code-Obfuscating oder Code-Minimizing. Diese Techniken dienen in erster Linie dazu, die Datenmenge von Script-Quellen zu minimieren und damit die Downloadzeiten zu beschleunigen. Dies geschieht wiederum mit Hilfe von Shellscripten oder Mini-Programmen, die Quelltexte parsen und dann je nach Voreinstellung White-Spaces und Kommentare entfernen oder den ganzen Code überarbeiten, indem bspw. Variablennamen durch möglichst kleine Buchstabenkombinationen ersetzt werden um die Zeilenlänge zu begrenzen. Der Betrachter sieht dann in der Quelltextansicht nur noch eine lange, einzeilige “Code-Wurst”. “Disassembling” ist hier nur mit Aufwand möglich, aber prinzipiell eben das: möglich.

Die Dojo-Build-Tools automatisieren beide Schritte, wobei Schritt 1, die Code-Konsolidierung, durch das Dojo-Pakagesystem ermöglicht wird und Schritt 2 durch einen eingebauten Obfuscator, alternativ kann der Google Closure Compiler verwendet werden. Die Werkzeuge bestehen aus einigen .jar-Dateien, die in jeder halbwegs aktuellen Java Virtual Machine laufen und mittels $ java –classpath … aufgerufen werden. Ein paar freundlicherweise beigelegte Shellscripte bzw. .bat-Dateien vereinfachen den Aufruf.

Die Datei build.sh beispielsweise benötigt mindestens einen Zielparameter “profile”, der den Pfad zur Profildatei enthält. Diese Datei besteht aus einem JSON-Objekt und konfiguriert die Projektumgebung. Hier kann der Entwickler alle Dateien bzw. Namensräume angeben, die der Compiler berücksichtigen soll.

Optional anzugeben ist die Behandlung von CSS-Dateien, die Code-Minimierungsstrategie und so weiter. Ein $ build.sh liefert eine gut dokumentierte Liste der möglichen Argumente.

Somit lassen sich automatisiert alle eigenen Javascripts und die des Dojo Frameworks zusammen mit CSS-Stylesheets für die Produktionsumgebung “fit machen” und optimieren. Dokumentiert ist das ganze wie immer mäßig auf dem dojocampus.

Dojo und Symfony

Im Entwickleralltag möchte man seine Entwicklungsumgebungen zentral verwalten. Im Symfony-Kontext gibt es bspw. standardmäßig die Environments “Prod”, “Int” und “Dev”. Alle drei Umgebungen nutzen unterschiedliche Datenbanken, Loggingeinstellungen und so weiter. Natürlich liegt es nahe, die einzelnen Dojo-Builds ebenfalls “environment-aware” zu konfigurieren. Dies ist mit einigen einfachen Schritten erledigt, so könnte man bspw. das Script-Verzeichnis umgebungsabhängig verwalten. Doch so richtig optimal ist das nicht, und vor allem: Die Dojo-Build-Tools haben in der Form keine Entsprechnung als Symfony-Task, die Verheiratung wirkt also etwas widerwillig.

In so einem Fall lohnt sich natürlich der Blick ins Symfony Plugin Repository, und siehe da, das sfDojoPlugin erledigt den Job. Installieren, Dojo als Dependency herunterladen (ein großer Vorteil, somit ist man nicht auf eine eventuell veraltete bundled Version angewiesen), Filter einfügen, fertig. Schon gibt es einen neuen Symfony Task Namespace “dojo”.

$ symfony dojo:build-for-prod

kompiliert dann die Javascripts für die Produktionsumgebung, ohne dass zusätzlicher Konfigurationsaufwand anfällt. Das ganze funktioniert durch eine Namensraum-Konvention der Ordner, in denen das Plugin einerseits die Dojo-Sourcen erwartet und andererseits die komplierten Scriptdateien ablegt.

Ein weiteres Killer-Feature ist das einfache Injizieren von PHP-Variablen in den Javascript-Context, das hier weitestgehend automatisiert abläuft. Interessant in diesem Zusammenhang wäre vielleicht noch zu wissen, in wie weit die I18N-Features des Symfony-Frameworks mit denen der Dojo-Welt verheiratet sind.

Dojo passt also ab Werk bereits hervorragend in jedes Symfony-Projekt, und mit dem sfDojoPlugin lässt sich die Integration nahtlos bewerkstelligen. Hat man sich einmal an die schlechte Dokumentation und die wirklich steile Lernkurve gewöhnt, lässt man mit Dojo meiner Meinung nach in Punkto Stabilität, Funktionsumfang und Projektunterstützung erstmal so ziemlich alles andere hinter sich.

Links

Dojo Toolkit: http://www.dojotoolkit.org/

sfDojoPlugin: http://www.symfony-project.org/plugins/sfDojoPlugin

Eine Beispielimplementierung einer Webbasierten GUI-Komponente für die Build-Tools, leider auf Basis einer veralteten Version : http://build.dojotoolkit.org/0.4.2/web/buildscripts/webbuild/

Ebenfalls veraltet, aber sicher einen Blick wert: GUI für die Dojo Build Tools, Eclipse-basiert: http://shaneosullivan.wordpress.com/2007/01/29/second-beta-of-dojobuilder-released/

Juitter prettyDate

Ivo Bathke — Wed, 27 Jan 2010 11:07:42 +0000

Juitter ist ein Twitter Widget basierend auf jQuery. Damit kann man Twitter nach gewissen Keywords durchsuchen und die Anzeige als Widget mit wenig Code auf seiner Seite einbinden. Das alles ist rein clientseitig, was es noch einfacher macht.

Das geht so:
Juitter (1.0) runterladen, in sein Projekt kopieren.

Javascript einbinden:

Container in die Seite einbinden:

CSS einfügen:

#juitterContainer { overflow: auto; padding: 2px; font-size: 12px; height: 650px; width: 419px; border: 1px solid silver }
/*JUITTER PLUGIN CSS*/
#juitterContainer .twittList{margin:0;padding:0;} /* UL that will contain the list of tweets */
/* Bellow the list of tweets "" */
#juitterContainer .twittLI{list-style:none;background:#EEFDEA;margin:0;padding:5px 0 0 0;border-bottom:dashed 1px #CAF8C9;padding:3px;clear:both;height:55px;}
#juitterContainer .twittList SPAN.time{color:#777;font-size:0.9em}
#juitterContainer .twittList A{color:#006600;} /*Links inside the tweets list */
/* Bellow the CSS for the avatar image */
#juitterContainer .juitterAvatar{float:left;border:solid 1px #D3EECA;background:#FFF;margin-right:5px;padding:2px;width:48px;;height:48px;}
#juitterContainer .jRM{float:right;clear:both} /*read it on twitter link*/
#juitterContainer .extLink{} /*CSS for the external links*/
#juitterContainer .hashLink{} /*CSS for the hash links
*/ /*end of Juitter CSS*/

und fertig!

Die Konfiguration geht in der system.js.
Dort kann man die zu suchenden Keywords einstellen, die Update Intervalle und noch einiges mehr.

Was noch etwas verbesserungswürdig ist, ist die Datumsanzeige, hier nimmt Juitter ganz einfach das von Twitter übergebene RFC 2822 Datum und stellt es dar.

Das geht auch schöner!
Dazu hab ich das jQuery PrettyDate Plugin genommen und mit Juitter gebündelt.
Also Plugin noch einbinden:

Dann Juitter ein wenig aufgebohrt, so dass man nun in der system.js eine dateFormat option hat:

//set your Date Format:
//locale: uses JS toLocaleString
//pretty: uses prettyformat like so: 3 Days ago
//normal: RFC 2822 formatted date

dateFormat: "pretty"

Sprach Einstellungen für prettyDate sind auch möglich:

$.prettyDate.messages = {
now : "gerade eben",
minute : "vor einer Minute",
minutes : $.prettyDate.template("vor {0} Minuten"),
hour : "vor einer Stunde",
hours : $.prettyDate.template("vor {0} Stunden"),
yesterday : "Gestern", days : $.prettyDate.template("vor {0} Tagen"),
weeks : $.prettyDate.template("vor {0} Wochen")

}

Und schon ist es ein bißchen schicker!
Den Bundle gibts hier (juitter.dateimproved) zum download.
Alles weitgehend ungetested und ohne Gewähr.
Bleibt zu hoffen, dass es in die nächste Juitter Version integriert wird.

Textarea mit Code Highlighting

Ivo Bathke — Mon, 18 Jan 2010 16:35:25 +0000

Um eine HTML Textarea mit Code Highlighting zu versehen muss man ein bißchen tricksen.
Zum Glück gibts ja da schon fertige Libs, die das erledigen.
Sucht man mit Google, findet man schnell dieses hier:

http://codepress.sourceforge.net/
Dies wird aber scheinbar nicht weiterentwickelt und hat zudem einige Bugs.

Weiterhin gibts dann http://sourcepad.org.
Das sieht ganz gut aus, für meine Zwecke schon zu gut, daher habe ich mich für dieses entschieden:
http://marijn.haverbeke.nl/codemirror

Also der CodeMirror:
Installation ist einfach:
Runterladen, die nötigen Files einbinden:

Den linenumber style setzen (warum das nicht in der docs.css schon drin, fragt man sich?)

Eine Textarea anlegen:

und das Highlighting aktivieren:

    var editor = CodeMirror.fromTextArea('code', {
    height: "350px",
    width: "700px",
    parserfile: "parsexml.js",
    stylesheet: "css/xmlcolors.css",
    path: "js/",
    continuousScanning: 500,
    lineNumbers: true
  });

Das wars schon.
Die Konfigurationsmöglichkeiten werden im Manual ganz gut erklärt, da gibts dann weitere Infos.

Spannend wirds allerdings wenn nun die Form submitted werden soll um den geänderten Code zu verarbeiten.
Denn der Trick bei dieser, wie auch bei den anderen Libs ist, dass das die Textarea unsichtbar gemacht wird und stattdessen ein iFrame gerendert wird mit dem Highlighting.

Submitted man nun die Form, wird natürlich nicht der aktuelle Inhalt übertragen sondern unverändert der alte.
Um zu erreichen, dass der neue Inhalt übertragen wird, muss man vorher den Code aus dem iFrame holen und in die ursprungliche Textarea setzen.
Daher besser keinen Submit Button benutzen, da ein Submit direkt feuert.
Besser ein onclick auf einen normalen Button und eine javascript funktion zwischenschalten die den Transfer übernimmt und danach submittet.
CodeMirror bietet dafür, sehr praktisch, eine Funktion an, die einem den geänderten Code liefert: getCode()
Als prototype event sehe das dann so aus:

//button id=save
Event.observe('save','click',function(event) {
 	 	  $('code').value = editor.getCode();
		  $('form').submit();//die form mit id = form
});

So siehts aus:

coole sache!

Audio auf Webseiten mit SoundManager 2

Max Girkens — Sun, 29 Nov 2009 14:28:15 +0000

Audio auf Webseiten ist ja immer so ein Thema.
Die “nativen” HTML “Möglichkeiten” lassen wir mal lieber aussen vor.

Des Rätsels Lösung ist ja eigentlich meistens Flash – so auch bei Soundmanager 2.
Nur bleibt Flash hier komplett im Hintergrund und wird nur als “Ausgabegerät” missbraucht.

Sounds lassen sich dann mittles einer wirklich mal sehr coolen JS API einbinden, triggern und noch einiges mehr.
Dazu ist das ganze auch noch hervorragend dokumentiert.

Im einfachsten Fall sieht sowas dann so aus:

var mySoundObject = soundManager.createSound({
 id: 'mySound',
 url: '/audio/mysoundfile.mp3'
});

mySoundObject.play();

soweit so praktisch schonmal.
Die Performance ist übrigens ebensfalls hervorragend.

Richtig gut wird es dann, wenn man Flash 9 vorrausetzt:

waveformData array:
256 waveform data values available while playing sound

eqData array:
256 EQ spectrum data values available while playing sound

peakData object:
Left and right channel peak/volume data available while playing sound

damit lassen sich dann mal eben eigene Meter Darstellungen skripten. In JS.

someSoundObject.whileplaying = function() {
  // Move 256 absolutely-positioned 1x1-pixel DIVs, for example (ugly, but works)
  var gPixels = document.getElementById('graphPixels').getElementsByTagName('div');
  var gScale = 32; // draw -32 to +32px from "zero" (i.e., center Y-axis point)
  for (var i=0; i<256; i++) {
    graphPixels[i].style.top = (gScale+Math.ceil(this.waveformData[i]*-gScale))+'px';
  }
}

HTML Canvas beispiel : http://www.schillmania.com/projects/soundmanager2/demo/360-player/canvas-visualization.html

benutzt wird das ganze übrigens unter anderem von:
http://muxtape.com/
http://thecloudplayer.com/
http://8tracks.com/
und natürlich http://openchords.org ;)

lawnchair – a client side JSON document store

Max Girkens — Wed, 25 Nov 2009 13:04:01 +0000

Sorta like a couch except smaller and outside

JSON Daten clientseitig speichern und verfügbar halten.

“stores” nennt Lawnchair das dann.
Eigentlich ähnlich wie bei Propel und co. Nur halt ohne DB.

ich würde sagen die Syntax spricht in dem Fall für sich selbst:

var people = new Lawnchair('people');

// Saving a document
var me = {name:'brian'};
people.save(me);

// Saving a document async
people.save({name:'frank'}, function(r) {
    console.log(r);
});

// Specifying your own key
people.save({key:'whatever', name:'dracula'});

// Get that document
people.get(me.key, function(r){
    console.log(r);
});

// Returns all documents as an array to a callback
people.all(function(r){
    console.log(r);
});

// List all with shortcut syntax
people.all('console.log(r)');

// Remove a document directly
people.get(me.key, function(r){
    people.remove(me);
});

// Remove a document by key
people.save({key:'die', name:'duder'});
people.remove('die');

// Destroy all documents
people.nuke();

Nerdpress.org » Javascript

HTML5 – Sammlung von Ressourcen, Dokus und Browser-Fallbacks

Cross Browser Helper

Html 5 Validator (en)

Html5 Browser capability test (en)

Html readyness – fancy browser comparison (en)

Modernizr – Cross-Browser Html5 & CSS3 Support (en)

Html5Shiv – Html5 for IE (en)

IE-7 js – Standard complient IE 7 (en)

Html 5 CSS-Reset (en)

HTML 5 Boilerplate – Best Practices, Scripts und Server-Konfigurationen

Audio/Video

Html 5 Audio and Video – What you must know (en)

Video accessiblity (en)

Canvas

Canvas cheat sheet (en)

Reference Guide (de)

Canvas beginners guides (en)

Canvas demos & tutorials (en)

Cookbooks & Tutorials

WHATWG Weblog (en)

Html 5 laboratory (en)

Dive into Html 5 (en)

Html5 Playground (en)

Tag reference (en)

Fancy tag reference (en)

Html5 Techniques – Ultimate collection of tutorials (en)

Useful html 5 code snippets (en)

Geolocation using the Google API (en)

Fun with html5 forms

Blog-Artikel & andere Quellen

Webkrauts Artikel zum Thema (de)

What beautiful Html5 code looks like (en)

48 Flash killing HTML 5 demos (en)

HTML 5 facts & myths (en)

Learning to love html 5 (en)

Designing a html 5 layout from scratch (en)

Ajax (Fake) Push: Long Polling mit HTML 5 WebWorker