|
From: | Kristian Lein-Mathisen |
Subject: | Re: [Chicken-users] Starting up spiffy for dynamic content |
Date: | Thu, 10 Mar 2016 01:11:21 +0100 |
Peter, hello.
On 8 Mar 2016, at 20:41, Peter Bex wrote:
On Tue, Mar 08, 2016 at 02:48:00PM +0000, Norman Gray wrote:
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 new section 'A simple dynamic web page example' is perfect, in combination with the pointer to the spiffy+sxml example.
I marginally adjusted the linked webserver.scm to use sxml-serializer rather than the full-blown sxml transform egg (was that the 'outdated' you meant). I've attached the result.
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?
I don't think that would be necessary and would, as you say, be a further level of indirection. Yesterday afternoon, I did put together a potential patch for spiffy.scm which may have the same idea (attached for interest), but the vhost-map (once one understands what it's intended for) seems to be completely general.
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.
Indeed: it's not obvious what the best name is, though 'handle/host' seemed to push the right buttons for me.
One would of course export a (define vhost-map fancy-new-name) for 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.
I agree.
It's a wiki, feel free to improve the wording in places where it's
unclear.
There's nothing I can usefully add to the change you've made, but I'll bear the suggestion in mind for what I expect to be lots of future engagement with these docs.
And thanks, Andy, for the pointer to uri-match (and for the mention of Knodium, which I intend to investigate further).
All the best,
Norman
--
Norman Gray : https://nxg.me.uk
SUPA School of Physics and Astronomy, University of Glasgow, UK
_______________________________________________
Chicken-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/chicken-users
[Prev in Thread] | Current Thread | [Next in Thread] |