Anzeige
Smartes Cloud Hosting für anspruchsvolle Projekte.
↬ Jetzt testen
Dr. Detlef Groth 8. Dezember 2006

Entwickeln, Debuggen und Loggen mit dem JSDebugger

Kein Beitragsbild

Die Debugging und Logging Tools für den Enwickler von JavaScript-Anwendungen reichen vom Ausgeben von Informationen mit der Alert-Funktion bis zum Steppen durch den Code mit dem Venkman-Debugger. Da Ersteres zu limitiert und Letzteres zu einarbeitungsintensiv und aufwändig ist, kann man beobachten das bei Skript-Problemen zumeist die JavaScript-Konsole von Opera oder Mozilla/Firefox genutzt wird. Wir stellen ein Weg vor bei dem das Entwickeln, Debuggen und Loggen direkt in der Webseite stattfindet.

Mit der zunehmenden Verbreitung von JavaScript/Ajax basierten Webanwendungen steigt auch der Bedarf an geeigneten Tools zum Debuggen und Loggen für die Programmiersprache JavaScript. Am meisten genutzt wird wohl die Alert-Funktion, der Ersatz für die fehlende Konsole im Webbrowser. In Schleifen kann daraus aber sehr schnell ein mühsames Wegklicken der Hinweis-Boxen werden. Allzu oft wird dann aber auch die richtige Box weggeklickt und zwar ohne dass man Sie gelesen hat.

Eine weitere Gefahr sind die Endlosschleifen – es bleibt dem Enwickler bei den Mozilla-Browsern und dem Internet Explorer nur die gesamte Browserinstanz abzuschießen… Wenigstens die neue Opera-Version verfügt über die Möglichkeit, die Script-Ausführung bei einem Alert abzubrechen. So kann man sich bei Opera 9 aus einem selbst verschuldeten Endlos-Loop mit integriertem Alert doch noch auf die sanfte Art befreien.

JavaScript Debuger
Neben dem einfachen Alert existieren auch höheren Ansprüchen genügende Tools wie der Venkman JavaScript-Debugger. Zumeist scheuen die Programmierer aber die langwierige Einarbeitung und das mühsame Steppen durch den Code mit Hilfe von Debuggern. Bei meinen Kollegen konnte ich ebenso wie bei mir beobachten, daß man doch wieder zu den Alert-Boxen oder im besseren Fall zur JavaScript-Konsole von Opera bzw. den Mozilla-Browsern zurückkehrt.

Allerdings ist es nicht möglich Debugging-Informationen, wie zum Beispiel den Wert bestimmter Variablen in die Konsole zu schreiben. Diese bietet allerdings sehr gute Hinweise auf JavaScript-Fehler, welche leider oft erst unter den Fehlern anderer Webseiten die in der gleichen Browserinstanz ablaufen herauszufiltern sind. Auch Entwickler benutzen ihren Browser eben nicht nur zum Programmieren. Nach eigenen Erfahrungen werden bei jedem Blick in die Konsole zuerst einmal alle Fehlermeldungen gelöscht, die Webseite anschließend neu geladen und danach wieder in die Konsole geschaut, um die selbst verursachten Fehler zu analysieren. Auch diese Methode ist natürlich nicht sehr effizient.

Log4js
Für das Loggen von Informationen über den Zustand der Webanwendung gibt es unter anderem das Framework Log4js . Es bietet eine ganze Reihe von Features, so zum Beispiel je nach Betriebssystem oder Browser-Unterstützung das Schreiben in externe Popup-Fenster, AjaxRequests oder in Text-Dateien. Wegen der Vielfalt der Optionen erfordert Log4js eine gewisse Einarbeitung. Nachteilig scheint ebenfalls zu sein, daß der Log nicht wieder einfach gelöscht oder den verschiedenen Kategorien oder Log-Levels gemäß angezeigt werden kann.

Fvlogger
Hier geht der Fvlogger von David Miller einen Schritt weiter. Anstatt ein eigenes Browser-Fenster zu öffnen, werden die Logging-Informationen direkt in das Dokument geschrieben. Verschiedene Log-Levels lassen sich selektiv ein- und ausblenden. Der Log kann komplett gelöscht werden. JavaScript-Fehler werden abgefangen und im Log angezeigt. Das Logger-Templates wird mit Copy und Paste in die eigene Webapplikation eingefügt. Ein etwas umständliches und fehleranfälliges Verfahren. Diesem Problem erliegt offenbar auch der Autor. Die Datei, die man sich von der Artikelseite herunterladen kann, enthält einige kleinere Typos, welche die Funktionalität beeinträchtigen.

JSDebugger
Nachdem ich die Vor- und Nachteile der vorgestellten Tools abgewogen hatte, stellte ich folgende Anforderungen an ein geeignetes Werkzeug zum Entwickeln von Webanwendungen:

  • Einfaches Einbinden in die Webseite
  • Möglichkeit den Debugger unabhängig vom übrigen Inhalt anzuordnen
  • Selektives Anzeigen der verschiedenen Log-Level
  • Scrollen durch den Log-Inhalt
  • Möglichkeit des Löschens des Log-Inhalts
  • Direktes Eingeben von JavaScript-Code in die Webseite durch ein Textfenster
  • Direktes Eingeben von Stylesheet-Code in die Webseite durch ein Textfenster
  • Integration von nützlichen Bookmarklets

Einbinden des Debuggers
Durch die Einbettung des JSDebuggers als extra Komponente in das JSComponents-Framework ist es lediglich notwendig, die entsprechenden JavaScript-Dateien und Stylesheets im Datei-Header einzutragen. Außerdem muss im Dokument-Body ein leerer DIV-Container mit dem Class-Attribut und einem Wert JSDebugger eingetragen werden. Soll der Debugger verschiebbar angeordnet sein, so daß er nicht das normale Aussehen der Webseite verändert, so wird der DIV-Container des JSDebuggers von einem weiteren DIV-Container der Klasse JSDragArea eingeschlossen. Außerdem gibt man in diesem Container die Style-Angaben für die anfängliche Position des Containers an. Ein einfaches Beispiel zeigt der folgende HTML-Code.

Beispiel 1:

 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
       "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>jsDebugger</title>
<script src="jsc/jsComponents.js"
type="text/javascript"> </script>
<script src="jsc/extra/jsDebugger.js"
type="text/javascript"> </script>
<script src="jsc/extra/jsDebuggerTools.js"
type="text/javascript"> </script>
<link rel="stylesheet" type="text/css" href="jsc/jsComponents.css" />
<link rel="stylesheet" type="text/css" href="jsc/extra/jsDebugger.css" />
</head>
<body>
<!-- BEGIN SOURCE -->
<div id="jsdebugger" class="JSDragArea"
style="position:absolute;top:50px; left:50px;">
<div class="JSDebugger"> </div>
</div>
<!-- END SOURCE -->
<h4>Test</h4>
<p>Some Content</p>

</body>
</html>

JavaScript- und Stylesheet-Code zur Laufzeit editieren
Mit der Programmiersprache Tcl hat man bei der Entwicklung von Benutzerinterfaces mit dem Tk-Toolkit gute Erfahrungen mit dem so genannten Live-Programmieren gemacht. Dabei wird entweder der Code direkt innerhalb der laufenden Applikation geschrieben oder vom Editor wird mit einer Tastenkombination die aktuelle Definition einer Prozedur oder Klasse an die laufende Anwendung gesendet. Es entspricht in etwa dem WYSIWYG-Ansatz der Textverarbeitung.

Man kann dieses Verfahren durchaus mit einer Operation am lebenden Organismus vergleichen. Das sonst übliche Verfahren: Code im Editor ändern, speichern, Datei im Browser auffrischen, mit mehreren Klicks sich an den vorherigen Zustand der Anwendung heranarbeiten, um endlich zu erfahren, ob die Änderungen in der beabsichtigten Weise wirksam geworden sind, wirkt im Vergleich dazu reichlich antiquiert und umständlich. Möglichkeiten dieses Live-Editierens für Stylesheets bieten zum Beispiel die Developer-Extensions für die Mozilla-Browser und die Addresszeile der Browsers für JavaScript-Code. Die Integration dieser Möglichkeiten direkt in die Webseite innerhalb eines Textfeldes direkt im Debugger, macht dieses Verfahren aber erheblich komfortabler.

Man kann sagen, dass dadurch aus der Einbahnstrasse Editor->Browser eine vorteilhafte Normalstrasse Editor<->Browser wird. Auch vom Browser kann Code aus dem Textfenster nach der Testung in den Editor wandern und dort abgespeichert zu werden. Ich selbst habe es für die Entwicklung des JSDebuggers genutzt, um so zum Beispiel Besonderheiten des Internet Explorers beim Behandeln von Stylesheet-Code einzuarbeiten.

Live-Programmieren im Textfenster

Bookmarklets einbinden
Bookmarklets kleine in JavaScript geschriebene Programme, die als Lesezeichen gespeichert werden, sind nützliche Tools die in vielen Fällen in browserunabhängiger Weise bei der Entwicklung von Webanwendungen helfen können. Teilweise bieten Bookmarklets ähnliche Funktionalität wie die bereits erwähnten Webdeveloper-Extensions für die Firefox- und Mozilla-Browser.

Mit den Bookmarklets hat man jedoch das gleiche Problem wie mit den Lesezeichen: ist man mit mehreren Browsern an unterschiedlichen Orten unterwegs oder testet man seine Anwendungen auf den diversen Browsern, kommt man um die aufwendige Verwaltung der Lesezeichen und damit der Bookmarklets nicht herum. Deswegen lag die Idee nahe, die Bookmarklets direkt in den Debugger einzubinden und Sie für das Loggen in die Debugger-Konsole anzupassen.

Damit Anwender Ihre eigenen Tools oder die erwähnten Bookmarklets leichter in den JSDebugger einbinden können, wurde diese Funktionaliät in eine eigene Datei ausgelagert (jsDebuggerTools.js). Statt sich um die Verwaltung seiner Bookmarklets zu bemühen, lädt man einfach den Debugger in seine Webseite und und hat sie sofort zur Hand.

Benutzung des JSDebuggers
Um den JSDebugger innerhalb der eigenen Webanwendung benutzen zu können, werden die entprechenden Dateien im Header des Dokumentes, wie im Beispiel oben angegeben, eingebunden. Danach stehen dem Programmierer die folgenden Methoden innerhalb seines Programmiercodes zur Verfügung: debug(message), print(message), bench(n,message,func), warn(message) und error(message). Dabei sollten warn und error für zur Laufzeit auftretende problematische Situationen eingesetzt werden.

Die Funktion fatal wird bei konkreten Laufzeitfehlern direkt durch den Browser aufgerufen. Durch das Klicken auf die entsprechenden Tabs können die ensprechenden Debug-Levels selektiv angezeigt werden. Unterhalb der Logger-Konsole befinden sich Tabs für die Eingabe von JavaScript- und Stylesheet-Code. Dort stehen auch die Funktionen loadScript(js-url) und loadStyle(css-url) zum dynamischen Laden von JavaScript- und Stylesheet-Dateien zur Verfügung.

Außerdem können im Tools-Bereich eigene Skripte durch das Editieren der Datei jsDebuggerTools.js eingebunden werden. Der Code dazu sollte in der Datei jsDebuggerTools geschrieben werden. Beispielcode dafür ist in der Zip-Datei bereits vorhanden. Da jede Webanwendung nur ein body.onload-Ereignis verarbeiten kann, sollten eigene body.onload-Funktionen mit addLoadEvent(func) hinzugefügt werden.

Ein Demonstrationsseite für das Beispiel – in einem neuen Fenster.

Da der Debugger von einem DIV-Container der Klasse JSDragArea eingeschlossen ist, kann die Konsole mit der Maus verschoben werden.

Soll der Debugger versteckt in der Webanwendung weiterlaufen und nur noch bei Bedarf durch den Entwickler angezeigt werden, so kann dies durch eine Zeile wie #jsdebugger { display: none ;} im eigenen Stylesheet erreicht werden. Dann braucht man auch die Log-Aufrufe wie print, debug und so weiter nicht auszukommentieren. Bei Bedarf läßt man sich dann den Debugger durch die Eingabe von

javascript:document.getElement
ById(„jsdebugger“).style.display=““;return;

in der Addresszeile des Browsers den Debugger wieder anzeigen.

Material zum Thema:

  • Demo als Zip-Archiv
  • JSCompoments Online Demo

Vorschläge und Hinweise zum Artikel werden vom Autor gerne entgegengenommen email: detlef(at)groth.de. Weitere Informationen zum JSDebugger und den JSComponents sind auf der Webseite des Autors zu erhalten. Diese enthält auch ein Wiki auf dem Anwender sich zum JSComponents-Framework und JSDebugger austauschen können.

Dr. Detlef Groth

Dr. Detlef Groth, von Beruf Biochemiker und IT-Konsultant, arbeitet als Bioinformatiker und Autor in Potsdam und Umgebung.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.