Comments on: Some concepts behind hvac

By: Art Silver

Art Silver — Wed, 18 Mar 2009 00:39:05 +0000

I’m looking forward to more about templates.

By: Jochem Berndsen

Jochem Berndsen — Fri, 26 Dec 2008 00:37:01 +0000

After some fiddling with hvac + lighttpd, I came to the conclusion that the lighttpd-packages in Debian testing are *broken*. (Maybe also in Ubuntu). The latest version on 1.4.20 works, however. My config, for the example, is as follows:

server.document-root = “/var/www”
server.modules = ( “mod_fastcgi” )
server.port = 3000

fastcgi.debug = 1
fastcgi.server = ( “/test” =>
(
(
“socket” => “/tmp/test.sock”,
“bin-path” => “/path/to/hvac-board”,
“min-procs” => 1,
“max-procs” => 1,
“check-local” => “disable”
)
)
)

By: sclv

sclv — Fri, 23 May 2008 03:42:50 +0000

And now checked in at the darcs repo (http://code.haskell.org/~sclv/hvac/) we have such an api. Pleasantly for me, since its equivalent and simpler, it cleans up the code a bit. Import Network.Frameworks.HVAC.AltController and you get: path, meth, param, takePath, readPath, and endPath. The above code that gets a “board” from the path then a boardId, then “new” then checks that it is a post can be written (in a do block):

  path “board”
  boardId <- readPath
  newPost boardId <|> showBoard boardId

newPost boardId = do
path “new”
(meth “POST” >> {- POST stuff-}) <|> {- GET stuff -}

showBoard boardId = do {- other stuff -}

Wordier and more irritating in my opinion, although it makes the parser connection clear.

This can be condensed into e.g.:

path "board" >> readPath >>= \boardId ->
  (path "new" >>
    (meth "POST" >> {- POST stuff -}) <|> {- GET stuff -})
   <|>
    {- other stuff -}

which then looks more obviously like a wordier version of the code above, so the nature of how its condensed becomes more clear. All the ugly parens also make it clear why one wants to mix and match *> as well, which is just >> with a precedence that's higher than <|>.

By: sclv

sclv — Fri, 23 May 2008 02:38:19 +0000

sigh. dbpatterson encouraged me not to, but on to Network.Frameworks.HVAC.AltController it is…

By: gwern

gwern — Fri, 23 May 2008 02:09:31 +0000

sclv, I’ve got to agree with Justin. The code may be elegant, but my eyes are hurting. I can’t immediately figure out what’s being escaped (if at all), what’s adding a lambda binding, what’s combinator A, what’s combinator B…

I mean, just ow in general, y’know?

By: sclv

sclv — Thu, 22 May 2008 14:42:50 +0000

The withValidation function stashes errors away elsewhere in the request scope. Then it “falls though” to the next possible action, just as a failed parse would. So a pattern that works pretty well I’ve found for certain types of forms is to manage them as postbacks, where on failure of a POST they fall through to the GET handler, which in turn renders the errors as part of the form page. On success you either display a new page, or redirect.

There’s also a handleValidation function that rather than falling through takes an explicit “failure” continuation that’s a function of the errors.

I don’t have named variants of the operators at the moment, but rather than an alternative more traditional “parser-like” api, it might be easier just to provide those. That’s a nice idea.

ie. |/ = `andPath`, |// = `withMethod`, |\ = `withUrlParam`.

On the other hand, I tried to give things names that were obvious mnemonics, but maybe the associations just work for me. The forward slash is as with a path, the two slashes are as with those following a protocol, the backslash is as with a lambda, etc.

By: Justin Bailey

Justin Bailey — Wed, 21 May 2008 21:34:03 +0000

I like the idea of parsing controlling what code gets run. Slick. The discussion on scopes was also intriguing and I’d like to see where you go with that. What are some drawbacks you’ve found when trying to work this way (that is, where current scope is very well defined).

Just a comment on readability. I see |\, /| and |//. Do you have equivalents that are named? I don’t find your operators terribly readable. They probably make a lot of sense once you’ve used the framework awhile, but consider adding some aliases to them for us newbs.

Finally, how do you deal with validation failures?