[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