While hvac, which I announced here recently, is not yet ready for primetime, so to speak, you may want to take a look at it -- with a few tweaks it should match your specs. (darcs get http:// community.haskell.org/~sclv/hvac/)

It does include some templating, though you don't have to use it significantly, but then again, I find it hard to automate data validation without it (how else do you control showing results?), and it does allow for session support, although it isn't necessary.

It is, however FastCGI based and has built-in connection pooling. It should theoretically be able to speak to any database that HDBC speaks to, although it does need a little work (here's the modification issue) to ensure the strong atomicity constraints work properly with anything but sqlite.

Additionally, the validation functionality should be very powerful and intuitive, and the control flow combinators equally so, which are also written to parse RESTful parameters as part of url strings as well.

Not sure what you mean by marshalling to-from Haskell types -- the validation provides one side of it, and on the other, as you well know, HDBC gives a very convenient way to deal with the SQL end :-)

The less tested/more dicey parts of hvac are all those that deal with atomicity and caching, and if you're not relying on those, then that shouldn't be an issue either. And the only questions there, in my mind at least, are to what degree running everything out of STM (i.e. optimistically) could lead to problems in high-contention environments -- so again, possibly not an issue for your needs in any case.

As for event model -- hvac tries to be nonjudgemental, though it is request rather than continuations-based and is mainly designed to be REST. One could implement a "conversations" layer over sessions without too much work -- alternately, control flow can be parameter based, much as one would do in plenty of other web frameworks.

Finally, although the atomic stuff is what makes hvac fun, one could rip out either the controller or validation sections without too much work and act directly over FastCGI. On its own even, the FastCGI lib isn't perfect, but as Paul Brown noted, its not too hard to build a few nice structures on top of it to handle whatever you throw at it.

Regards,
Sterl.

On Mar 27, 2008, at 3:26 PM, John Goerzen wrote:

Hi again,

I'm currently working on a project that has a Web interface to data
stored in a SQL database.  I wrote this thing in WASH a few years
back.  Overall, this has been acceptable, but the non-Haskell-adepts
around here run away screaming from the code.  Not only that, but we
don't get control over the names of the form elements, which can make
interacting with other software that sometimes plonks users down
halfway through the process -- well, interesting.  Also, WASH supports
nothing better than CGI, which is a big minus when talking to SQL databases.

What I really want is some sort of simple tool that supports FastCGI
or some such, has basic support for form data input validation and
marshalling to/from Haskell types, and basic control flow.  I don't
need, or really particularly want, something that uses hs-plugins to
compile pages on demand (I'm using Haskell for it's static safety,
after all).  Nor do I need fancy templating systems or session support
(we use HTTP auth and are fine with it for now.)

So I've looked around a bit at the landscape.  Any recommendations?

I've found these:

HSP: big on "dynamic pages".  I don't want to make my webserver able
to compile Haskell code.  Develop code, compile, test, make sure it's
right, then push to production every 6 months around here.

WASH: Pretty much the right niche, but the event model is hard to use.

HAppS: Frankly it is a big collection of confusing packages to me. What
documentation exists doesn't seem to be relevant anymore, and it seems
to be designed to not use a SQL database.

FastCGI: Relies upon CGI for a good part of processing.  Does not seem
to have any form data validation support built in.

Thanks again,

-- John


_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Reply via email to