Piping Pipes

Yahoo! Pipes kann man wohl ohne weiteres zum Buzz of da month wählen, da schreibt ja zur Zeit jeder drüber. Da will man ja nicht zurückstehen.

Nick Bradbury (yep: FeedDemon, yo: TopStyle…!), hat einen wunderbaren, kurzen und noch dazu simplen Beispielartikel verfasst, den man sich unbedingt zu Gemüte führen sollte, bevor man daselbst einsteigt. Und los geht’s. Ausdrucken! 😉

dojo.query

Kurze Zusammenfassung: Dojo kann jetzt auch Queries. Der Rest: die üblichen Anfeindungen mit der mangelhaften Dojo-Dokumentation. 😉

Einer der Gründe, warum beispielsweise jQuery in letzte Zeit so ausgesprochene Erfolge zu verzeichnen hat, dürfte deren eingebaute Query-Language sein, also die Möglichkeit, über CSS- und/oder XPath-Queries auf DOM-Elemente zuzugreifen. Es kommt einfach ziemlich handy, wenn man mal eben in einem Rutsch alle <a> mit der Klasse .popup beispielsweise mit einem prima Klick-Ererignis verknüpfen kann. In jQuery sieht das ungefähr so einfach aus: $('a.popup').click(function(){alert('So einfach ist das!')});. Das macht die Zugriffe aufs DOM einierseits zu alles anderem als Hexenwerk und kommt anderseits ziemlich handy daher (zumal man speziell bei jQuery nun noch beliebig viele andere Methoden mit weiteren ‚.‘ an die Geschichte anhängen kann).

Das ist eine sinnvolle Sache, haben sich die Dojo-Entwickler gedacht, und prompt etwas ähnliches eingebaut: dojo.query. Buh, billig kopiert könnte man jetzt anmerken, oder: »Jungs, dokumentiert die Codemassen, die ihr so ausspuckt, doch erst mal richtig, eh‘ ihr mit neuen Features prahlt«. Letzteres hätte sicherlich durchaus seine Berechtigung, anderseits, wie gesagt: es ist einfach ein cooles Feature. Ob man nun damit angeben muss, dass Dojo diese Queries auf jeden Fall viel schneller ausführt, als alle anderen JS-Toolkits, ist eine müßige Angelegenheit und zeigt nur, dass die Entwickler der unterschiedlichen Frameworks tatsächlich irgendwie mitinander in Konkurrenz stehen, oder sich selbst setzen. Was eigentlich unnütz und kontraproduktiv ist, denn mir gefiele es besser, man besinne sich der Vorzüge des jeweiligen Frameworks, bei Dojo dürften das die Widgets sein. Stattdessen lernen wir, das Dojo über »div span span« in IE7 4mal so schnell iteriert, als jQuery. Schön…

Javascript on-demand, please

Eine der Königsdisziplinen beim »Ajaxifizieren« (grin!) einer Webseite ist es sicherlich, Javascript-Code nach dem Laden der Seite vom Server zu holen und auszuführen. Möglich ist dies beispielsweise via XHR: so macht es das Package Load System des Dojo Toolkits.

Auf Ajaxian kann man sich gerade ansehen, wie das funktioniert. Der auszuführende Code wird per XHR am Server abgeholt und per eval() zur Ausführung gebracht. Dabei lauern allerdings ein paar Fallstricke. Zunächst einmal sei darauf hingewiesen, dass eval() eine nicht ganz ungefährliche Funktion ist, denn was dort hineingepackt wird, wird auf dem Client ausgeführt, ist also so, als wenn man es selbst direkt in den Code geschrieben hätte. Um dabei kein Sicherheitsrisiko entstehen zu lassen, muss man sicher stellen, dass alles was an der eval-Methode ankommt, vertrauenswürdig ist.

Die restlichen Probleme die auftreten, liegen in der unterschiedlichen Art, wie verschiedene Browser eval() umsetzen. Firefox seht eval() als Methode von Object, IE sieht das natürlich anders. Ausserdem muss man den evaluierten Code schon global zur Verfügung stellen, denn sonst kann man ja später da nur noch schlecht drauf zugreifen. In Dojo wird dies mit eine globalen Variable dj_global relalisiert, IE kennt eine eigene Funktion execScript, die Code direkt in das window-Objekt evaluiert.

All das zusammen sieht dann so aus (übersetztes Beispiel von Ajaxian):

[syntax,on_demand.js.txt,javascript]

Das ist natürlich stark vereinfacht (der XHR selbst und seine Absicherung fehlen bspw.), aber so ungefähr kann das gehen. Anstatt wie Dojo eine eigene global Variable zu nutzen, kann man auch direkt das window-Objekt benutzen, also return window.eval ? window.eval(code) : eval(code).

Firebug im YUI-Theater

Yahoo macht ja nicht zu knapp Werbung für sein Javascript-Framework »Yahoo! User Interface Library« (kurz YUI), und das mit Fug und Recht sozusagen, denn YUI kann nicht nur einiges, das was es kann ist einfach hervorragend dokumentiert, es wird dazu ausgiebig gebloggt und mit dem YUI Theater wird eine Vielzahl von Lern-Videos angeboten,… also der gemeine DojoUserEntwickler kriegt da schon feuchte Augen…

Aktuell tritt im Theater gerade John Hewitt – bekannt als der Entwickler von Firebug – auf, mit Welcome to Firebug 1.0 (MP4-Download-Link). John stellt sein Wundertool vor, und gibt einige Tricks zum Besten. Vor allem die Profiler-Funktionen werden eindrucksvoll erklärt.

IDE: Aptana

Um ein wenig Javascript zu editieren, braucht man sich natürlich keine fette IDE installieren!

Ja, das stimmte sicherlich noch zu den Zeiten, als wir mit Javascript diese tollen Spuren programmiert haben, die den Mauszeiger verfolgten, nicht?! Heutzutage entwickelt man irgendwie im größeren Stil könnte man meinen, und da ist so eine IDE durchaus sinnvoll. Für Javascript empfehle ich da durch mal Aptana, die auf Eclipse aufsetzt: man kann Apatana einzeln und als Eclipse Plugin herunterladen (250.000 Leute haben das schon getan), ich empfehle letzteres, da man dann auch noch andere Funtkionen von Eclipse (bspw. Subversion, diverse PHP-Editoren etc.) kombineren kann. Alles an einem Ort sozusagen.

Aptana editiert ganz hervorragend JS-Files, CSS und HTML, stellt einen (leider etwas gewöhnungsbedürftiegn) (S)FTP-Client zu Verfügung und glänzt mit allerhand vorbereiteten JS-Frameworks, die beim Anlegen von Projekten ausgewählt werden können. Das reicht, um einiges mehr im Browser passieren zu lassen, als eine Mauszeigerverfolgung.

Webseminar: Web-2.0-Anwendungen absichern

Via Think PHP: mysql.de veranstaltet am 30. Januar ein Online-Seminar (ein Webinar sozusagen) zum o.g. Thema.

Die verbesserte Einsatztauglichkeit der Web-2.0-Anwendungen wird auf Kosten von neuen Sicherheitsproblemen erworben. Sowohl die mächtige Logik im JavaScript als auch der permanente Login auf vielen Sites bergen Risiken, die anders und gezielt beantwortet werden müssen. Dieses Webseminar gibt einen Überblick, bewertet die Probleme und stellt Lösungswege vor.

Wenn Sie Web 2.0- und AJAX-Anwendungen entwickeln, ist dieser Vortrag genau das Richtige für Sie! Hier erfahren Sie:

  • Welche neuen Sicherheitsrisiken es für Webanwendungen gibt
  • Welche Bedeutung XXS hat
  • Ursprünge und Typen von JavaScript-Malware
  • Wege zur Absicherung Ihrer LAMP-Anwendungen für Web 2.0

Ist gratis, online und eine Telefonkonferenz gibt’s auch. Nähere Infos und Anmeldung hier.

Encoding — irgendetwas geht immer schief

Character Encoding ist so eins der Dinge, die bei einem Webprojekt leicht schief gehen können, vor allem wenn man in einer heterogenen Umgebung arbeiten muss, also beispielsweise eine große Website aus etlichen verschiedenen Quellen, von unterschiedlichen Servern, aus verschiedenen Codejahrhunderten zusammen zu stricken hat. Natürlich könnte, müsste, sollte immer alles UTF-8 codiert sein: aber die Realität sieht leider anders aus. Denn selbst wenn man es schafft, alle Codequellen und Server abzustimmen, irgendwann kommt immer ein Benutzer mit der nordkoeranischen Version des Acrobat Readers 1.0 und hat mal eben daraus Text in ein Webformular gepastet…

Tommy Olsson bringt nun auf Sitepoint: The Definitive Guide to Web Character Encoding, ein hehres Ziel, will ich meinen. Und tatsächlich, der Artikel birgt wunderschöne Erklärungen: was ist das eigentlich »Character Encoding«, was passiert da, wie und wo stellt man es richtig ein und was passiert dann. Auf die Unwägbarkeiten des geplagten Integrationsentwicklers kann man da nur schwer eingehen, das sehe ich ein, also, wer von »Character Encoding« noch keinen Schimmer hat, unbedingt lesen.

Für die anderen ein paar Hinweise (teilweise auch siehe im genannten Artikel) gebündelt: Stellen an denen es mit dem Character Encoding gerne schief läuft:

  • Der Eintrag im HTML ist falsch oder fehlerhaft. Eigentlich immer die erste Stelle, wo man bei einer Webseite nachschauen sollte. <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> soll da im Header stehen. Man beachte auch, dass content den ganzen String, samt Semikolon enthält, also hier: text/html; charset=utf-8.
  • Ausserdem überschreibt der HTTP-Header des Servers (oder aus einem Programm) zwingend den Meta-Tag des Dokumentes. Also muss in der Apache-Konfiguration AddDefaultCharset UTF-8 gesetzt sein. Ist es so, aber es kommt trotzdem Müll, kann auch bspw. ein PHP-Programm den Header neu gesetzt haben. Man suche nach Stellen wie: header('Content-Type: application/xhtml+xml; charset=ISO-8859-1'); und, ach ja: in der php.ini gibt’s auch noch ein oder zwei Stellen, wo man mal nach default_charset diggen sollte.
  • Arbeitet man mit einen Javascript-Framework wie Dojo, kann man über Parameter bestimmen, in welchem Encoding Daten an den Server geschickt werden. Da haben wir aber teilweise richtige Schwierigkeiten bekommen, die wir auch nicht auflösen konnten – was so ein typisches Problembeispiel ist. Die Programmierer der Javascript- genauso wie der PHP-Seite behaupteten allesamt, dass ausschließlich mit UTF-8 gearbeitet würde, obwohl trotzdem Müll in der DB landete. Schlussendlich hat man sich auf einen Dojo-Bug geeinigt und serverseitig das Problem aufgefangen…
  • …was man aber eigentlich nicht tun sollte, denn: es ist im Grunde immer besser, wenn die Daten schon richtig ankommen, im Grunde ist dabei das Encoding egal, wenn es richtig ausgewiesen ist. Richtig blöd wird’s nur, wenn encodierte Daten nochmals encodiert werden. Das sieht zwar lustig aus…