> > 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
_______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
