<div>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. </div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div><div><br>
</div><div>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 &#39;happstack&#39; 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.</div>
<div><br></div><div>- jeremy</div><div><br></div><div><br></div><div><br></div><div><br></div><br><div class="gmail_quote">On Mon, Mar 15, 2010 at 11:33 AM, Chris Eidhof <span dir="ltr">&lt;<a href="mailto:chris@eidhof.nl" target="_blank">chris@eidhof.nl</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi everyone,<br>
<br>
I don&#39;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&#39;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.<br>


<br>
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.<br>
<br>
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.<br>


<br>
What do you think of this?<br>
<br>
-chris<br>
<br>
_______________________________________________<br>
web-devel mailing list<br>
<a href="mailto:web-devel@haskell.org" target="_blank">web-devel@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/web-devel" target="_blank">http://www.haskell.org/mailman/listinfo/web-devel</a><br>
</blockquote></div><br>