Ich finde, dass die inkrementelle Entwicklung dazu neigt, beim Kodieren von Hunchentoot zu brechen.
Zum Beispiel könnte ich eine Webseite schreiben, die aus ein paar Funktionen besteht. Wenn eine dieser inneren Funktionen einen Aufruf an - sagen wir - hunchentoot: post-parameters * enthält, kann ich die Funktion in der REPL nicht einfach testen. Es tritt ein Fehler auf, weil * Anfrage * nicht existiert, bis die Seite von einem Webclient aufgerufen wird.
Es wäre schön, wenn eine Funktion oder eine andere Quelle existieren würde, so dass ich meine Funktion testen könnte:
%Vor%Existiert es oder etwas Ähnliches? Habe ich einen besseren Ansatz zum Debuggen übersehen?
Ich denke, die einfachste Sache wäre die Verwendung einer benutzerdefinierten Anforderungsklasse, die eine Möglichkeit bietet, Anforderungen irgendwo in der Initialisierungskette zu persistieren.
Hier ist ein triviales Beispiel für einen Ansatz. Eine benutzerdefinierte Unterklasse der Anfrage, die ihren Status in einem globalen Stapel speichert.
Sie können Ihre Akzeptoren so einstellen, dass sie benutzerdefinierte Anfrageklassen mit
verwenden (setf (acceptor-request-class acceptor ) new-value)
so etwas wie das
%Vor%und legen Sie dann die Akzeptoranforderungsklasse fest, um diese zu verwenden, wenn Sie Ihren Akzeptor z.
%Vor% Jedes Mal, wenn eine Anforderung von diesem Akzeptor zum Übergeben an den Handler erstellt wird, wird er der Liste *requests* hinzugefügt.
Wenn Sie eine Variable verwenden, um den Namen der Anfrageklasse anzugeben, können Sie diese Klasse für Entwicklung / Debugging ein- und ausschalten.
Sie könnten dann Anfragen von diesem Stapel in Ihrer Testbindung übernehmen.
Tags und Links debugging lisp common-lisp hunchentoot