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.

Being one of the main developers of HSP, I guess I should reply to this. :-) HSP is indeed big on dynamic pages, if by dynamic you mean pages that can return different results on different calls. The compile-on-demand feature used to be a part of the old runtime for HSP, but in the current incarnation that has been lifted out. And HSP as such is much more a programming model - an API basically - than any particular deployment scheme. HSP's basic model is much more low-level than e.g. WASH, as we haven't really had time to add any flesh to the bare bones yet. But looking at the bright side, at least we don't have a hard to use event model... And HSP would definitely give you control over the names of elements if you find that you need it. There is - currently - no built-in support for form validation in HSP, bare bones and all that, but it's definitely a feature that we would *like* to support. We just haven't gotten there yet. So if you wanted to use HSP, we would be happy to accept a feature request from you. It would be great to be able to have actual use cases to work with to help the design of such form validation. Easy support for SQL databases is another feature high up on the wish list. Right now it should be about as easy as as from any other Haskell application, except... ...HSP also currently only supports CGI, but that's perhaps the number one priority to get it working in different environments. We were thinking primarily of using the HAppS server utility as a runtime environment, but FastCGI support would perhaps be an even easier task. Again, a feature request would be most welcome, with some ideas for what you want to get out of the FastCGI integration. Also, one of the explicit design goals of HSP from the very beginning has been to make it easy to understand for non-Haskell users. Just like PHP allows you to take the step from writing static HTML pages to writing dynamic PHP pages without pause, we wanted to "lure" prospective web programmers into the Haskell world and in the darkness bind them... Maybe something for your co-workers? :-) So to summarize, HSP is a very simple model - perhaps *too* simple right now - and aims to support much of what you ask for in a not too distant future. Please drop a few feature requests our way so we have something tangible to work with. Feature requests go here: http://code.google.com/p/hsp/issues/entry Cheers, /Niklas

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