I am interested in contributing to a Haskell web framework. :)
I have started an attempt to create my own Haskell web framework, but I got busy working on my Master's thesis research, so I had to stop working on it... I was a web developer at a start-up company for 1.5yrs with Ruby on Rails, and I really really like the MVC design; however, I prefer a stricter MVC implementation than Rails provides. More specifically, I don't think code should appear in the view at all. I believe that using html tags, the web framework can provide a function to "render" the view which would parse the html tags and insert the content (whatever it may be). Functions can be easily composed together to build more complex content in the views. For example,
<person id="name"></person> <person id="age"></person>
person_name = renderView "person" "name" "John Doe"
person_age = renderView "person" "age" "40"
I can show you my code which implements this parsing in a more structured manner, but I think this stricter MVC implementation leads to more maintenable projects and especially facilitates a graphic designer to work independent of the web developer since the graphic designer won't be confused by the code in the views.
What do you think?
Are you saying that you specify the view in an XML file and then render it using Haskell code? If that's what you mean, one question: why bother with the XML at all? I've experimented both with writing HTML which gets rendered by code, or writing code that creates the HTML, and I think the latter is more flexible (think of the Text.XHtml hierarchy here). I would like to differ from Text.XHtml in two significant ways: 1. It would be nice if we set it up to only allow valid attributes. For example, a div tag should not have a src attribute. 2. We should intend from the beginning to have more high-level widgets. For example, I have in my codebase a navbar widget, which takes a list of links (both ILink and ELink, if you read my blog post) and produces the HTML, setting a class "current" on the link to the current page. That last part is often times a burden to program but provides a very nice user interface. I hope that last example gives more insight into what I'm looking for with these higher-level views. I have more examples if people are interested, I just didn't want to cause an information overload right away... well, at least nor more of an information overload than a 14-points blog post will in general cause. Michael