javablog.ch

Momentan lese ich das Buch JavaScript: The Good Parts von Douglas Crockford.
Ein durchweg empfehlenswertes Buch, das eine klare und kompakte Übersicht über die Stärken (und Schwächen) von JavaScript bietet. Sehr interessant ist das “Functional”-Pattern: Mit Hilfe von Closures können private Instanzvariablen und Methoden definiert werden. In 4 Schritten erstellt eine sogenannte “Maker”-Methode eine neue Objekt-Instanz.

1. Erzeuge ein neues Objekt
2. Definiere in der Methode die (privaten) Instanzvariablen und Methoden.
3. Hänge an das neue Objekt die öffentlichen Methoden. Dank dem “Closure”-Prinzip haben nur diese Methoden Zugriff auf die vorher definierten Instanzvariablen und Methoden.
4. Gebe das neue Objekt zurück.

Hier das Beispiel:

1. var vehicle = function(spec) {
2.      // the spec object contains all attributes needed to create the object.
3.  
4.      // create a new empty object using the object literal
5.      var o = {};    
6.  
7.      // vars of this function are the private variables of the new object
8.      var age            = 0;
9.      var maxSpeed       = spec.maxSpeed;
10.      var name           = spec.name;
11.      var price      = spec.price;
12.  
13.      // private methods
14.      var calculateDegradation = function() {
15.            return age * price / 10 ; // assuming linear degradation
16.      };    
17.  
18.      // public methods
19.      o.getName = function() {
20.          return name;
21.      };
22.  
23.      o.getMaxSpeed = function() {
24.          return maxSpeed;
25.      };
26.  
27.      o.setAge = function(v) {
28.         age = v;
29.         return o; // cascade pattern
30.      }
31.  
32.      o.getResidualValue = function() {
33.          return price - calculateDegradation();
34.      };
35.  
36.      return o;
37. }
38.  
39. var myVehicle = vehicle( { name: 'Audi R8',
40.                                 price: '106400',
41.                                 maxSpeed: '301'});
42.  
43. alert(myVehicle.getMaxSpeed()); // 301
44. alert(myVehicle.getResidualValue()); // 106400;
45. alert(myVehicle.setAge(2).getResidualValue()); // 85120;

Interessant ist die Ansicht im Firebug: Keine Spur von den privaten Methoden oder Instanzvariablen. Sie werden durch das “Closure” geschützt.

Mit der Taglibrary von OSCache können einzelne Segmente innerhalb einer JSP gecached werden. Das “cache”-Tag führt den Tag-Body aus und cached anschliessend das Ergebnis (also den Output). Dabei kann der JSP-Entwickler entscheiden, wie lange und in welchem Scope (Application oder Session) der Body Content gecached werden soll.

Die Konfiguration des Algorithmus sowie die maximale Anzahl Objekte im Cache werden in einem property-File (oscache.properties) vorgenommen, welches in das WEB-INF/classes Verzeichnis platziert wird.

Das nachfolgende Beispiel cached zwei Datumsobjekte. Das erste wird für 5 Sekunden im Application Scope gecached. Das zweite für 10 Sekunden im Session Scope (jede Session bekommt also ein eigenes gecachetes Objekt).

Die (sehr gute Dokumentation) der Taglibrary gibts unter
http://www.opensymphony.com/oscache/wiki/JSP%20Tags.html#JSPTags-cache

Zentrales Element im OSCache sind die konkreten Implementierungen der AbstractCacheAdministrators Klasse. OSCache bietet zwei Implementierungen:

• GeneralCacheAdministrator
  Eine generelle Implementierung, die auch für Desktopanwendungen eingesetzt werden kann.
• ServletCacheAdministrator
  Spezialisiert auf Caching im Servlet-Umfeld, kann unter anderem auf Session oder ServletContext-Ebene cachen.

Die Funktionsweise eines CacheAdministrators ähnelt einer HashMap, geht aber weit darüber hinaus. So können Cache-Einträge ablaufen und müssen bei erneuten Zugriffsversuch erneuert werden. Auch die Anzahl von Cache-Einträgen soll limitiert werden. Mit der Methode setAlgorithmClass(String clazz) kann der Algorithmus konfiguriert werden.
Zur Verfügung stehen:

• FIFOCache
• LRUCache
• UnlimitedCache

Beispiel:
Das nachfolgende Beispiel verwendetet einen FIFOCache mit max. 20 Cache-Einträgen. Unter dem Key “myKey” wird ein String in den Cache abgelegt und anschliessend 2x darauf zugegriffen. Beim zweiten Mal ist dieses Objekt “abgelaufen” und muss erneuert werden.

Ausgabe:
myObject
expired object:=myObject

Das Cachingframework bietet zusätzlich eine eigene JSP-Taglibrary und einen Servlet-Filter, der transparent für die Applikation ganze Seiten oder binäre Dateien cachen kann. Mehr dazu im 3. Teil.

Caching spielt bei der Entwicklung von Webapplikation eine entscheidende Rolle. Nicht jedes Element auf einer Seite soll bei einem Request komplett neu generiert werden. Beispiel dafür sind RSS-Feeds, die in Form einer Newsliste auf einer Homepage dargestellt werden. Hier soll nicht bei jedem Request der RSS-Feed vom anderen Server abgeholt und neu geparst werden, da jedes Einlesen mit erheblichen Zeitaufwand verbunden ist.

Eine typische Lösung ist, den RSS-Feed nach dem ersten eintreffenden Request für eine Zeitspanne (z.B. für eine Stunde) im RAM zu halten. Jeder weitere Request innerhalb dieser Zeitspanne verwendet das gecachte Objekt. Nach Ablauf dieser Zeitspanne verfällt der Cacheeintrag und der nächste Request sorgt dafür, dass der RSS-Feed neu generiert wird und wieder in den Cache abgelegt wird.

Man kann sich so einen Cachingmechanismus mit Hilfe einer HashMap und einem Object-Wrapper selber bauen. Oder man spart sich die Arbeit und nutzt ein vorhandenes Caching-Framework wie OSCache von OpenSymphony.

OSCache bietet generische Caching-Klassen mit unterschiedlichen Cache-Algorithmen wie Least Recently Used oder FIFO. Die Cache-Einträge können zudem persistiert werden, damit sie einen Webserver Neustart überleben und nicht neu generiert werden müssen.

Mehr zum Einsatz dieser Cache-Bibliothek gibts im zweiten Teil.

Manchmal darf man als Java-Entwickler auch JavaScript programmieren. Dabei stört mich der fehlende Compiler, der den Code auf Tippfehler oder versehentlich definierte globale Variablen überprüft. Abhilfe schafft JSLint, ein JavaScript Programm, das JavaScript validiert. Neben Fehlern werden auch Coderichtlinien wie Klammersetzung oder Variablennamen berücksichtigt.

Abschliessend noch ein Zitat von Douglas Crockford (Entwickler von JSLint):

JSLint will hurt your feelings

Mit dem Web 2.0 Hype kam eine Vielzahl von Javascript Frameworks. Neben der obligatorischen Unterstützung für asynchrone Requests bieten diese Frameworks auch zusätzliche Features wie Animation oder eigene UI-Controls. Diese Woche habe ich mir die Yahoo! User Interface Library (YUI) genauer angeschaut und bin bis jetzt begeistert.

Typischerweise zeichnen sich die bisherigen JavaScript Frameworks wie Dojo oder Rico durch eine eher dürftige Dokumentation aus. Dagegen ist die YUI Library von Yahoo vorbildlich dokumentiert. Besonders gefällt mir die hohe Anzahl an Code-Beispielen und die “Cheat Sheets”, die eine sehr schnelle Einarbeitung in die Library ermöglichen.

Beispiele:
Cheat Sheet für das “Animation” Modul
Dokumentation für das “Autocomplete” Modul

Ach ja: Die Library ist Open Source (unter der BSD Lizenz).

Webapplikationen können über die HttpSession keine Daten austauschen, da eine HttpSession immer an einen ServletContext gebunden ist. Wenn eine Webapplikation eine andere Webapplikation über den RequestDispatcher inkludiert, wird zwar eine Session mit der gleichen(!) SessionID erzeugt, es sind aber effektiv zwei HttpSession Objekte vorhanden.

Vergleiche Servlet Specification 2.4. (Kapitel 15.1.7)

Session information is scoped only to the current web application
(ServletContext), so information stored in one context will not be directly visible
in another.

Auch für JSR 168-konforme Portlets gelten diese Restriktionen. So konnen Portlets nur innerhalb der gleichen PortletApplication gemeinsame Daten austauschen. (Eine PortletApplication wird mit Hilfe einer Webapplikation realisiert). Diese Restriktion soll mit JSR 286 aufgehoben werden. Im Early Draft Review werden sogenannte “Shared Session Attribute” vorgestellt. Hier definiert der Portlet-Entwickler die gemeinsamen Session Attribute in der portlet.xml. Das JAXB Framework (Java Architecture for XML Binding) wird verwendet, um den Typ des Session Attributes zu beschreiben. Konkret bedeutet dass, das die Klasse für das Shared Attribut mit JAXB Annotations versehen wird. So kann das Attribut auch in anderen VMs ausgelesen werden, da die Klasse mit Hilfe von JAXB wieder zusammengebaut wird (Stichwort “marshalling”).