Java-Beans

Wie wir im vorigen Kapitel gesehen haben, können wir Java-Objekte auf den Scopes request, session und application nutzbringend verwenden. Besonders praktisch wäre es, wenn wir nicht nur einfache vordefinierte Klassen der Java - Api benutzten, sondern eigene, spezialisierte Klassen dort unterbringen könnten, die auch einen Teil des Java-Codes, der sich jetzt noch in unseren JSPs befindet, aufnehmen würden. Zuviel Code in HTML ist weder für den Programmierer noch für den Designer angenehm. Der Designer versteht nicht recht, was diese merkwürdigen Scripte sollen und ärgert sich, dass seine HTML Seiten nicht mehr korrekt (weil ohne verarbeitenden Server) angezeigt werde, der Programmierer hat stets den Verdacht, dass der Designer an seinem Code "rumgepfuscht" hat. Zudem scheint es zu den ehernen Gesetzen der Webseitenproduktion zu gehören, dass die Abnahme des Designs stets als letztes kommt, sodass es gut ist, bis dahin schon einmal die Logik fertig zu haben. Kurzum, was wir anstreben ist eine Trennung von Code und Design, und mit JavaBeans können wir sie weitgehend erreichen.

JavaBeans eignen sich besonders gut für diese Aufgabe, da sie Java-Klassen sind, die ganz bestimmten formalen Kriterien gehorchen und daher leicht durch ein Java-Programm (Container), in diesem Fall unseren Server Tomcat, verarbeitet werden können. JavaBeans müssen nicht von einer bestimmten Klasse abgeleitet sein - auch nicht von java.bean.Beans. Die für uns wichtige Kriterien einer gelungenen Bean sind drei:

1. Beans müssen einen Konstruktor haben, der public ist und ohne Parameter auskommt. Dieser Konstruktor wird vom Container benutzt. Wir können daneben weitere Konstruktoren mit Parametern schreiben, die wir selbst benutzen.
2. Beans müssen das Interface java.io.Serializable implementieren, d.h. all ihre Felder (globalen Variablen) müssen speicherbar (serialisierbar) sein. Nicht serialisierbare Felder müssen durch das Schlüsselwort „transient" gekennzeichnet sein.
3. Alle Felder der Bean, die der Container setzen oder lesen können soll, müssen über sogenannte getter- und setter-Methoden zugänglich sein.

Wir können eine Bean im Definitionsbereich einer JSP definieren. Dazu folgendes Beispiel:

<%! 
  /**  Unsere Bean ist eine eigene Klasse, deshalb beginnt sie mit 
  *  dem Schlüsselword: "class".
  *  Es folgt ihr Klassenname "SampleBean".
  *  "implements java.io.Serializable" ist die Anzeige an das
  *  Java-Runtime, dass diese Klasse serializiert werden kann.
  *  Wir brauchen für die Serializierung nichts weiter zu tun,
  *   wenn alle Felder der Klasse (=globalen Variablen) 
  *  serializierbar sind. */
    class SampleBean implements java.io.Serializable {
    
    /** Aller Felder der Klasse werden mit dem Schlüsselwort 
    *  "private" gekennzeichnet. Sie erreichen dadurch,
    *  dass sie ausserhalb der Klasse nicht sichtbar sind.    */
        private int value=0;
    private boolean valid=false;
    
    /**  Klassen sollten immer einen Wert bekommen und sei
    *  es auch nur "null". Vermeiden Sie Statements wie:
    *  "private String name,notVisibleToContainer;"
    *  damit haben Sie zwar zwei Strings in einer Zeile
    *  definiert, aber sich auch die Chance auf eine Menge
    *  Ärger eigehandelt. */
        private String name=null;
    private String notVisibleToContainer=null;
    
    /** Dies ist unser Konstruktor nach Beans-Spezifikation.
    *  Er ist public, d.h. im Prinzip von jeder Klasse in jedem package 
    *  aus zu erreichen und erfordert keine Parameter. Der Container
    *   (Tomcat) kann damit das Objekt erzeugen.*/
        public SampleBean() {
        }
    
    /** Ein weiterer Konstruktor, den wir "von Hand" benutzen
    *  können, um etwas Schreibarbeit zu sparen.    */
    public SampleBean(String aName,int aValue) {
      name=aName;
      value=aValue;
      valid=true;
    }
        
    /** Die setter-Methoden für alle Eigenschaften (Felder) der Bean,
    *  die der Container kennen soll und auf die man von aussen 
    *  Zugriff haben soll. Sie sind public, haben keinen Rückgabewert
    *  (void) und der Methodenname entspricht dem Namen des Feldes. 
    *  Ihr Parameter entspricht dem Typ des Feldes. */
        public void setName(String aName) {
            this.name=aName;
        }
        public void setValue(int aValue) {
            this.value=aValue;
        }
        public void setValid(boolean isValid) {
      this.valid=isValid;
    }
    
    /**  Die getter-Methoden. Sie sind ebenfalls public, ihr R?ckgabewert
    *  entspricht dem Typ des Feldes, ihr Methodenname setzt sich aus
    *  get+Feldname zusammen und sie haben keinen Parameter. */
    public String getName() {return name;}
        public int getValue() {return value;}
    
    /**  Die Ausnahme: Der Getter f?r boolsche Werte heist nicht
    *  getBoolean(), sonder isBoolean(). */
    public boolean isValid() {
      return valid;
    }
    
    /** Tipp:
    *   Überschreiben Sie die Methode public String toString()
    *  aus java.lang.Object (von dieser Klasse sind ja bekanntlich
    *  alle Java.Klassen abgeleitet.), um eine aussagekräftige 
    *  Ausgabe von Objekten Ihrer Klassen zu erhalten. */
    public String toString() {
      return "Name="+getName()+" value="+getValue()+" valid="+isValid();
    }
    }
 %>

Sie können die Bean nun wie jede andere Java Klasse verwenden, d.h. Sie können Objekte von ihr mit den Konstruktoren erzeugen, die definierten Methoden auf sie anwenden und sie ausgeben, indem Sie sie als Parameter für Methoden anderer Klassen nutzen:

 <%=new SampleBean()%>
 <%=  new SampleBean("JSP-Kurs",1)%>
 <% 
   SampleBean myBean=new SampleBean(); 
  myBean.setName("Meine Bean");
  myBean.setValid(true);
  out.println(myBean);
 %>
 

Einen Nachteil hat dieses Verfahren allerdings noch: Die Bean ist nur in der JSP sichtbar, in der sie definiert wurde. Das ist nicht gut, vor allem wenn wir eine Bean auf der Session oder dem Application-Scope nutzen wollen. Wir wollen daher im nächsten Abschnitte einen Weg finden, um selbstdefinierte Java-Klassen allen JSP zur Verfügung zu stellen.