[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-users] Starting up spiffy for dynamic content
From: |
Peter Bex |
Subject: |
Re: [Chicken-users] Starting up spiffy for dynamic content |
Date: |
Tue, 8 Mar 2016 21:41:41 +0100 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Tue, Mar 08, 2016 at 02:48:00PM +0000, Norman Gray wrote:
> Peter, hello.
>
> Thanks for these clarifications.
You're welcome.
> 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)))
> (cont))))
> (vhost-map `((".*" . ,vhost-handler)))
That's how it was intended, yes. I've added something similar to the
wiki with a link to slightly extended (but somewhat outdated) example
from a demonstration.
The introduction does mention in passing that you'd add custom path
handlers to the vhost-map.
> 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.
Well, it is a mapping for which handler to use for which vhost. That
is also the topmost place where dispatching happens for incoming
requests, so it's the place where you'd add custom handlers.
I could add some intermediate parameter like "request-handler", which
then defaults to some procedure that handles the request like the
current implementation does (try to serve a file), but it would be
one more level of indirection which is basically just what "continue"
does now.
Would that be sensible?
> 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.
Not sure that would be much clearer. Also, it would break compatibility.
> 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:
>
> (handle/host
> `(,my-general-handler
> ("foo\\.bar\\.com" . ,(lambda (continue) ...))
> (#t . ,my-catch-all-handler))
I think that would only complicate things, and cause more confusion
as to the format of this list.
> 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.
It's a wiki, feel free to improve the wording in places where it's
unclear. I've been using Spiffy for too long to see these missing
pieces.
> Thanks again for the illumination.
No problem!
Cheers,
Peter
signature.asc
Description: Digital signature