[web-devel] A separation of concerns

[Jeremy Shaw]

I agree with the small libraries path as well. In some sense, the future of
happstack is to not exist at all. The parts of happstack should be further
modularized and generalized until they are not happstack specific.
Ultimately, though, there is a need for some glue code to bring all the
pieces back together. But there should be a wide variety of pieces to pick
from.

We have already split happstack-server and happstack-state so that neither
depends on the other.  I have also been wanting to split happstack-server
into smaller chunks that could possibly be used independently. The attempt
to port happstack-server to happstack-wai is a step in that direction.

Happstack itself does not really have any templating libraries. But it
supports Text.XHtml, HStringTemplate, HSP, and formlets. And it is trivial
to add support for other things as well.

In my experience there is usually some glue code that is needed to make the
various libraries work together. But at the same time, the libraries
themselves do not really need to be happstack specific. For example, the
four libraries listed above where all developed independently of happstack.
And, I wrote a happstack-facebook library, but the 'happstack' specific
portion of it is very small. If I had more time to work on it I would finish
refactoring it so that it could be used with non-happstack apps as well.

- jeremy





On Mon, Mar 15, 2010 at 11:33 AM, Chris Eidhof <chris at eidhof.nl> wrote:

> Hi everyone,
>
> I don't believe that there could be one big framework for everybody. Some
> people want good HTML abstractions, others only think of the server as data
> storage. Some people want RESTful URLs, other people don't care about
> RESTfulness but would benefit heavily from controller abstractions. For
> certain applications SQL might be perfect and for others the Happstack-State
> works great.
>
> My point is: we should not try to build one big framework. Instead, I
> propose that we build a set of smaller libraries that each do one thing very
> well. Some of these libraries might be designed to work together.
>
> I personally think MVC is a perfect fit for the web: model code handles
> data storage, view code handles HTML/JSON/XML and the controller coordinates
> between these. Instead of building packages that do all of these things, I
> would like to see model packages, view packages and controller packages.
> That way we can achieve maximum reusability and a good separation of
> concerns.
>
> What do you think of this?
>
> -chris
>
> _______________________________________________
> web-devel mailing list
> web-devel at haskell.org
> http://www.haskell.org/mailman/listinfo/web-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/web-devel/attachments/20100315/25f90aea/attachment-0001.html