Oder anders gefragt, warum kann der Code nicht so aussehen?

 webPrint("Ergebnis",
   webRead("Erste Zahl") + webRead("Zweite Zahl"));

Stattdessen müssen wir unsere (in diesem Beispiel sicherlich primitive)
Anwendungslogik zerreißen und dem zustandslosen HTTP-Protokoll und
ereignisgesteuerten Ablauf des Browsers unterwerfen:

 - zeige ein Eingabeformular mit dem Prompt "Erste Zahl" an.
 - reagiere auf die Eingabe der ersten Zahl und zeige jetzt ein
   Eingabeformular mit dem Prompt "Zweite Zahl" an, merke dir
   dabei die erste Zahl, z.B. als versteckte Eingabe in dem zweiten
   Formular
 - reagiere auf die Eingabe der zweiten Zahl und zeige jetzt
   eine Seite mit dem Text "Ergebnis" und dem Ergebnis der Addition
   der zweiten Zahl mit der ebenfalls versteckt übertragenen ersten
   Zahl an.

Wir müssen die Formulare also jeweils so gestalten, dass sie den
zukünftigen Programmablauf mit berücksichtigen.  Diese Zukunft eines
Programms bezeichnet man als continuation und Sprachen wie z.B. Scheme
kennen sie als direktes Sprachkonzept.

Könnten wir continuations in Java benutzen, könnten wir vielleicht
obiges Programm direkt implementieren.  Dies (wenigstens zu simulieren)
soll das Ziel dieses Teils des Tutorials sein.

Java hat keine Continuations, auch keine Coroutinen (die kleinen
Schwestern von Continuations), aber Threads, die näherungsweise benutzt
werden können, indem wir sie explizit anhalten und später weiterlaufen
lassen.

Auf die URL /start hin wollen wir eine neue Continuation erzeugen, die
dann das obiges Programm ablaufen lässt. Die Continuation soll unter
einer einzigartigen ID abgelegt werden, damit wir sie bei jeder weiteren
Anfrage, die mit /continue eingeleitet werden soll, wiederfinden.

 public class ContinuationWeblet extends Weblet {
  private final Map<String, Continuation> continuations =
    new HashMap<String, Continuation>();

  public boolean matches(WebRequest request) {
    return request.urlStartsWith("/start") ||
      request.urlStartsWith("/continue");
  }

  public void handle(WebRequest request, WebResponse response)
    throws IOException {
    if (request.getUrl().startsWith("/start")) {
      newContinuation().start(request, response);
    } else if (request.getUrl().startsWith("/continue")) {
      getContinuation(request).resume(request, response);
    } else {
      response.sendError("404 Not found", null);
    }
  }

  private Continuation newContinuation() {
    synchronized (continuations) {
      String id;
      do {
        id = newId();
      } while (continuations.containsKey(id));
      Continuation cont = new Continuation(id);
      continuations.put(id, cont);
      return cont;
    }
  }

  private String newId() {
    ...
  }
  ...
 }

Als ID nehmen wir am besten eine ausreichend lange Folge zufälliger
Zeichen. Die konkrete Implementation sei dem Leser überlassen.

Dies ist der Aufbau einer Continuation:

 public class Continuation extends Thread {
    private final String id;
    private WebRequest request;
    private WebResponse response;

    Continuation(String id) {
      this.id = id;
    }

    protected void init(WebRequest request, WebResponse response) {
      this.request = request;
      this.response = response;
    }

    public void start(WebRequest request, WebResponse response) {
      init(request, response);
      start();
      ...
    }

    public void resume(WebRequest request, WebResponse response) {
      init(request, response);
      ...
    }

    public void run() {
      ...
    }
 }

Ich bin mir nicht sicher, ob eine Thread-Unterklasse die beste Idee ist,
aber irgendwie muss ich den Thread schließlich starten, laufenlassen und
dabei unterbrechen können. Dazu später mehr. WebRequest und WebResponse
werden jeweils übergeben und in Exemplarvariablen gespeichert, damit sie
in der run-Methode zur Verfügung stehen. (Seufz: Alles muss man in Java
selbst machen - auch closures...)

Zunächst möchte ich den Code zeigen, der eine Continuation wiederfindet:

 public class ContinuationWeblet...
  ...
  private Continuation getContinuation(WebRequest request) {
    Continuation cont;
    synchronized(continuations) {
      cont = continuations.get(request.getParameter("id"));
    }
    if (cont == null) {
      cont = NullContinuation;
    }
    return cont;
  }

  private static final Continuation NullContinuation =
    new Continuation() {
      public void resume(WebRequest request, WebResponse response) {
        init(request, response);
        merge(ERROR_TEMPLATE);
      }

    };

    private static final String ERROR_TEMPLATE = ...
 }

Wir benutzen hier das Null-Object-Pattern, das statt null ein spezielles
Objekt benutzt, um so eine Fallunterscheidung oder NullPointerException
in der eigentlichen Methode zu vermeiden und die Lesbarkeit zu erhöhen.

Der Fehlertext sagt sowas wie "hey, diese continuation gibt es nicht,
klicke auf /start um neu zu beginnen".

Wie man sieht, habe ich die merge-Methode in die Continuation-Klasse
verschoben. Wahrscheinlich sollte auch der Fehlertext dort stehen.

Die eigentliche Magie geschieht in der Continuation-Klasse, dort wo ich
die "..." eingefügt habe. Beginnen wir mit der run()-Methode:

 class Continuation...
    public void run() {
      webPrint("Ergebnis",
        webRead("Erste Zahl") + webRead("Zweite Zahl"));
    }

    private int webRead(String prompt) {
      merge(
          "<html><head><title>@prompt@</title></head>" +
              "<body><h1>@prompt@</h1>" +
              "<form method='post' action='@url@'>" +
              "<input type='text' name='value' />" +
              "<input type='submit' value='OK' />" +
              "</form></body></html>",
          "prompt", prompt, "url", url());
      yieldControl();
      return Integer.parseInt(request.getParameter("value"));
    }

    private void webPrint(String prompt) {
      merge(
          "<html><head><title>@prompt@</title></head>" +
              "<body><h1>@prompt@</h1>" +
              "<p>@result@</p>" +
              "<p><a href='/start'>Restart</a></p>" +
              "</body></html>",
          "prompt", prompt, "result", Integer.toString(result));
      yieldControl();
    }

    private String url() {
      return "/continue?id=" + id;
    }
 }

Die Methode yieldControl() hält den Thread (und damit die Ausführung der
Continuation) an und lässt die zwischenzeitlich wartende start() bzw.
resume()-Methode weiterlaufen, auf dass die erstellte WebResponse
abgeschickt werden kann:

 public class Continuation...
   ...
   private final Condition yield = new Condition();
   private final Condition wait = new Condition();
   ...
   public void start...
     ...
     start();
     yield.await();
   }

   public void resume...
     ...
     wait.signal();
     yield.await();
   }

   private void yieldControl() {
     yield.signal();
     wait.await();
   }
   ...
 }

Was ist eine Condition?  Ein Synchronisationspunkt zwischen zwei
Threads. Wahrscheinlich gibt es da auch eine fertige Klasse im JDK 1.5,
aber so war es für mich einfacher:

 static class Condition {
   private boolean b;

   synchronized void signal() {
     if (!b) {
       b = true;
       notify();
     }
   }

   synchronized void await() {
     while (!b) {
       try {
         wait();
       } catch (InterruptedException e) {
         e.printStackTrace();
       }
     }
     b = false;
   }
 }

Die Methode signal() setzt ein Flag. Mit await() kann ich in einem
anderen Thread auf dieses Flag warten. Danach wird das flag
zurückgesetzt, damit die Condition ein zweites Mal benutzt werden kann.

Schauen wir uns mit diesem Wissen nochmal die Continuation-Methoden an:

 - Continuation#start() wird aus dem Thread des Handlers aufgerufen und
   startet Continuation#run() als Continuation-Thread. Dieser läuft
   sofort oder später los, wichtig ist nur, dass der Handler-Thread auf
   ein "yield"-Signal wartet. Das wird die Continuation auslösen, wenn
   die WebResponse fertig ist und vorerst unterbrochen werden soll.
 - Continuation#run() läuft parallel zum wartenden Handler-Thread los
   und führt das erste webRead() aus, welches yieldControl() aufruft.
 - Continuation#yieldControl() sagt dem wartenden Handler-Thread, dass
   er weitermachen kann und wartet selbst auf ein Signal, dass ein neuer
   Handler-Thread schicken wird, wenn /continue aufgerufen wird.
 - Während der Continuation-Thread also auf "wait" (besser wäre ja
   continue, aber das ist ein Schlüsselwort in Java) wartet, wird
   Continuation#resume() aus einem Handler-Thread aufgerufen, was
   dem Continuation-Thread bescheid gibt, dass es weiter gehen kann
   (mit neu untergeschobenem WebRequest und neuem WebResponse) und
   wartet genau wie start() darauf, dass die Continuation wieder die
   Kontrolle abgibt.

Wird das Ende von run() erreicht, stoppt leider die Continuation nicht,
sie hängt ewig - Künstlerpech.

Ich rekapituliere nochmal: Wenn wir im Browser auf /start zugreifen,
wird eine neue Continuation erzeugt und gestartet, während der
Handler-Prozess wartet.  Die Continuation wird stückweise ausgeführt,
jedes Mal neu getriggert durch einen Request mit der URL /continue.
Verschiedene URLs sind unnötig. Die Continuation "weiss", wo es weiter geht.

Neben dem offensichtlichen Problem, welches sich dieses Rahmenwerk mit
vielen anderen einfachen Web-Rahmenwerken teilt - der Back-Button ist
tötlich für den Ablauf - hat das Rahmenwerk somit auch ein Problem mit
Reloads.

Doch gehen wir trotzdem noch einen Schritt weiter.

Eine WebComponent sei ein Objekt, das sich selbst auf einer WebPage
darstellen kann:

 public abstract class WebComponent {
   public abstract void renderOn(WebPage page);
 }

  webPrint("Ergebnis",
    webRead("Erste Zahl") + webRead("Zweite Zahl"));

soll unverändert so bleiben und gesucht ist einzig eine geschickte
Implementierung für webPrint und webRead.

Gegeben ist wieder diese Funktion:

  function run() {
    webPrint("Ergebnis", webRead("Erste Zahl") + webRead("Zweite Zahl"))
  }

Die Implementierung der beiden Funktionen ist geradeheraus:

  function webRead(prompt) {
    emit("<html><head><title>", prompt, ...
         "<form action='", url, ...
         "<input name='v' ...)
    yieldControl()
    return req.getParameter("v")
  }

  function webPrint(prompt, result) {
    emit("<html>... ", result, ...)
  }

Die Funktion emit() schenke ich mir, sie macht aus Strings und Werten
einen String und schreibt ihn per

  res.contentType = "text/html"
  res.writer.println(result)

in die Response.

Spannender ist die Funktion yieldControl. Sie erzeugt und speichert eine
neue Continuation, die dann später beim nächsten Request fortgesetzt
wird. Danach beendet sich die Funktion, indem eine zuvor gespeicherte
exit-Continutation fortgesetzt wird.  Wie req und res speichere ich
beide Continuations in globalen Variablen:

  var exit
  var cont
  function yieldControl() {
    cont = new Continuation()
    exit()
  }

Hier wird die exit-Continuation angelegt:

  function doit() {
    exit = new Continuation()
    if (cont != null) {
      cont()
    } else {
      run()
    }
  }

Damit ich das jetzt aus Java heraus aufrufen kann, braucht es noch ein
kleines Servlet (ich werde nicht müde, hinzuweisen, dass die Java-Seite
tatsächlich mehr Zeilen hat als der JavaScript-Code):

  class ContinuationServlet extends HttpServlet {
    private ScriptEngine engine;
    private Map<String, Object> continuations;
    private int nextId;

    void init(...) {
      engine = new ScriptManager().getEngineByName("JavaScript");
      engine.eval(/* hier den obigen JavaScript-Code lesen */);
      continuations = new HashMap<String, Object>();
    }

    void doGet(....) {
      String id = /* id from URL extrahieren */

      Object continuation;
      synchronized (continuations) {
        continuation = continuations.get(id);
        id = Integer.toString(++nextId);
      }

      Bindings b = engine.getBindings(ScriptContext.ENGINE_SCOPE);
      b.put("req", request);
      b.put("res", response);
      b.put("cont", continuation);
      b.put("id", id);
      engine.eval("doit()", b);
      synchronized (continuations) {
       continuations.put(
         id,
         engine.getBindings(ScriptContext.ENGINE_SCOPE).get("cont"));
      }
    }
  }

Wenn man HttpSessions benutzen würde, müsste das noch einfacher gehen,
ich fand aber bei meinem Test auf die Schnelle nicht, wie ich das in
Jetty, das ich direkt ohne web.xml starte, realisiere.

Ich bin mir nicht sicher, ob die Engine wohl thread-safe ist. Außerdem
räume ich meine Continuations nie auf, man will wahrscheinlich nicht
alle für eine unbegrenzte Reise in die Vergangenheit aufbewahren,
sondern nur die letzten 10 oder nur für X Minuten oder so.

Zumindest sind das die Argumente die auf meinen Vorschlag in der
Wicket-user Mailingliste kamen. Ich schätze man wollte sich Arbeit vom
Hals halten, was ich gut nachvollziehen kann :)

Deine Ausführungen fand ich sehr gut. Ich hoffe ich habe tatsächlich mal
die Zeit eine Continuations-Implementation für Wicket zu machen. Der
grösste Aufwand wird wohl sein das vernünftig und ohne Änderungen am
Kern umzusetzen, nicht die Continuations-Engine selbst. Trotzdem ist
dein Artikel da schon mal eine grosse Hilfe.

Wenn es dich interessiert, hier mein Vorschlag wie Continuations in
Wicket aussehen könnten:
http://sourceforge.net/mailarchive/message.php?msg_id=13995847

Timo

 > und die sind ja teuer und das skaliert

 > und überhaupt geht das ja auch mit einer State Machine.

Nur viel umständlicher.  Vergleiche Stefan Rams Beispiel...

Aber selbst wenn Continuations nur mit Threads möglich sind ist mir das
egal, denn bei einer Anwendung mit wenigen dutzend Usern ist der Nutzen
bei komplexen Abläufen mit viel Interaktion hoch.

Mein nächster Versuch ist daher, einen Interpreter zu bauen, der
Continuations kann, weil ich das glaube ich immer noch nicht 100%ig
verstanden habe :(

Oder ich schaue mir erstmal
http://download.plt-scheme.org/doc/301/html/web-server/ an...

Wenn du partu bei Java bleiben willst, wäre vielleicht - wenn es dann
zumindest eine häßliche Lösung gäbe - ein spzieller post prozessor in
Form eines ClassLoaders ein Weg, den Code automatisch zu tranformieren.

Ich meine RIFE geht so vor, allerdings meine ich ebenfalls (ohne das
genauer angeschaut zu haben), dass sie dort keine echten Continuations
haben.

Wenn man wenigstens in Java resume/retry-bare Exceptions hätte...

Das Framework selbst sieht so auf den ersten Blick recht gut programmierbar
aus, ähnlich wie UCW (muß ich wirklich mal ausprobieren), mit
Continuations. Scheint auch recht einfach zu sein, zu Aktionen eigene
Webseiten zu entwerfen.

Du willst bei "diesen Continuation" -- hab den Begriff eigentlich immer
nur hier in der NG von dir gelesen, vermutlich fehlt mir da eine
schlüssige Definition -- also einfach nur zwischen Zwei Funktionen wie
"webRead() + webRead()" eine weitere Response haben, oder? *selber noch
ein wenig drüber Nachdenk*

Der Trick bei diesem simplen Beispiel mit dem "+" ist ja, dass das
Programm quasi in der "+"-Operation anhält, und dort mehrfach mit
verschiedenen zweiten Operanden - wenn man im Browser nach dem Ergebnis
immer wieder den Back-Buttond drückt - addiert wird.

Siehe auch http://en.wikipedia.org/wiki/Continuation für mehr
Informationen.   Es gibt zu dem Thema aber einiges an Literatur:
http://library.readscheme.org/page6.html ;)

Mir hat der Artikel "Teach yourself Scheme in Fixnum Days" und dort der
Abschnitt über "Amb" geholfen, Continuations zu verstehen.

PLT-Scheme benutzt da vielleicht die besseren Namen.  Dort gibt es eine
"send/suspend"-Funktion (der Name enthält ein "/", da ist nichts
besonderes dabei), die eine Funktion übergeben bekomt, die wiederum eine
continue-URL übergeben bekommt und eine web-response erzeugt und wo
send/suspend dann selbst einen web-request liefert.  Per Konvention
startet eine PLT-Scheme-Webanwendung mit einer Funktion "start", die den
initialen Request bekommt und eine web-response liefert soll.

Übersetzt in Scala könnte das so aussehen:

  abstract class Servlet {
    def start(req: Request): Response
    def sendAndSuspend(f: String => Response): Request = {
      ...
    }
  }

  class OnePage extends Servlet {
    def start(req: Request): Response = {
      Response(<html>...<h1>Hello</h1>...</html>)
    }
  }

  class TwoPages extends Servlet {
    def start(req: Request): Response = {
      val req = sendAndSuspend(kUrl =>
        Response(<html>...
          <a href="{kUrl + "?link=1"}">Link 1</a>
          <a href="{kUrl + "?link=2"}">Link 2</a>
          ...</html>))
      Response(<html>...
        <p>You chose Link {req.parameter("link")}</p>
        ...</html>)
    }
  }

Und das klassische Additionsbeispiel könnte so aussehen:

  class AddEx extends Servlet {
    def start(req: Request): Response = {
      webPrint("Ergebnis", webRead("Eins") + webRead("Zwei"))
    }

    private def webRead(prompt: String): Int = {
      val req = sendAndSuspend(kUrl =>
        Response(<html>...<form action="{kUrl}"><input name="v">...))
      req.parameter("v").toInt
    }

    private def webPrint(prompt: String, value: Int) = {
      Response(<html>...)
    }
  }

Leider ist es auch in Scala nicht möglich, sendAndSuspend zu
implementieren...

Was man machen müsste, wäre einen Snapshot vom aktuellen
Ausführungsstack und Zeiger auf die nächste auszuführende Anweisung
derart anzulegen, sodass man später das Programm ab diesem Zeitpunkt
weiter laufen lassen kann.

Dann muss man das Programm hier abbrechen, indem man einen zuvor
gesetzten Snapshot fortsetzt, der die erstellte Response jetzt an den
Browser übergibt und dann die Kontrolle bis zum nächsten Request
komplett abgibt.

Entscheidend ist ... grummel, jetzt scheint die brasiliansche Site down
zu sein... jedoch, dass man während der Entwicklung direkt im Browser
Zugriff auf all diese netten Werkzeuge hat, angefangen von der
Möglichkeit, mal die Komponenten und das HTML selbst zu sehen, über den
Profiler bis hin zum Inspector für das laufende Programm.

Ich sehe aber den Nachteil des Medienbruchs, wenn man es nur in der IDE
editieren könnte: Squeak (und Emacs) bieten eine andere Sichtweise auf das
System, als man es im Browser sieht, also z.B. muß man bei einer Webseite
erst den dazugehörigen Quelltext suchen, wobei bei Seaside das mit einem
Klick auf den Quelltextbutton der gerade dargestellten Seite möglich ist
(denke ich). Ist also in der praktischen Anwendung wahrscheinlich gar nicht
so schlecht.

Fazit: man baut Zope nach, also eine Webanwendung, mit der man
Webanwendungen bauen kann :-)

In Java sähe das dann z.B. so aus, daß man z.B. einen
JavaScript-Interpreter einsetzt und per Webinterface die Scripts und
dazugehörigen Templates anlegen und ändern kann. Ideal wäre dann noch ein
Editor als Browser-Plugin, der eine Verbindung zum Java-Server aufnimmt und
beim editieren von Quelltext z.B. auto-completion bereitstellt. Oder ganz
visionär: Man baut in Eclipse einen Webeditor, der in integrierten
Textfeldern die Editor-Funktionen von Eclipse bereitstellt. Da bekäme man
dann viel von der Projektverwaltung usw. für die Webanwendung zum
webanwendungsbauen geschenkt.

Ich würde mich jetzt sogar hinstellen und behaupten, du kannst einen
Webmacs in JavaScript bauen, jedenfalls eine Näherung, sodass der
Emacs-Anfänger keinen großen Unterschied sieht.  Scheme-Interpreter in
JavaScript gibt es jedenfalls :)

Nein, die Herausforderung wäre schnelles Syntaxhighlighting. Das normale
<textarea> ist ja ungefähr so komfortabel wie notepad.

Man müsste also stattdessen das benutzen, was Mozilla Midas nennt und
Microsoft mit dem contenteditable-Attribut realisiert. Dann mit einem
Listener jede Änderung des Dokuments erfahren, mit regulären Ausdrücken
Regionen finden, dann dort span-Elemente mit der entsprechenden
CSS-Klasse einfügen und alte span-Elemente entfernen. Und das alles mit
umständlichen DOM-Befehlen.

Das scheint aber tatsächlich zu gehen (falls die das so machen):
http://demo.aboutedit.com. Wow, ich bin beeindruckt.

 > Ideal wäre dann noch ein

    http://vowe.net/archives/005723.html

 > Ich brauchte einen Moment, bis ich die letzte

Zu obigem Beispiel zu bemerken ist übrigens noch, dass die Funktion
endrekursiv ist, was die "normale" Fakultätsfunktion nicht ist. Scheme -
das Endrekursionen erkennen und optimieren muss - würde obigen Code mit
konstantem Speicherbedarf auswerten.

Eine call/cc-Variante der Fakultätsfunktion wäre:

  (define (fac/cc n)
    (let* ((r 1) (k (call/cc (lambda (k) k))))
      (set! r (* r n))
      (set! n (- n 1))
      (if (= n 0) r (k k))))

Übrigens, in diesem Zusammenhang: Jemand hat gerade continuations in die
Mono VM eingebaut: http://bat.org/~tomba/monoco.html

Das hat aber auch gute Gründe, denn man verbaut sich ansonsten einiges
an Optimierungen.  Da es in Smalltalk sehr selten ist, dass man wirklich
explizit auf den Context zugreift, so erzählte mir der Autor der
VisualWorks-VM mal, haben die dort quasi zwei Betriebsmodi. Den
normalen, wo optimiert wird und die Context-Objekte eigentlich gar nicht
existieren und den, der es so macht, wie Smalltalk-80 spezifiziert ist
und Änderungen am Kontext erlaubt.

Unter Mac und Linux könnte man den Java-HTML-Renderer verwenden (gab's doch
irgendein Swing-Control für?). Bis das Projekt fertig ist, hat Sun das
vielleicht soweit hinbekommen, daß aktuelle Webseiten vernünftig
dargestellt werden :-)