[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-users] Starting up spiffy for dynamic content

From: Norman Gray
Subject: Re: [Chicken-users] Starting up spiffy for dynamic content
Date: Tue, 08 Mar 2016 14:48:00 +0000

Peter, hello.

Thanks for these clarifications.

On 8 Mar 2016, at 12:40, Peter Bex wrote:

On Tue, Mar 08, 2016 at 12:02:29PM +0000, Norman Gray wrote:
It occurred to me that I could/should use the vhost-map to do this
dispatching, using something like

(vhost-map `((".*" . ,(lambda (continue) ... and ignore (continue)))))

But (a) that would clearly be a hack

Actually, that's how it was designed to be used.  Not a hack at all!


and (b) it appears that that's designed to be able to re-parameterise
a request, rather than handle it itself,

It's intended to be used like that, and you *may* re-parameterise (but
that's not necessary).  The idea is that you can create "components"
which can be chained together, influencing their sub-components by
simply parameterising some options and then passing the flow on to
continue.  The last component in the sequence would then actually
serve the request.

So you mean including handlers like:

(define (vhost-handler cont)
  (let ((uri (uri-path (request-uri (current-request)))))
(if (string=? (cadr uri) "wibble") ;; we want to handle URIs like /wibble/...
        (send-response status: 'ok
body: (format "<p>Good: request was ~S (vhost)</p>" uri)
                       headers: '((content-type text/html)))
(vhost-map `((".*" . ,vhost-handler)))

OK: that's a (very) nice design -- I'll do that.

But may I suggest that vhost-map is not, perhaps, the best name for this structure, since the intended functionality is much more general than mapping vhosts. As I mentioned, I guessed that might be a route to the solution, but based on the name, on the fact it's documented in a section called 'Virtual hosts', and since the example in that section is about handling virtual hosts, I got the impression that the author was firmly steering me away from more open-ended cleverness. Caolan suggested that I'm not (thankfully) alone in misinterpreting this.

Perhaps dispatch-handler-map, or handler-map, or something like that, would signal the intent more clearly, along with an example such as the above. Since the car of the alist is a host pattern, then perhaps the word 'host' should be in the name, but in that case perhaps handle/host might be suitable (and if anything's being changed, then it might be nice to have a clear catch-all host pattern, such as #t, or to permit the list elements to be a continuation thunk as well as a string-thunk pair). Thus:

   ("foo\\.bar\\.com" . ,(lambda (continue) ...))
   (#t . ,my-catch-all-handler))

The final possibility is to use intarweb directly, but that's
unappealing, since it would require me cut-and-pasting quite a lot
of the content of spiffy.scm.

Now *that* would be a hack ;)

Not half!

Where this is coming from: I'm pretty familiar with the Racket
servlet framework which requires, in serve/servlet
<>, a
request->response mapping function.

If I'm missing something really obvious, then apologies, and could
someone hand me the clue-stick?

I think you're coming at this from a slightly wrong angle with some
preconceptions that prevent you from using the system as designed,
because you did figure out how to use it (you came up with two valid
solutions to the problem) but rejected them offhand.

Some preconceptions, yes, but I've used enough frameworks such as this to make sure that I keep such preconceptions pretty lightweight, so they're merely a guide as a search for how the system wants to be used. I thus did find vhost-map quickly, but the documentation appeared to be telling me I was in the wrong place.

Thanks again for the illumination.

All the best,


Norman Gray  :
SUPA School of Physics and Astronomy, University of Glasgow, UK

reply via email to

[Prev in Thread] Current Thread [Next in Thread]