Dies ist die Heimat der Java User Group Nürnberg.


Mittwoch, 18. November 2009

FinalCountdown iPhone-App

FinalCountdown is the new iPhone app for watching the countdown to a chosen date/time in all timezones.

E.g. with FinalCountdown you can follow the New Year's Eve all over the world in different time zone. Or you can lookup where in the world your birthday can be celebrated first.

Very useful also if you want to launch something worldwide at a special date so you can watch when the next timezone is ready for your launch.

Dienstag, 3. November 2009

JSXP (Just Simple eXtensible Pages)


JSXP: Web-Applikationen entwickeln – wie es sein sollte
JSXP steht für Just Simple eXtensible Pages[1] und ist ein frisch veröffentlichtes Open Source Framework für Web-Applikationen in Java. Unter [2] findet  man einen Screencast, der zeigt, wie man eine Newsletter-Web-Applikationen mit JSXP implementiert.
Warum ein neues Web-Framework? Als David Tanzer und ich im Februar dieses Jahres bei den JSFDays[3] in Wien waren, haben wir mit Entwicklern der JSF-Technologie darüber gesprochen, dass JSF zu kompliziert ist. Immer noch, denn verbessert hat sich die Situation selbst mit JSF2 nicht.
Leider stieß diese Ansicht, die ich in unserer Branche bei den Entwicklern, die mit JSF oder anderen Technologien arbeiten (müssen), bei den Erschaffern der bestehenden Technologien nicht auf Gehör. Auf der Fahrt zurück diskutierten David und ich fleissig. Wir waren uns einig, dass Apache Wicket einige gute Ansätze hat, aber das es unserer Meinung nach immer noch nicht die Probleme bei der Web-Frontend-Entwicklung löst.
Wir wollten zum einen Compile-Time-Safety und eine striktere Trennung von Design und Code, als man dies bislang im Java-Bereich gesehen hat. Die Diskussion endete damit, dass es schön wäre einen Proof-Of-Concept zu haben. In der folgenden Nacht schrieb ich die erste Version des JSXP-Frameworks, von der heute in dieser Form wohl keine Code-Zeile mehr übrig ist. Aber der Weg war geebnet. Nach dem Feedback zur ersten Live-Demo von JSXP auf der Herbstcampus[4] und weiteren sehr positiven Kritiken aller, denen wir JSXP vorstellten, ist das Framework längst nicht mehr nur ein Proof-Of-Concepts. Es ist eine ernst zu nehmende Möglichkeit Webauftritte in Java zu realisieren.
Bleibt die Eingangs erwähnte Frage: Warum ein neues Web-Framework? Diese Frage musste ich mir in einer frühen Phase von JSXP von einem Entwickler der JSF-Technologie stellen lassen, als ich ihm unser Konzept vorstellte
. Er fügte hinzu, dass es unsinnig und verlorene Zeit sei etwas zu entwickeln, was es schon gibt. Meine Antwort darauf ist folgende: es ist bezeichnend, wenn Menschen etwas neu entwickeln müssen, obwohl es bereits einen Ansatz gibt.
Was kann und bietet JSXP?
JSXP hat als realisierte Ziele von Anfang an Einfachheit und Sicherheit in der Anwendung. Zwar ist es äußert flexibel und bietet alle Features, die man aus Technologien wie JSF kennt, aber bei der Gestaltung des JSXP-Frameworks wurde die API stets auf Nutzerfreundlichkeit optimiert.
Zentrale Bestandteile einer JSXP-Webanwendung sind Design-Views, View-Controller, Applikationsklasse und Context. Design-Views ist dabei die Bezeichnung für das Design (z.B. XHTML-Dateien), View-Controller sind Java-Klassen die den Code hinter dem Design implementieren. Jedes JSXP-Webprojekt hat eine Applikationsklasse, die grundlegende Einstellungen und Algorithmen für die Applikation vorgibt. Der Context ist ein überall im JSXP-Projekt verfügbares Objekt, in dem man u.a. Informationen über den aktuellen Requests, diverse Einstellungen, Benutzerinformationen findet.
JSXP-Webanwendungen sind Design-Driven. Designer liefern das Design. Per Default in Form von XHTML-Dateien, aber dank des realisierten Factory-Patterns ist es möglich, auch jede andere Art von Eingabe (z.B. aus der DB) und Form des Design (z.B. XAML von Silverlight, oder jedes beliebige Format) zu nutzen, wenn man die Schnittstellen dann entsprechend implementiert. Im Folgenden beschränken wir uns bei den Beispielen auf das vom Standard direkt unterstützte Design per XHTML.
Das gelieferte Design wird bei JSXP-Webanwendungen nicht mit Code verunstaltet, die XHTML-Dateien bleiben im Browser u.a. zum Preview nutzbar. JSXP hält sich dabei an die strikte Trennung von Design und Code. Dies ermöglicht, Design in den Softwareentwicklungsprozess erfolgreich zu integrieren. Ein Designer kann das Design iterativ anpassen, es entstehen keine Inkonsistenzen. Der Designer kann direkten Zugriff auf die Versionsverwaltung bekommen und Design dort einchecken und verändern.
Ein per Shell aufrufbarer Generator
 generiert zu den Design-Views (im Standard eine XHTML-Datei) einen View-Controller. Die generierte Klasse selbst wird nie editiert. Man kann von ihr ableiten und die Subklasse anpassen. Dies verhindert Probleme im iterativen Prozess bei erneuter Generierung. Die generierten Klassen enthalten spezielle get- und set-Methoden für den Zugriff auf das Design und ermöglichen Templating und das ersetzen/einfügen von Texten und Elementen. Dank der generierten Methoden/Eigenschaften kann bereits zur Compile-Zeit festgestellt werden, ob sich eine Design derart verändert hat, dass der selbst implementierte Code nachgebessert werden muss. Auf dieses Compile-Time-Safety Feature wird man nicht mehr verzichten wollen, wenn man nach einem Tippfehler im Design direkt auf den Fehler hingewiesen wird, und dies nicht erst zur Laufzeit „um die Ohren gehauen“ bekommt. Auch wenn im Code benötigte Elemente umbenannt oder gelöscht werden, bekommt man sofortiges Feedback.
Das Paar von Design-View und View-Controller bildet in JSXP eine View-Komponente. Im Normalfall gehört genau eine View-Controller-Klasse zu einem Design-View. Diese Komponenten können wiederverwendet werden und man kann aus den Komponenten andere Views zusammen bauen. Innerhalb eines View-Controllers kann man andere Komponenten importieren und nutzen. JSXP ist damit Komponenten-basiert. Das Definieren und der Zugriff auf Komponenten geschieht dabei im Java-Code, nicht im Design.
Zur Laufzeit löst das JSXP-Framework eine URL auf, um benötigte View-Controller zu finden (oder Resource-Dateien direkt auszuliefern). Die Applikationsklasse wird genutzt um zu prüfen, ob evtl. Weiterleitungen notwendig sind oder Sicherheitseinschränkungen vorliegen (Login notwendig, etc.). Beim Zugriff auf einen JSXP-View wird der zugehörige View-Controller initialisiert. Dieser unterliegt dann einem bestimmten Lebenszyklus auf dessen Phasen im View-Controller selbst durch Überschreiben von Methoden oder von beliebiger Stelle per Registrierung von Phase-Listenern reagiert werden kann. Ein Beispielablauf der Phasen ist: Vorbereiten, Initialisierung, Eingabe-Parameter setzen, Validierung der Eingabe-Parameter, Ausführung, Templating, Resourcen-Handling, Variablenersetzung, Rendering,
Wie funktioniert der Zugriff auf Design-Elemente bei Beachtung von Separierung von Code und Design? Gerade bei diesem Feature von JSXP wird man seine Vorteile in Bezug auf Apache Wicket spüren, denn JSXP verfolgt das Prinzip der Separierung weit strikter. In den XHTML-Dateien muss man Elementen lediglich eine JSXP-ID geben und entsprechende Methoden/Eigenschaften werden generiert. JSXP-IDs sind im XHTML Tag-Attribute aus einem bestimmten Namensraum. JSXP kennt dabei keine HTML-Tags, es kennt lediglich View-Elemente. Es weiss nicht, ob es sich z.B. dahinter um eine Liste handelt oder um strukturierte DIV-Blöcke. Es muss auch die Verschachtelung von Elementen nicht kennen, da die IDs eindeutig sind. Dies führt dazu, dass man folgenden Design-Ausschnitt ändern kann, ohne das JSXP falsch reagieren wird:
Beispiel: per JSXP-ID referenzierbare Design-Elemente im Design-View
<head>
<title>Hello World</title>
</head>
<body>
<div jsxp:id="Name">Name
<p jsxp:id="Address">Adresse</p>
</div>
</body>
</html>
Hier werden am entsprechenden View-Controller „getElementName“ und „getElementAddress“ als Methoden generiert, die jeweils generierte Elemente von „Name“ und „Address“ typsicher zurückgeben (man beachte, dass spezielle Elemente für diese IDs als Interfaces generiert werden, aber dass es DIV-Elemente sind braucht JSXP nicht zu wissen). Und am Element „Name“ wird eine Methode „getElementAddress“ generiert. 
Per Code kann man wie folgt auf die Elemente zugreifen:
Name nameElement = getElementName();
Address addressElement = getElementAddress();
Element sameAddressElement = getElementName().getElementAddress();
Name und Address sind Implementierungen des allgemeinen Interfaces „Element“. Im Beispiel sind „addressElement“ und „sameAddressElement“ identisch. Je nachdem ob man Zeile 2 oder Zeile 3 aus dem Beispiel benutzt, ist folgende Designänderung kompatibel oder erzeugt einen Compile-Zeit-Fehler:
Beispiel: Änderung der Verschachtelung im Design
<div jsxp:id="Address">Adresse
<p jsxp:id="Name">Name</p>
</div>
Nur in Fällen, wo eine Verschachtelung im Design wichtig für den Code ist, benutzt man in JSXP also den verschachtelten Zugriff.
Mit den JSXP-IDs kann man Elemente aus dem Design-View referenzieren. Man kann auch Variablen im Design nutzen, um komfortabel Inhalte auszutauschen. Dazu benutzt man die $(Variablenname)-Notation an beliebiger Stelle im Design. Variablen werden dabei stets zu dem nächsthöheren per JSXP-ID angegebenen Element generiert.
Beispiel: Variablen
<div jsxp:id="Name">$(firstName)$(lastName)
<p jsxp:id="Address">$(street)</p>
</div> 
In dem Variablen-Beispiel gibt es generierte Methoden zum Auslesen und Setzen der „firstName“ und „lastName“ Variablen am Element „Name“ und für die Variable „street“ am Element „Address“.
Beispiel: Methoden passend zu den Variablen
getElementAddress().setVariableStreet(String value);
getElementName().setVariableFirstName(String value); 
getElementName().setVariableLastName(String value);
Auf diese Weise kann man mit JSXP Variablen nutzen und ist dennoch Compile-Zeit-sicher. Bei der Angabe der Variablennamen in der $-Notation unterstützt JSXP wohlweislich keine Expression-Language. Eine Query-Language würde den JSXP-Richtlinien zur Typsicherheit und der Konsistenz von Design und Code widersprechen. Möchte man allerdings sicherstellen, dass eine Variable zu einem bestimmten Element gehört oder zum View-Controller direkt, kann man dies durch einen Punkt notieren.
Beispiel: Weitere Variablennotation
<div jsxp:id“customer“>
<div jsxp:id=“order“>
<div jsxp:id=“billingAddress“>$(customer.name) $(street)</div>
<div jsxp:id=“deliveryAddress“>$(customer.name) $(street)</div>
</div>
</div>
In diesem Beispiel gibt es jeweils eine Variable „street“ an den Elementen „billingAddress“ und „deliveryAddress“ und eine Variable „name“ am Element „customer“. Benutzt man nur „$(.name)“ wird die Variable direkt an dem View-Controller generiert und ist damit für die gesamte View gültig.
JSXP erlaubt es dem Designer voll funktionsfähige Designs zu liefern. Die XHTML-Dateien können navigierbar sein und bereits mit Daten aufgefüllte Listen zu Demonstrationszwecken haben. Der Entwickler muss diese Listen nicht in den Design-Dateien leeren. Er tut dies dort, wo man es von einem Java-Entwickler erwartet: im Java-Code. Dies hat zur Folge, dass die Anwendung direkt nach dem Einfügen der Design-Views funktioniert und Prototyping möglich macht. Dies sieht man auch in dem Video-Screencast [2]. Man integriert die Design-Dateien in sein Projekt und kann die Webanwendung direkt nutzen und iterativ den Code und somit die dynamische Funktionalität implementieren. Dies bedeutet, dass die Design-Dateien stets auch losgelöst vom Webserver im Browser angeschaut und Designer und Entwickler in einem iterativen Prozess an den gleichen Dateien arbeiten können.
Beispiel: vereinfachte Tabelle vom Designer (Ausschnitt aus XHTML-Datei)
<table>
<tr>
<td>12345</td><td>07.02.2009</td>
</tr>
<tr>
<td>45678</td><td>11.10.2009</td>
</tr>
</table>
Nehmen wir an, die oben angegebene Tabelle wurde vom Designer geliefert. Diese Tabelle kann der Entwickler im nächsten Schritt für JSXP anpassen, ohne das Design zu ändern oder die Beispieldaten zu entfernen.
Beispiel: Tabelle nach Anpassung durch Entwickler
<head>
<title>Hello World</title>
</head>
<body>
<table jsxp:id="orderList">
<tr>
<td>12345</td><td>07.02.2009</td>
</tr>
<tr>
<td>45678</td><td>11.10.2009</td>
</tr>
<tr jsxp:id="orderItem">
<td>$(orderNo)</td><td>$(orderDate)</td>
</tr>
</table>
</body>
</html>
Per Code leert der Entwickler nun die Liste aus dem Design und benutzt die hinzugefügte Zeile für Element-Templating. In JSXP kann man Elemente aus dem Design als Template verwenden und so wiederholt als Struktur einfügen.
Beispiel: Code des View-Controller zum Table-Beispiel
public class TableXhtmlController extends TableXhtmlControllerGenerated<Object> {
@Override
public void execute() throws Exception {
getElementOrderList().removeElements();
ElementTemplate<OrderItem> itemTemplate = 
getElementOrderItem().createTemplate();
List<Order> orderList = ...; /* Business-Logik */
for (Order order : orderList) {
OrderItem orderItem = itemTemplate.createElement(order);
getElementOrderList().addElement(orderItem);
}
}
}
Die „execute“-Methode aus dem Beispiel wird vom JSXP-Framework im Zuge des Lebenszyklus eines Request aufgerufen, wenn die „Table“-Komponente Teil des Views ist, der zu einem Request gerendert wird. Hier wird also erst die Liste aus dem Design geleert, womit die Beispielinhalte verfallen. Danach wird aus dem „orderItem“-Element ein Template erzeugt, dass genutzt wird um Orderobjekte für die View aufzubereiten. Die „createElement“-Methode erzeugt dabei innerhalb der Schleife das konkrete Element zu für die Antwort auf den eingehebenden Browserrequest. Übergibt man der „createElement“-Methode ein Objekt, wird automatisch mit den an dem Objekt vorhandenen Properties versucht, die Variablen des Elements zu setzen. Alternativ hätte man die Variablen auch manuell setzen können: 
orderItem.setVariableOrderNo(value);
orderItem.setVariableOrderDate(value);
Wichtig an dieser Stelle ist, dass man im Code nicht merkt, dass es sich im Design um eine Tabelle handelt. Ändert sich das Design und wird die Tabelle z.B. durch eine DIV-Struktur oder einfache Textzeilen ersetzt, ändert sich der Code nicht. Code und Design sind unabhängig. Fällt eine JSXP-ID bei Bearbeitung durch den Designer weg, gibt es einen Kompilierungsfehler. So wird man bereits in der IDE gewarnt.
Will man zu der Tabelle einen Pager einbauen, der erlaubt in der Liste zu Blättern, ist es möglich eine Pager-Komponente zu importieren und zu nutzen. Im vorherigen Beispiel können wir dies durch das Überschreiben der „init“-Methode des View-Controllers tun:
@Override
public void init(Importer importer) throws Exception {
PagerXhtmlController pager = new PagerXhtmlController();
pager.setPageSize(20);
importer.importView(pager);
getElementOrderList().addElement(pager.getElementSimplePager());
}
Auf diese Art lassen sich beliebige fertige oder selbst entwickelte View-Komponenten importieren und direkt integrieren oder per Templating-Mechanismen nutzen. Und im Gegensatz zu JSF sind hier die Schnittstellen der Komponenten in der Sprache der Entwickler hinterlegt: Java. Der Designer wird nicht mit zusätzlichen ihm unbekannten Konstrukten belästigt.
In JSXP sind URLs direkt lesezeichenfähig (Bookmarkable) und vom Menschen lesbar (Human-readable-URLs). Dies wird beides auch bei Redirects unterstützt. Die Unterstützung hierfür ist bei anderen Webframeworks recht dürftig oder nur sehr schwierig umsetzbar. Selbst in Zusammenhang mit Internationalisierung oder Resourcenhandling sind keine komplizierten URIs notwendig (wie in JSF2). I
Internationalisierung wird von Haus aus unterstützt. Dabei kann durch die Applikationsklasse angegeben werden, welche Locales die Anwendung unterstützt, und per Default ermittelt JSXP, welche der Locales am besten zum User passt. Danach werden zum einen entsprechende Locale-Verzeichnisse für Design und Code genutzt, als auch das Locale am Context gesetzt, so dass man es beim Resourcenhandling nutzen kann.
Mit Resourcenhandlung kann man Elemente aus der View an Resourcen binden und die Elemente dadurch unterschiedlich füllen als auch austauschen. Dies ist zum Beispiel für Texte innerhalb eines Views nützlich, der aus Java Resource-Bundles kommen soll, oder für Bilder oder Skripte die aus unterschiedlichen Quellen stammen, für die der Designer aber im Design einen statischen Pfad benötigt. Beim Resourcenhandling definiert man durch Überschreiben der Methode „getResources“ welche mit einer JSXP-ID versehen Elemente des Designs zu einer Resource gehören. Man kann dann ResourceHandler an der Applikation definieren (im Standard sind bereits einige vorgesehen) die das Element je nach Resourcen-Typ unterschiedlich für die Antwort zum Client rendern. Im folgenden Beispiel sieht man ein Element im Design, dessen Inhalt durch das Resourcehandling automatisch vom JSXP-Framework durch die Inhalte aus einer Java-Properties-Datei ausgetauscht werden.
Beispiel: Resourcenhandling Designausschnitt
<body>
<p jsxp:id="resourcebundle">
Hello <br/> $(name)
</p>
</body>
</html>
Beispiel: Resourcenhandling View-Controller
public class ResourceBundleXhtmlController extends ResourceBundleXhtmlControllerGenerated<Object> {
@Override
public void execute() {
getElementResourcebundle().setVariableName("Snoopy");
}
@Override
public List<Resource> getResources() {
List<Resource> resources = super.getResources();
resources.add(new Resource(
"ResourceBundlePropertiesFileURL",
"text/resourcebundle", getElementResourcebundle()));
return resources;
}
}
Beispiel: Resourcenhandling Properties-Datei
resourcebundle[]=Hallo|$(name)
Resourcenhandling kann auch dazu genutzt werden, Skripte oder CSS-Dateien immer aus einem bestimmten Verzeichnis oder aus der Datenbank zu laden. Mit Resourcehandling sind Elemente beliebig durch Resourcen ersetzbar. Wie dies dargestellt wird, entscheidet der zu einem bestimmten Resourcen-Typ (im Beispiel „text/resourcebundle“) registrierte ResourceHandler. Resource sind insbesondere für die Komponenten-basierte-Entwicklung wichtig. Gibt ein View-Controller so zum Beispiel an, dass er eine bestimmte JavaScript-Datei als Resource benötigt, wird diese Resource für den Client gerendert und an ihn geschickt, auch wenn nur Teile der View nach dem Komponentenimport genutzt werden.
JSXP erlaubt auf komfortable Weise Zustände auf dem Server zu sichern. Dazu unterstützt JSXP diverse Scopes, wie Application-Scope, Session-Scope, View-Scope, Flash-Scope, ViewFlow-Scope und Request-Scope. Alle diese Scopes und ihre Inhalte werden automatisch verwaltet und sind über das Context-Object als leicht zu nutzende Maps verfügbar, oder können durch Angabe von Annotationen an Properties des View-Controllers verwendet werden. JSXP prüft automatisch bei den verwendeten View-Controllern, ob das anlegen einer Session notwendig ist und kümmert sich um alles notwendige.
Mit JSXP View Flows kann man Mengen von View-Komponenten definieren, die ausgezeichnete Start- und Endpunkte haben. JSXP erlaubt dann automatisch den Aufruf dieser Views per Request vom Client nur, wenn als erstes der Start-View aufgerufen wurde. Der View Flow wird automatisch beendet, sobald ein End-View erreicht wird. Springt der User aus einem View Flow nach Start hinaus, wird der View Flow abgebrochen. Während eines View Flows ist der ViewFlow-Scope gültig. ViewFlows kann man dabei wie Formular-Wizards verstehen, mit der Abläufe über mehrere Requests verarbeitet werden können.
JSXP unterstützt AJAX. Dazu ist eine sehr leichtgewichtige AJAX-JavaScript-API integriert. Aber jede andere AJAX-Bibliothek kann mit JSXP genutzt werden.
Geschwindigkeit ist mit JSXP auch kein Problem. Ein Caching-Mechanismus sorgt dafür, dass Prototypen der Design-Views stehts auf Abruf bereit stehen. Sie werden automatisch neu geladen, wenn sich das jeweilige Design ändert.
Auch das automatische Setzen von Input-Parametern (die z.B. in HTTP-GET/POST vom Browser kommen) übernimmt JSXP für den Entwickler. Dazu muss ein Entwickler lediglich eine Bean mit Eigenschaften für erwartete Input-Parameter zur Verfügung stellen.  Input-Parameter können dabei auch an importierte Komponenten weitergereicht werden.
Zum Validieren von Input-Parametern sieht JSXP eine Phase im Lebenszyklus vor. Für die Validierung überschreibt man im View-Controller die „validate“-Methode. Innerhalb der Methode kann man beliebige Frameworks nutzen, um die Daten an der Input-Parameter-Bean zu validieren und bei Fehlern auf entsprechende andere Views weiterzuleiten und die Fehler anzuzeigen/zu melden. Benötigt man kein spezielles Framework kann man mit den JSXP-Validatoren die Daten prüfen, JSXP-Elemente auf der Ergebnisseite markieren und Meldungen anzeigen.
Generell ist JSXP nach dem Prinzip gestaltet: Vollständig aber leicht anpassbar. Jederzeit kann das Verhalten des Frameworks nach den besonderen Projektbedürfnissen angepasst werden. JSXP bietet dazu insbesondere mit der Applikationsklasse und dem Context die Möglichkeit Methoden zu überschreiben und damit das Verhalten von JSXP flexibel zu gestalten. Beispielsweise kann man die Art und Weise wie Elemente bei Fehlern markiert werden um dem Benutzer nach Validierung auf Eingabefehler hinzuweisen, oder wie der zu benutzende Locale ermittelt wird ändern. Aber auch weitreichende Änderungen wie das Parsen von Design-Dateien oder sind einfach möglich. Viele der im Standard genutzten Algorithmen kann man somit austauschen oder anpassen.
JSXP bietet eine Reihe an weiteren Features, wie Project-Stages, View-Templates (ein Template-Mechanismus auf View-Ebene wie man ihn u.a. von Apache Struts kennt), View-Aliases, Command-Pattern und einiges mehr. Des weiteren ist noch in für dieses Jahr geplant, JSXP vollständig portletfähig zu machen.
Momentan wird JSXP von der MATHEMA Software GmbH [5] und der Ciqua [6] unterstützt. Damit gibt es eine breite Basis an erfahrenen Entwicklern, Trainern und Beratern für JSXP. Gern dürfen sich natürlich weitere Freiwillige zu uns gesellen. Das JSXP-Framework steht unter der Apache License Version 2. Es gibt auch erste Referenzprojekte: sowohl der jsxp.org Webauftritt ist über das CMS-System CMSonal mit JSXP implementiert, als auch das JSXP-Wiki und die Internetplattform solacize.com [7].
Eine Implementierung Ihrer Web-Applikationen mit JSXP steht also nichts mehr im Weg. Warum?
  • Damit Design wieder mit den Applikationen stattfinden kann, die dafür gemacht wurden, und nicht in irgendwelchen schwer zu handhabenden Plugins.
  • Damit Design auch nach mehreren Monaten Projektlaufzeit leicht iterativ angepasst werden kann, ohne das ein Entwickler kostbare Zeit vergeudet.
  • Damit Entwickler ihrer Kernaufgabe nachkommen können: Geschäfts- und Prozesslogik in Java-Code umsetzen.
  • Damit Entwickler nicht verzweifelt lange Zeit für Nichtigkeiten vergeuden, die den Projektfortschritt stoppen.
  • Und sicher auch um stabilere Applikationen zu schaffen, die nicht unvorhersehbar zur Laufzeit auf extrem schwer zu findende Fehler laufen, weil sich bei der Entwicklung jemand nur vertippt hat.
[1] JSXP Website, http://www.jsxp.org
[3] JSFDays Website, http://jsfdays.irian.at
[4] Herbstcampus Website, http://www.herbstcampus.de
[5] MATHEMA Software GmbH, http://www.mathema.de
[6] Ciqua Pirringer & Tanzer OEG, http://www.ciqua.com
[7] solacize.com, http://www.solacize.com