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
+1. I wrote another e-mail just a bit ago listing some library projects that I thought should be attacked. Perhaps we should start a Wiki page with a "web programming wishlist", rank it by difficulty and priority, and try to encourage collaboration that way? On Mon, Mar 15, 2010 at 9:33 AM, Chris Eidhof <chris@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@haskell.org http://www.haskell.org/mailman/listinfo/web-devel
On Mon, Mar 15, 2010 at 5:33 PM, Chris Eidhof <chris@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.
While I think there is space for frameworks as a way to help developers structure web applications I agree with the call for smaller libraries. In fact, one of the best things that happened to Haskell web development the last few months is in my opinion the 'text' library. Even though it has nothing to do with web development per se it solves an important problem for web development, namely having a space efficient, fast and correct data type for Unicode text. The reason I pick the 'text' library as an example is that I think it exemplifies the kind of libraries we need more of: well-test, high-performance, and well-documented libraries. There are lots of small libraries that are still missing. For example an equivalent of Python's urllib, a really fast and *simple* HTTP server, a high-performance and *full features* database library for working with e.g. MySQL, etc. Cheers, Johan
On Mon, Mar 15, 2010 at 9:57 AM, Johan Tibell <johan.tibell@gmail.com>wrote:
On Mon, Mar 15, 2010 at 5:33 PM, Chris Eidhof <chris@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.
While I think there is space for frameworks as a way to help developers structure web applications I agree with the call for smaller libraries. In fact, one of the best things that happened to Haskell web development the last few months is in my opinion the 'text' library. Even though it has nothing to do with web development per se it solves an important problem for web development, namely having a space efficient, fast and correct data type for Unicode text. The reason I pick the 'text' library as an example is that I think it exemplifies the kind of libraries we need more of: well-test, high-performance, and well-documented libraries.
There are lots of small libraries that are still missing. For example an equivalent of Python's urllib, a really fast and *simple* HTTP server, a high-performance and *full features* database library for working with e.g. MySQL, etc.
Is there a reason you count out Hyena as a good HTTP server? After all, you are the expert on it ;).
Michael
On Mon, Mar 15, 2010 at 6:05 PM, Michael Snoyman <michael@snoyman.com> wrote:
On Mon, Mar 15, 2010 at 9:57 AM, Johan Tibell <johan.tibell@gmail.com> wrote:
While I think there is space for frameworks as a way to help developers structure web applications I agree with the call for smaller libraries. In fact, one of the best things that happened to Haskell web development the last few months is in my opinion the 'text' library. Even though it has nothing to do with web development per se it solves an important problem for web development, namely having a space efficient, fast and correct data type for Unicode text. The reason I pick the 'text' library as an example is that I think it exemplifies the kind of libraries we need more of: well-test, high-performance, and well-documented libraries.
There are lots of small libraries that are still missing. For example an equivalent of Python's urllib, a really fast and *simple* HTTP server, a high-performance and *full features* database library for working with e.g. MySQL, etc.
Is there a reason you count out Hyena as a good HTTP server? After all, you are the expert on it ;).
It's not done! I have a large number of changes on my local machine that I haven't had time to finish up yet. It lacks benchmarks, sufficient test coverage, and documentation (including tutorials). It's simply not polished enough yet and doesn't incorporate what I've learned about Haskell server development the last year or so. I do plan to return to Hyena after finishing up some lower level stuff like the event library -- yes, I'm yak shaving. Cheers, Johan
On Mon, Mar 15, 2010 at 10:12 AM, Johan Tibell <johan.tibell@gmail.com>wrote:
On Mon, Mar 15, 2010 at 6:05 PM, Michael Snoyman <michael@snoyman.com> wrote:
On Mon, Mar 15, 2010 at 9:57 AM, Johan Tibell <johan.tibell@gmail.com> wrote:
While I think there is space for frameworks as a way to help developers structure web applications I agree with the call for smaller libraries. In fact, one of the best things that happened to Haskell web development the last few months is in my opinion the 'text' library. Even though it has nothing to do with web development per se it solves an important problem for web development, namely having a space efficient, fast and correct data type for Unicode text. The reason I pick the 'text' library as an example is that I think it exemplifies the kind of libraries we need more of: well-test, high-performance, and well-documented libraries.
There are lots of small libraries that are still missing. For example an equivalent of Python's urllib, a really fast and *simple* HTTP server, a high-performance and *full features* database library for working with e.g. MySQL, etc.
Is there a reason you count out Hyena as a good HTTP server? After all, you are the expert on it ;).
It's not done! I have a large number of changes on my local machine that I haven't had time to finish up yet. It lacks benchmarks, sufficient test coverage, and documentation (including tutorials).
It's simply not polished enough yet and doesn't incorporate what I've learned about Haskell server development the last year or so.
I do plan to return to Hyena after finishing up some lower level stuff like the event library -- yes, I'm yak shaving.
While we're discussing Hyena, is there any possible of it using the wai package? I wouldn't mind doing the grunt work of porting it over (in fact, I already started this).
Michael
On Mon, Mar 15, 2010 at 6:24 PM, Michael Snoyman <michael@snoyman.com> wrote:
While we're discussing Hyena, is there any possible of it using the wai package? I wouldn't mind doing the grunt work of porting it over (in fact, I already started this). Michael
I appreciate the offer. However, I'd prefer if the WAI was done with a separate compatibility layer on top (in a separate package) for now. The reason is that I have a big uncommited refactoring sitting on my laptop that changes the internals a lot (by using a new definition of iteratees) and changes the API a little bit. By using a compatibility layer you wouldn't have to change much when the next version of Hyena comes out. Cheers, Johan
On 15 mrt 2010, at 17:57, Johan Tibell wrote:
There are lots of small libraries that are still missing. For example an equivalent of Python's urllib, a really fast and *simple* HTTP server, a high-performance and *full features* database library for working with e.g. MySQL, etc.
Ok, so let's try to make a list. Here's some stuff I would like to see. "Low level" stuff - Fast, simple HTTP server with no abstractions - IMAP library Data storage - abstraction of relational databases (something like HaskellDB? based on Takusen?) - abstraction of nosql databases - purely functional databases (something like Happstack?) Controller abstractions - a good URL routing library (where you can only produce and link to valid urls) - a serializable continuations-based library (especially the serializable part is hard), something like Clean's iTasks. View abstractions - High-performance HTML combinators - generic programming for the web - simplified formlets - abstractions over "web components", e.g. composable components that contain HTML, CSS and Javascript. maybe composed using something like FRP. Please add to this list or expand where necessary. Maybe we should put this on a wiki page. -chris
On Mon, Mar 15, 2010 at 9:00 PM, Chris Eidhof <chris@eidhof.nl> wrote:
On 15 mrt 2010, at 17:57, Johan Tibell wrote:
There are lots of small libraries that are still missing. For example an equivalent of Python's urllib, a really fast and *simple* HTTP server, a high-performance and *full features* database library for working with e.g. MySQL, etc.
Ok, so let's try to make a list. Here's some stuff I would like to see.
Good list!
"Low level" stuff - Fast, simple HTTP server with no abstractions
I plan to take a stab at this after I'm done with the event library.
- IMAP library Data storage - abstraction of relational databases (something like HaskellDB? based on Takusen?) - abstraction of nosql databases
I'm also interested at writing a client library for Cassandra.
- purely functional databases (something like Happstack?) Controller abstractions - a good URL routing library (where you can only produce and link to valid urls) - a serializable continuations-based library (especially the serializable part is hard), something like Clean's iTasks. View abstractions - High-performance HTML combinators
I created a GSoC project proposal for this here: http://hackage.haskell.org/trac/summer-of-code/ticket/1580
- generic programming for the web - simplified formlets - abstractions over "web components", e.g. composable components that contain HTML, CSS and Javascript. maybe composed using something like FRP.
Cheers, Johan
On Mon, Mar 15, 2010 at 3:00 PM, Chris Eidhof <chris@eidhof.nl> wrote:
On 15 mrt 2010, at 17:57, Johan Tibell wrote:
There are lots of small libraries that are still missing. For example an equivalent of Python's urllib, a really fast and *simple* HTTP server, a high-performance and *full features* database library for working with e.g. MySQL, etc.
Ok, so let's try to make a list. Here's some stuff I would like to see.
Controller abstractions - a good URL routing library (where you can only produce and link to valid urls)
I have a library like that: http://src.seereason.com/urlt/ documented here: http://src.seereason.com/~jeremy/SimpleSite1.html View abstractions
- abstractions over "web components", e.g. composable components that contain HTML, CSS and Javascript. maybe composed using something like FRP.
I have been experimenting with some web component widgets recently. It's very experimental at the moment. Hope to release something soon.. - jeremy
Hi Chris,
- High-performance HTML combinators The first step would be measuring performance of various existing libraries Nothing is faster than caching (?) So maybe we can have faster pages writing cache strategies (?) Not using caching means less dev - time. So I agree on that this can be important.
Data storage - abstraction of relational databases (something like HaskellDB? based on Takusen?) - abstraction of nosql databases - purely functional databases (something like Happstack?)
No matter what you're going to do. It will be compared against the ease of use of use of existing RDBM solutions. You just connect to the database and run arbitrary queries. Also keep in mind that some projects require keeping track of values such as sums or max which is typically done by triggers. Haskell could do this as well.
- a good URL routing library (where you can only produce and link to valid urls) Think about this twice: You can't recompile bigger CMS systems each time you add a link. This may be fine for you personal web page (However you could use Joomla or such for that as well *kidding*)
No matter what you're going to do - Having kind of meta compiler (EDSL) in order to write Flash / JS code would be perfect - and maybe Haskell is the best language to write that. Have a look at the features of HaXe. It's interesting: Write one language and target Flash, JS, PHP, neko virtual machine, (IPhone).. Marc Weber
On Mon, Mar 15, 2010 at 4:23 PM, Marc Weber <marco-oweber@gmx.de> wrote:
Hi Chris,
- a good URL routing library (where you can only produce and link to valid urls) Think about this twice: You can't recompile bigger CMS systems each time you add a link.
What do you mean by 'adding a link' in a bigger CMS. To me that sounds like something which is done by a user interacting with the app via the browser? I don't see that as being in conflict with producing only valid urls... It seems like the system would have two classes of URLs. Ones that are statically known at compile time, and ones that only exist due to the state of the live database. If you want to add new code that refers to a specific page that was created in the live database -- then you do have a potential issue, since you can not guarantee at compile time that the dynamically created page will exactly be there.. The URL routing library ensures that when you are referring to 'static' urls in your code, you only generate valid urls. And the app runtime ensures that dynamically created urls are valid. And when you want to have static code which refers to a page which may or may not exist.. you can still probably benefit from a good URL router.. data CmsUrl = LoginPage | Homepage | ASpecificDynamicLink | DynLink String do u <- showURL ASpecificDynamicLink ... cms :: CmsURL -> URLT CmrURL IO () cms LoginPage = .... cms Homepage = ... cms ASpecificDynamicLink = cms (Dynlink "somelink") cms (DynLink str) = ... What am I missing? - jeremy
On Mon, Mar 15, 2010 at 9:33 AM, Chris Eidhof <chris@eidhof.nl> wrote:
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 completely agree. For our current project we chose Hack mainly because of its simplicity and the fact that it imposes very little requirements on the code around it which is more in keeping with many of the reasons I love working with Haskell to begin with - flexibility chief among them. In fact, I would go so far as to say that any one-stop web framework for Haskell would have to be comprised of may separate libraries that function well on their own first, and then happen to form a cohesive whole to create a more monolithic, if only in spirit, one size fits all framework. Happstack does this to a certain extent but I think there's a lot of room for improvement.
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.
Absolutely.
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@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@haskell.org http://www.haskell.org/mailman/listinfo/web-devel
On Mon, 15 Mar 2010 12:50:07 -0500
"Jeremy" == <jeremy@n-heptane.com> wrote:
Jeremy> I agree with the small libraries path as well. I'm sorry if I was misunderstood as desiring to see one-size-fits-all Haskell web-framework, but I fully agree with stuff like WAI and having bunch of small libs used by several frameworks. However, there is one thing which, iirc, nobody mentioned and I thought about in my original post - that's documentation! It's (lack of) one of things for which Happs(stack) was/is very often criticized, Turbinado was also lacking it, Yesod can improve as well. That's why I consider & hope that some 'consolidation work' on the web scene can bring about better documented web-related projects. Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: F96FF5F6 ----------------------------------------------------------------
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 absolutely agree with that.
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.
Have you read about the "View First" approach of Lift[1]? While I do not like the monolithic approach of Lift, I really like that specific aspect. I'd not narrow my view on "Rails-Style MVC" right now. Cheers, Simon [1] http://wiki.liftweb.net/index.php?title=Lift_View_First
On 3 apr 2010, at 20:36, Simon Hengel wrote:
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 absolutely agree with that.
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.
Have you read about the "View First" approach of Lift[1]? While I do not like the monolithic approach of Lift, I really like that specific aspect. I'd not narrow my view on "Rails-Style MVC" right now.
I have not really looked in to it before, the lift documentation always confuses me, but it looks very interesting! I really like the philosophy behind StringTemplate. I think something similar could be done by restricting a view to be |a -> HTML|. Do you think that's enough? Or should there be more restrictions? -chris
Simon, While I don't have any hands on experience with Lift's approach to templating it looks a lot like asp.net databinding/templates and from my experience with that toolset it ends up being a cumbersome solution to the problem of separating controller and view. I don't necessarily think mixing code into your views is the "one true way" either, but what you sacrifice in controller code clarity seems to outweigh any gains from separating the two so strictly. As an example from http://liftweb.net/docs/getting_started/mod_master.html#x1-130002.7 : <lift:TD.list all_id="all_todos"> <div id="all_todos"> <div>Exclude done <todo:exclude/></div> <ul> <todo:list> <li> <todo:check><input type="checkbox"/></todo:check> <todo:priority> <select><option>1</option></select> </todo:priority> <todo:desc>To Do</todo:desc> </li> </todo:list> </ul> </div> </lift:TD.list> private def doList(reDraw: () => JsCmd)(html: NodeSeq): NodeSeq = toShow. flatMap(td => bind("todo", html, "check" -> ajaxCheckbox(td.done, v => {td.done(v).save; reDraw()}), "priority" -> ajaxSelect(ToDo.priorityList, Full(td.priority.toString), v => {td.priority(v.toInt).save; reDraw()}), "desc" -> desc(td, reDraw) )) In the above you'll notice that the bind has direct reference to elements in the template, so I think its fair to say you've moved some of your template mixing from view to the controller. From the docs "This method calls toShow to get the list of to-do items to show. Using the flatMap method, we iterate over each to-do item and binding the item to the incoming html." In addition I think the result is something thats harder for people to grok. When reading loops and control flow constructs from a programming language in a template its immediately familiar. When binding data into a template, at the very least, the code you need to reference exists in two separate places but interacts very very intimately. Again, I'm not saying that the current practice of writing code into the template should be the final solution. You could make the case that Haskell is better at parsing and handling text for whatever purpose (databinding or otherwise) than almost any other language and that, as a result, it would be better equipped to handle controller side manipulation of xhtml. In addition this might allow you to better leverage the type system. Personally I think if your going to be mucking around with html/xhtml a bit of haskell won't make it much worse :D All, To contribute something positive here, I would really like to see HAML become the goto template system of choice for haskell web dev if only because the syntax meshes well (indentation, terseness) and there's an enormous sea of web developers already familiar with its use and best practice. One less thing to worry about when learning webdev in haskell. Best John Disclaimer: I am an experienced web developer but I'm relatively new to Haskell. If there is some aspect of the language, unknown to me, that makes the Lift templating/databinding system much more effective feel free to ignore. On Sat, Apr 3, 2010 at 11:36 AM, Simon Hengel <simon.hengel@wiktory.org>wrote:
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 absolutely agree with that.
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.
Have you read about the "View First" approach of Lift[1]? While I do not like the monolithic approach of Lift, I really like that specific aspect. I'd not narrow my view on "Rails-Style MVC" right now.
Cheers, Simon
[1] http://wiki.liftweb.net/index.php?title=Lift_View_First _______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel
On 2010-04-03 23:28, John Bender wrote:
Simon,
While I don't have any hands on experience with Lift's approach to templating it looks a lot like asp.net databinding/templates and from my experience with that toolset it ends up being a cumbersome solution to the problem of separating controller and view. I don't necessarily think mixing code into your views is the "one true way" either, but what you sacrifice in controller code clarity seems to outweigh any gains from separating the two so strictly.
As an example from http://liftweb.net/docs/getting_started/mod_master.html#x1-130002.7 :
<lift:TD.list all_id="all_todos"> <div id="all_todos"> <div>Exclude done<todo:exclude/></div> <ul> <todo:list> <li> <todo:check><input type="checkbox"/></todo:check> <todo:priority> <select><option>1</option></select> </todo:priority> <todo:desc>To Do</todo:desc> </li> </todo:list> </ul> </div> </lift:TD.list>
private def doList(reDraw: () => JsCmd)(html: NodeSeq): NodeSeq = toShow. flatMap(td => bind("todo", html, "check" -> ajaxCheckbox(td.done, v => {td.done(v).save; reDraw()}), "priority" -> ajaxSelect(ToDo.priorityList, Full(td.priority.toString), v => {td.priority(v.toInt).save; reDraw()}), "desc" -> desc(td, reDraw) ))
In the above you'll notice that the bind has direct reference to elements in the template, so I think its fair to say you've moved some of your template mixing from view to the controller. From the docs
Disclaimer: I've only done a very simple (and incomplete) application in Liftweb. YMMV. Anyway, regardless of what you do there has to be _some_ connection between the view and the controller (backend) and in my experience, the "View first" approach of Liftweb does a very good job here. A major advantage is that the view is 100% pure XHTML/HTML so that it can be edited in any XML editor. It also contains placeholder data so that most of the layout/design can be done independently of having the actual application running. (That's the theory, anyway. I haven't done this on any sort of large scale, so again YMMV.) The only approach I can think of which would do away with having a binding mechanism would be to generate all the front end HTML/XHTML/JS completely from Haskell. This is great for developers, but not so good for the "web designer" crowd. Cheers,
I've worked with the Yii[1] framework for php. This "view first" approach seems to me like the Widgets[2] of the Yii. The widget keeps the logic of the view. The Yii uses a Rails like MVC with a better template using this widgets. []s Victor [1] http://www.yiiframework.com/ [2] http://www.yiiframework.com/doc/guide/basics.view On Sat, Apr 3, 2010 at 3:36 PM, Simon Hengel <simon.hengel@wiktory.org> wrote:
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 absolutely agree with that.
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.
Have you read about the "View First" approach of Lift[1]? While I do not like the monolithic approach of Lift, I really like that specific aspect. I'd not narrow my view on "Rails-Style MVC" right now.
Cheers, Simon
[1] http://wiki.liftweb.net/index.php?title=Lift_View_First _______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel
-- GNU/Linux user #446397 - http://counter.li.org
Simon, I posted the following to the mailing list yesterday but it has been awaiting moderation since then and I would like to contribute something to the conversation https://gist.github.com/118dc4cd9d8223c33f63 <https://gist.github.com/118dc4cd9d8223c33f63>I hope reading it at that link isn't too troublesome. Best John On Sat, Apr 3, 2010 at 11:36 AM, Simon Hengel <simon.hengel@wiktory.org>wrote:
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 absolutely agree with that.
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.
Have you read about the "View First" approach of Lift[1]? While I do not like the monolithic approach of Lift, I really like that specific aspect. I'd not narrow my view on "Rails-Style MVC" right now.
Cheers, Simon
[1] http://wiki.liftweb.net/index.php?title=Lift_View_First _______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel
participants (11)
-
Bardur Arantsson -
Chris Eidhof -
Clint Moore -
Gour -
Jeremy Shaw -
Johan Tibell -
John Bender -
Marc Weber -
Michael Snoyman -
Simon Hengel -
Victor Mateus Oliveira