Ein schönes Beispiel dafür, wie sich gewohnte Java-Programmierung in
Scala "anfühlt", sind
Servlets:
package com.muchsoft.scala.servlets
import javax.servlet.http.HttpServlet
import javax.servlet.http.{HttpServletRequest => Request,
HttpServletResponse => Response}
class MeinErstesScalaServlet extends HttpServlet {
override def doGet(request: Request, response: Response) {
val ausgabe =
<html>
<head><title>Hallo Scala</title></head>
<body>
<h1>Hallo Scala-Welt!</h1>
</body>
</html>
response.getWriter().print(ausgabe)
}
}
Das sieht doch fast wie Java aus, oder? Nicht ganz: Beim Import können wir Umdefinitionen vornehmen, das
override vor der Methodendefinition ist zwingend notwendig, zudem ein Schlüsselwort und keine Annotation. Der Rückgabetyp der Methode
doGet() ist nicht angegeben und entspricht dadurch dem Java-
void. Für Scala hätten wir vor die öffnende geschweifte Methodenklammer
:Unit= schreiben können.
Innerhalb von
doGet() legen wir das XML-Literal
ausgabe an (als nicht änderbaren Wert mit
val; mit
var angelegte Variablen versucht man in funktionalen Sprachen zu vermeiden). Dieses XML-Literal schreiben wir ganz normal in den Ausgabestrom des Response-Objekts. Der Typ von
ausgabe ist
scala.xml.Elem.
Die Struktur der Web-Applikation entspricht dem JavaEE-Standard:
Der vom Scala-Compiler erzeugte Java-Bytecode landet in
WEB-INF/classes. Die Scala-Standardbibliothek
scala-library.jar (aus dem Scala-Installationsverzeichnis) muss in
WEB-INF/lib mit ausgeliefert werden. In
WEB-INF/web.xml mappen wir die Klasse
com.muchsoft.scala.servlets.MeinErstesScalaServlet auf die URL "hallo.scala". Nach dem Bereitstellen (Deployment) z.B. in
Tomcat oder
GlassFish kann das Servlet im Web-Browser dann mit der URL
http://localhost:8080/halloscala/hallo.scala aufgerufen werden.
Zum Übersetzen der Servlet-Klasse muss sich noch die Servlet-API auf dem Build-Path (Classpath) befinden. Dazu kann man z.B. aus dem Tomcat-Installationsverzeichnis
servlet-api.jar oder aus dem GlassFish-Verzeichnis
javaee.jar als externe Bibliothek einbinden.
Nun verbessern wir das erste Scala-Servlet und trennen Darstellung und Steuerung etwas besser voneinander:
class MeinZweitesScalaServlet extends HttpServlet {
def ausgabe =
<html>
<head><title>Hallo Scala</title></head>
<body>
<h1>Hallo Scala-Welt!</h1>
<p>Zeit auf dem Server: {jetzt} </p>
</body>
</html>
def jetzt = new java.util.Date
override def doGet(request: Request, response: Response) {
response.getWriter().print(ausgabe)
}
}ausgabe ist nun eine Funktion außerhalb von
doGet(), die auf die Funktion
jetzt zurückgreift, um einen aktuellen Zeitstempel auszugeben. Beide Funktionen sind ohne Parameterklammern definiert und müssen daher ohne Klammern aufgerufen werden. Hätten wir die Funktionen mit leeren Parameterklammern definiert, hätten wir es uns beim Aufruf aussuchen können, ob wir die Klammern hinschreiben oder nicht. Es hat sich die Konvention herausgebildet, die Klammern bei der Definition wegzulassen, wenn eine Funktion keine Nebenwirkungen (Seiteneffekte) hat.
Für eine "vollständige" Web-Applikation fehlt noch ein Formular. Bitteschön:
class MeinDrittesScalaServlet extends HttpServlet {
def ausgabe(benutzername: String) =
<html>
<head><title>Hallo Scala-Welt</title></head>
<body>
<h1>Hallo {benutzername}</h1>
<p>Zeit auf dem Server: {jetzt}</p>
<form method="GET" action="hallo3.scala">
<p>Wie heißt Du?
<input name="benutzer" />
<input type="submit" value="Abschicken" />
</p>
</form>
</body>
</html>
def jetzt = new java.util.Date
override def doGet(request: Request, response: Response) {
val param = request getParameter "benutzer"
val benutzername =
if ((param == null) || (param.isEmpty))
"Scala"
else
param capitalize
val antwort = ausgabe(benutzername)
response.getWriter().print(antwort)
}
}ausgabe() bekommt nun einen String-Parameter übergeben, der in
doGet() anhand des Request-Parameters "benutzer" ermittelt wird. Statt des
?:-Operators von Java, den es in Scala nicht gibt, verwenden wir ein besser lesbares
if-else, das in Scala ein Ausdruck ist und entsprechend ein Ergebnis liefert.
Wenn diese dritte Servlet-Klasse in
web.xml auf die URL "hallo3.scala" gemappt wird, kann der Aufruf im lokalen Applikations-Server mit
http://localhost:8080/halloscala/hallo3.scala?benutzer=Thomas erfolgen.
In der Praxis wird man Servlets wohl eher nicht direkt programmieren, sondern ein Framework wie
Struts,
JSF,
Wicket o.ä. einsetzen. Man sieht hier aber gut, wie problemlos man Scala in bestehende Java-(Web-)Anwendungen integrieren kann. Und wenn man Web-Applikationen so richtig funktional entwickeln möchte, kann man das Scala-
Lift-Framework nutzen.
Why isn't this blog available in English? Well, there are so many useful blogs out there, but only a few of them are written in languages other than English. So I decided it was time for a blog in my mother tongue.
Posts
