Hi,
I'm relatively new to both Lisp and Hunchentoot, and I've got a question about how experienced developers go about working on a hunchentoot site. Specifically, I've made myself a helper macro to wrap define-easy-handler and make it simpler to add handlers from the REPL. I find that every time I use it, it adds a new entry to the *dispatch-table*. Most often, I'm redefining an existing handler (to expand or correct it) and would rather overwrite that handler with its new version, rather than adding a new entry. I'm finding it awkward to modify my macro so that it checks for an existing handler with that function name and overwrites it – more importantly I'm not certain this is the best way to do it.
If any more experienced users were willing to share how they address this issue, and in general what tools they've made to assist in developing a hunchentoot site, this newbie would be very grateful.
Thanks, Eric
On Tue, Mar 10, 2009 at 7:53 AM, Eric Abrahamsen girzel@gmail.com wrote:
Most often, I'm redefining an existing handler (to expand or correct it) and would rather overwrite that handler with its new version, rather than adding a new entry. I'm finding it awkward to modify my macro so that it checks for an existing handler with that function name and overwrites it – more importantly I'm not certain this is the best way to do it.
DEFINE-EASY-HANDLER should overwrite existing handlers of the same name (or if they have the same - EQUAL - URI part). If it doesn't do that, it's a bug.
Edi.
On Tue, Mar 10, 2009 at 11:28 AM, Edi Weitz edi@agharta.de wrote:
On Tue, Mar 10, 2009 at 7:53 AM, Eric Abrahamsen girzel@gmail.com wrote:
Most often, I'm redefining an existing handler (to expand or correct it) and would rather overwrite that handler with its new version, rather than adding a new entry. I'm finding it awkward to modify my macro so that it checks for an existing handler with that function name and overwrites it – more importantly I'm not certain this is the best way to do it.
DEFINE-EASY-HANDLER should overwrite existing handlers of the same name (or if they have the same - EQUAL - URI part). If it doesn't do that, it's a bug.
Maybe he is referring to the fact, that after redefining the DISPATCHER, the running server's dispatch table remains unchanged. In the sense, that the server continues to use the dispatcher closures, created at the time of the server start. At least for me it works this way (in old Hunchentoot): when I redefine a dispatcher, I need to modify the dispatch table (or plainly restart the server) for the change to take effect.
To clarify, I'd like to add, that I refer to the handler functions as per the docs (e.g. html-generation functions). They take no arguments and are responsible for forming the reply object. If you redefine them, it has immediate effect. Dispatchers are the closures in the dispatch-table, that take 1 argument -- request. If you redefine the dispatcher (for example, with define-easy-handler, or manually), somehow, it doesn't effect the running server's dispatch-table.
On Tue, Mar 10, 2009 at 11:04 AM, Vsevolod vseloved@gmail.com wrote:
Maybe he is referring to the fact, that after redefining the DISPATCHER, the running server's dispatch table remains unchanged.
I don't think so. He said that each time he redefines an easy handler a new entry is added.
In the sense, that the server continues to use the dispatcher closures, created at the time of the server start. At least for me it works this way (in old Hunchentoot): when I redefine a dispatcher, I need to modify the dispatch table (or plainly restart the server) for the change to take effect.
To clarify, I'd like to add, that I refer to the handler functions as per the docs (e.g. html-generation functions). They take no arguments and are responsible for forming the reply object. If you redefine them, it has immediate effect. Dispatchers are the closures in the dispatch-table, that take 1 argument -- request. If you redefine the dispatcher (for example, with define-easy-handler, or manually), somehow, it doesn't effect the running server's dispatch-table.
That shouldn't be the case with the 1.0.0 version. See how list-request-dispatcher works.
Edi.
On Mar 10, 2009, at 6:58 PM, Edi Weitz wrote:
On Tue, Mar 10, 2009 at 11:04 AM, Vsevolod vseloved@gmail.com wrote:
Maybe he is referring to the fact, that after redefining the DISPATCHER, the running server's dispatch table remains unchanged.
I don't think so. He said that each time he redefines an easy handler a new entry is added.
Sorry, nothing mysterious is happening. My stupid helper macro includes a create-prefix-dispatcher call and a push to *dispatch- table*, so obviously it pushes something new to the *dispatch-table* every time I call it. Using a plain old defun to redefine an existing handler does exactly what it should – my problem was a confusion about how lisp works, not about how hunchentoot works, and I apologize for the noise.
Back to mucking about, Eric
In the sense, that the server continues to use the dispatcher closures, created at the time of the server start. At least for me it works this way (in old Hunchentoot): when I redefine a dispatcher, I need to modify the dispatch table (or plainly restart the server) for the change to take effect.
To clarify, I'd like to add, that I refer to the handler functions as per the docs (e.g. html-generation functions). They take no arguments and are responsible for forming the reply object. If you redefine them, it has immediate effect. Dispatchers are the closures in the dispatch- table, that take 1 argument -- request. If you redefine the dispatcher (for example, with define-easy-handler, or manually), somehow, it doesn't effect the running server's dispatch-table.
That shouldn't be the case with the 1.0.0 version. See how list-request-dispatcher works.
Edi.
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
-
Edi Weitz -
Eric Abrahamsen -
Vsevolod