I'm interested on starting a project with others to create a powerful Haskell web framework in the same league as Rails or Django. I've enumerated (perhaps ad nauseum) my ideas for it in this blog post: http://blog.snoyman.com/2009/01/25/haskell-web-framework/. If people are interested in this, please respond to me either directly or on this mailing list. Just as a quick summary of the post, I would say the most salient points are that the framework should work in a shared hosting environment and should automatically abstract away most of the issues of writing an Ajax web application. It should also leverage the strengths of Haskell, eg type safety and speed. I welcome all comments and critiques as well. Michael
Hello Michael,
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?
--
Donnie Jones
2009/1/25 Michael Snoyman
I'm interested on starting a project with others to create a powerful Haskell web framework in the same league as Rails or Django. I've enumerated (perhaps ad nauseum) my ideas for it in this blog post: http://blog.snoyman.com/2009/01/25/haskell-web-framework/. If people are interested in this, please respond to me either directly or on this mailing list.
Just as a quick summary of the post, I would say the most salient points are that the framework should work in a shared hosting environment and should automatically abstract away most of the issues of writing an Ajax web application. It should also leverage the strengths of Haskell, eg type safety and speed.
I welcome all comments and critiques as well.
Michael
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
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
Hi Michael Snoyman, Donnie Jone, I don't think cross posting to web-devel and haskel-cafe is a good idea. Maybe do that but then advice people to either reply to cafe or to web-devel. So I suggest that we continue this discussion on web-devel. First of all there have been some attempts already to provide web frameworks for haskell. If you don't konw WASH yet please do have a look at the examples. I find the idea behind WASH pretty neat. It does also solve parts of the strict XHTML problem. you can only add valid tags and attributes. However it doesn't pay attention to order. (I don't think it was possible that time WASH was written). I've tried to make it better and verify that only valid XHTML is generated. The result is a finate state machine implented using functional dependencies. You can get the code from here git://mawercer.de/vxml.. However while doing so I noticed that this starts turning into a typing hell.. Why? There are some tags which require one or more childs (example : <ul>). So to distinguish both states (empty ul, ul with at least one element which may be closed) you need two different types. Thus you can no longer do myUl = ul $ map (li . show) [1...] My solution was to switch to a weak checking which only allows valid sub tags but does no longer care about order etc. So by now I'd vote for a partial validation only. a total validation isn't worth the effort. But it would be nice to to derive that from some specification (such as XHTML). So maybe have a look at my library and use the weak validation mode. About Ajax: I've developped some Ajax applications beeing written in PHP using MySQL.. In WASH everything is simple: You have one state (it doesn't know about AJAX). From that state you can go on, duplicate it etc. The state is passed to the client using an hidden input. So there is not that much you have to care about. But you can't write that much interaction easily either. When starting to write a web application (say a web shop).. it would be best if the client page keeps a state knowing about the basket and its content as well. And if you start implenting fancy features such as drag and drop I'm no longer sure which is the best way to handle this "client" state. I even don't know wether it can be abstracted on server side (using any language).. I'll watch you, keep posting to this list about your progress. Comments about the blog post (http://blog.snoyman.com/2009/01/25/haskell-web-framework/) Maybe the first step is writing down differences between existing haskell web frameworks. Probably the haskell wiki would be a good place to start. Another first step might be writing kind of abstraction so that an application can use either HAppS or apache or (fast)-CGI etc.. Encrypted cookies :-) Nice idea.. However this does mean a lot more traffic, doesn't it? It also depends on your storage enginge. If you have once keeping stuff in memory this won't hurt that much. But you're right. I'll think about that option About 13.: We should be able to simply specify the algorithm necessary to calculate an age from a birthday, and the framework will convert this into both client- and server-side code There is already a haskell -> JS converter.. However this will cause a lot more traffic. And if you have many users only loading the front page .. How do you want to utilize the power of existing script frameworks (eg Mootools) ? Should the engine be aware about those? What about CSS abstraction ? I mean ie6 does read some CSS properties quite different.. What about JS automatic compression (maybe even rewriting names to shorter ones)? Sincerly Marc Weber
participants (3)
-
Donnie Jones -
Marc Weber -
Michael Snoyman