[web-devel] Hoogle Advice

Jeremy Shaw jeremy at n-heptane.com
Tue Jan 25 18:35:57 CET 2011

On Jan 25, 2011, at 1:33 AM, Bardur Arantsson wrote:
> I'm actually considering using WAI for two of my projects as well. I  
> haven't had the time to actually try it, but I'm pretty sure I'll be  
> doing it for at least one of these projects.
> The second one *is* a framework (just started, hopefully I'll  
> actually finish it) for Rich Internet Applications a la Wicket,  
> Vaadin and Echo3. Essentially you (as the framework user) program  
> your application in a "magical" monad which turns widgets,  
> components and other logic into a combination of browser JavaScript/ 
> Ajax calls and server-side logic for processing state updates. I  
> think using a low-level API like WAI is also quite justified in this  
> case simply to avoid huge dependencies. The only thing that I'm  
> likely to have to "reimplement" is a little bit of routing (but  
> that's a trivial amount) and some handing of cookies/sessions  
> (though I may be able to avoid that in the short term). There will  
> also be some autogenerated JavaScript and such, but that's such a  
> niche thing that I wouldn't really expect much support from a  
> general framework for such a thing anyway.

I think there are a lot of things you might want from a slightly  
higher level framework like happstack-server. Note that you can  
install happstack-server with out happstack-state or any of the  
templating libraries.

You could then create your magical monad by adding some additional  
layers to the ServerPartT monad transformer. By using happstack-server  
you would get access to:

  1. RESTful-style routing combinators like (dir, path, etc), or type- 
safe urls via web-routes
  2. a cookie API
  3. a rich API for serving static files (which  handles things like  
'if-modified-since' automatically)
  4. a rich API for extracting values from cookies, query parameters,  
and the request body
  5. support for file uploads
  6. support for automatic compression of Response bodies

And the default ServerPartT monad gives you easy support for accessing  
the Request, applying filters to the Response, aborting/escaping the  
current computation and returning a different Response, support for  
throw/catch, and more.

I have done some work on trying to create a high-level haskell DSL  
which automatically generates client-side javascript+html,  
communication via JSON, etc. I personally found building on top of  
happstack to be useful.

The dependency list for happstack-server is not all that different  
from wai+wai-extra+warp. So concerns of a 'huge dependency list' are  
perhaps overblown.

The point being -- if happstack-server were built on top of WAI today,  
so that the choice was between wai or happstack+wai, I would still  
recommend that you consider happstack+wai as your foundation not just  
wai. :)

- jeremy

p.s. I am interested in possibly moving happstack to be built on top  
of WAI. I even did an experimental port once just to confirm that it   
would be feasible. The biggest hold up at the moment is probably the  
lack of timeout handling in warp. Though maybe that has been added now ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/web-devel/attachments/20110125/9207d3e7/attachment-0001.htm>

More information about the web-devel mailing list