March 2010 - web-devel

A separation of concerns
by Chris Eidhof 05 Apr '10

05 Apr '10

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

11 20

Type-safe URL handling
by Chris Eidhof 03 Apr '10

03 Apr '10

Hey everyone, I just wrote down some of my ideas about type-safe URL handling on github, it's at http://gist.github.com/333769 I think it's similar to what Jeremy is doing with his urlt package [1]. -chris [1]: http://src.seereason.com/~jeremy/SimpleSite1.html

5 68

Using a 'real' parser for URL parsing
by Chris Eidhof 27 Mar '10

27 Mar '10

Hey, I've added a darcs patch (I hope it worked, I'm a darcs newbie) to switch the URL parser to parsec. This simplifies the code a lot. I've used String's (i.e. the URL path components) as tokens for the parser. What do you guys think? I'm sorry I haven't been replying to the type-safe URL handling, I was busy with writing this week. The discussion has become quite large! I'll see if I can catch up somewhere this weekend. -chris

2 4

ANN: Salvia-1.0.0
by Sebastiaan Visser 24 Mar '10

24 Mar '10

Hi all, Straight from Zurihac: I'm very pleased to announce the 1.0.0 release of the Salvia web server. Salvia is a feature rich web server and web application framework that can be used to write dynamic websites in Haskell. From the lower level protocol code up to the high level application code, everything is written as a Salvia handler. This approach makes the framework extremely modular and extensible. This release include the following stack of packages: * salvia-protocol: Protocol stack containing URI, HTTP, Cookie and Mime. * salvia: Basic server interface and implementation. * salvia-extras: Additional server handlers and back end implementation. * salvia-sessions: Session and user management support. * salvia-websocket: Cutting edge HTML5 web socket support. * salvia-demo: Demo servers showing how to use Salvia. All the code is on Hackage[1] and the source repositories can be found on GitHub[2]. Most of the basic ideas of the previous Salvia release are still in these package, but all the code has been cleaned up considerably. There is now a very strong separation between interface and implementation making it more easy to plug-in new back-ends for your web application. To do a full install first run `cabal update' followed by `cabal install salvia-demo'. Now you can run the salvia-demo command and point your browser to http://localhost:8080/ . Thanks to the people that helped me with coding, suggestions and bug-reports. Any comments/suggestions are welcome! Have fun, -- Sebatiaan Visser [1] http://hackage.haskell.org/package/salvia (-protocol, -demo, etc) [2] http://github.com/sebastiaanvisser/salvia (-protocol, -demo, etc)

9 17

ANN: regular-web 0.1 | generic web programming in Haskell
by Chris Eidhof 21 Mar '10

21 Mar '10

From the ZuriHac hackathon, I am happy to announce the first release of the regular-web package [1]. The package contains functions for generic web programming: generating HTML, JSON and Formlets. It is based on the regular generic programming library [2]. Generic HTML and forms are often not sufficient for real purposes, so we encourage the use of regular-web in combination with the fclabels package [3]. There is an example in the documentation of the Formlets module. Furthermore, there is a slightly larger example [4] on github that shows off some more features of the package. This is a preliminary release and the API will probably change. I am interested to see what other people think of this. So please send me your comments or fork the project on github. [1]: http://hackage.haskell.org/package/regular-web [2]: http://hackage.haskell.org/package/regular [3]: http://hackage.haskell.org/package/fclabels [4]: http://github.com/chriseidhof/regular-web/blob/master/Example.lhs

1 0

Re: [web-devel] Type-safe URL handling
by Curt Sampson 16 Mar '10

16 Mar '10

On Tue, Mar 16, 2010 at 9:51 AM, Gregory Collins <greg(a)gregorycollins.net>wrote: > This rabbit hole goes pretty deep though; if you're serious about the > bondage and discipline approach you'd want to ensure that you can > check query parameters; i.e. "'/foo' takes a mandatory 'bar' integer > parameter on the queryString and an optional 'sort' parameter which > must be either 'asc' or 'desc'", etc. Which is not at all unreasonable, actually, if you take the approach I sorta-kinda-did with my Ruby system at one point (using regexps to match URIs): if the URL doesn't match the types you need for it, you get a 404. Thus, simplifying immensely for the sake of an example, "/user/show/1312" shows information about user 1312, but "/user/show/13x7" returns a 404. You still have to deal with the problem somewhere else of making sure everything within your system generates valid URLs, though.... cjs -- Curt Sampson <cjs(a)cynic.net +81 90 7737 2974 http://www.starling-software.com The power of accurate observation is commonly called cynicism by those who have not got it. --George Bernard Shaw

1 0

Web projects wiki page
by Michael Snoyman 16 Mar '10

16 Mar '10

Just wanted to give a heads up that a created the wiki page: http://haskell.org/haskellwiki/Web_Projects I put in the ideas that I've already mentioned; please go ahead and augment that list with any other ideas. Also, if someone has a good idea on how to organize the list, go ahead; I'll merge my list into any organizational system someone adds. Michael

3 3

On the state of Haskell web frameworks
by Gregory Collins 16 Mar '10

16 Mar '10

Hi all, Just subscribed, and after reading through the recent traffic on this list in the archives I have a couple of quick comments. First, and I've discussed this with Michael Snoyman at length in private, I agree 100% with Chris Eidhof when he writes "I don't believe that there could be one big framework for everybody." Even getting consensus on what the prerequisites would be is basically impossible. To quote Gour: > Although it might be great framework, I'll be frank to say that > Happstack with all technology that goes along is something which is > either too complicated for me, not practical to be run on shared > hosting (e.g. Webfaction), not documented properly and it belongs to > 'noSQL' which is not for me at the moment. > > That's why I'm interested to discuss possibility to somehow > consolidate Haskell's web frameworks nad provide something which is > good for practical development, does not require VPS to be used, nice > documentation etc. A priori we've reached a fundamental disagreement about first principles -- personally I couldn't give a rat's ass whether the framework I'm using runs well on shared hosting, my focus is on being able to efficiently service heavy loads in a production context. Obviously, on the other side of the coin, being able to run in a CGI process hooked up to Apache is really important to many people. Michael wants to use YAML to define data models: more power to him, but personally the idea of doing that makes me want to vomit. I'm not saying that to disparage him at all, the idea isn't necessarily bad on its own merits: it just isn't for me. Everyone has their own pet preferences. I'm seeing a lot of energy being dedicated to standardizing interfaces, which I suppose is an admirable goal, but to me it's putting the cart before the horse: what's the point of having a standardized adapter when there's nothing worth plugging into it, besides some middleware that your framework should be providing for you anyways? Concentrating too much on interop right now is a waste of time IMO - besides, on the level that it's currently being discussed, that stuff is *easy*: making an adapter between any two of the myriad different web stack implementations (WAI, Happstack, Hyena, CGI, Hack, FastCGI, etc etc etc) is trivial. I doubt there's anyone on this list who couldn't cook up a WAI/CGI gateway in an afternoon. We need pluggable *applications* (blog, CMS, RSS feed generation, administrative panels, forum, wiki, caching, user management, etc) that understand how to talk to each other --- expecting "plug and play" compatibility between frameworks on this level, when there's no consensus on the *primitives*, is a pipe dream. The first framework that cracks this particular nut, in a way that makes it easy and pleasurable for people to build web apps that perform, is going to gain a lot of traction. Code talks. G -- Gregory Collins <greg(a)gregorycollins.net>

6 13

consolidating Haskell's web-framework scene
by Gour 15 Mar '10

15 Mar '10

Hello! I'm (still) Haskell noob learning the language with the help of RWH book and plan to write desktop GUI app (probably with qthaskell). However, there is also need to put together some web sites and I'd be very happy to use Haskell instead of tinkering with Python/Django. You know, once when you get even a small taste for Haskell it's hard to 'go back'. :-) Although it might be great framework, I'll be frank to say that Happstack with all technology that goes along is something which is either too complicated for me, not practical to be run on shared hosting (e.g. Webfaction), not documented properly and it belongs to 'noSQL' which is not for me at the moment. That's why I'm interested to discuss possibility to somehow consolidate Haskell's web frameworks nad provide something which is good for practical development, does not require VPS to be used, nice documentation etc. If we take a look in the Python's neigbourhood, we think something like Django although knowing well that it is quite big community, with lot of docs, books, apps etc., so it's maybe not the best example. However, Alson's yesterday post about leaving Haskell and (probably) leaving Turbinado abandoned (http://www.alsonkemp.com/haskell/reflections-on-leaving-haskell/) made me think to write this post. From his post it is obvious that he faced some walls during his devlopment which he could not overcome. I'm sad that the Turbinado was not more open so that someone can jump in and offer suggestions. Otoh, it was also not documented - docs were promised for quite some time, but nothing happened. Otherwise, the project had some nice objectives...so, let's learn the lessons. Some time ago, Michael posted about Yesod and I read about WAI initiative. He is very responsive and I've already exchanged several emails with him, but being noob for web-development in Haskell I want to learn more and help, according to my skills, that Haskell gets one decent & practical web-framework. The Haskell language itself was created to consolidate fragmented market of different FP languages. Are we ready to follow our 'ancestors' and in their spirit do the same when it comes to web-framework(s)? * Is it WAI & Yesod good start? What the others think? Any further reference you can provide for someone to learn more about web-programming in Haskell? (RWH is not very extensive here.) * I said frameworks because it seems that Happs is in its own category and if you read the comments in the above referenced URL, you'll see that often Happs is labeled as too complex. Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: F96FF5F6 ----------------------------------------------------------------

4 7

Re: consolidating Haskell's web-framework scene
by Michael Snoyman 14 Mar '10

14 Mar '10

I was planning on writing a blog post called "call to arms," which would have been something similar to what you said. I agree that there is far too much fragmentation in the community; I debated starting Yesod at all when there were already a number of frameworks out there (Happs, KIbro, Turbinado). However, none of them hit the spot that I was aiming for, so I created it. At the same time, Jinjing came out with Hack, and I tried to go with that. Unfortunately, there are some inherent flaws with Hack (you can review the Hack-discuss mailing list to see some discussions over there), so I started WAI. So it would seem that so far, I've done more fragmentation than consolidation :(. On the other hard, the other frameworks having had much development, Yesod is still active, and it looks like Happstack will be joining WAI, so not all is lost. I am very interested in trying to continue consolidation, but I think aiming for the One True Haskell Framework is a bad idea. Python- the community known for One Way To Do It- can't even consolidate around a single framework, so Haskell- the language of We Can All Write A Monad Transformers Library- doesn't stand a chance. So where can we consolidate? On libraries. I have purposely released a number of the components of Yesod as separate libraries that are available to any framework author (or even someone *not* using a framework). Here are some in particular to look at: wai wai-extra web-encodings clientsession authenticate data-object, data-object-json and data-object-yaml failure and control-monad-failure hack-handler-webkit Some of these packages have very obvious room for future development, and if someone (like Gour) is looking for somewhere to start contributing to the Haskell web community, I would recommend one of the following: authenticate currently supports OpenId 1 and RPXnow. I would like to have authenticate itself support *all* sites that RPXnow does. The first step in that process would be to get authenticate to use the openid package and determine whether a server support openid 1 or 2. From there, Twitter, Facebook, Windows Live support would all be nice. hack-handler-webkit is, IMO, a really cool idea. It allows you to convert any Hack application into a desktop app. It runs simpleserver and then opens up a Webkit window that connects to it. This is much better than simply running the simpleserver and then opening up a webbrowser, because: 1) The program terminates automatically when the web browser closes. 2) You can control menu bars, title bar, etc completely, making it *feel* like a desktop app. 3) You can ensure that all of the functionality you want is present in webkit. Unfortunately, hack-handler-webkit has two problems: 1) It's written for hack instead of WAI. However, this should take all of 5 minutes to fix. 2) It only works on Linux, and even there I don't have any documentation on setting it up. Yesod is still missing a model layer. This is a project that I will most likely be doing myself, since it will need to be designed to integrate very closely with Yesod, but I'll mention some of the design ideas here. (By the way, Chris Eidhof has a package on Github called Basil which looks very interesting here.) 1) I want to use YAML quasi-quoting to define the models. 2) I don't want a super-complex "object relational mapping"; Haskell is already much closer to the relational level than an OO language. 3) Utilize IO thunks (ie, lazy IO loading) so that we don't need to load everything into memory at the beginning. 4) Not tied down to SQL *or* in-memory databases. It should support both of those, but *also* support a system that is usable even in a CGI setup. I'm contemplating now a database that uses multiple directories/files and uses append-only to avoid concurrency issues. Compile-time checking of templates would be great. The Bravo package looks interesting, but I'm a little dubious about the approach used. I think something based on typeclasses might be a bit more nimble. Once again, tight integration with the model system I theoretically design would be nice. So, in summary of a much-too-long e-mail, let's not bother trying to get everyone to agree on One Framework. Happs has its place, Yesod has its place, and I know others are using Loli and probably Kibro. (I'm not sure if anyone every got started with Turbinado.) However, we can raise the bar for *all* packages simultaneously by making a more solid ecosystem of Haskell web packages available that any framework can cherry-pick from. Michael

1 1