January 2011 - web-devel

Re: [web-devel] richer client experiences
by Gershom B 25 Jan '11

25 Jan '11

Greg Weber writes: > AFAICT this language is less featureful than coffee-script, its only > advantage being the syntax is slightly more haskellish. > Of course, it does provides a technique for inserting haskell values into > javascript, and having javascript in haskell code. I think it would be > better to add these features to the more widely used coffee script using > that part of JMacro and/or Yesod's similar template tools. Hi! Author of JMacro here. You're right that JMacro has a few less features than CoffeeScript. In particular, it lacks pattern matching. Outside of that, however, most CoffeeScript features are to make CoffeeScript more rubylike in syntax. Haskell-style anonymous lambdas coupled with whitespace function application on their own, however, suffice to allow exceedingly Haskell/ML-like code. JMacro can be used as a nicer syntax for JavaScript, but the big win is that it is a better way to *generate* JavaScript -- in particular via hygiene and a shared namespace with surrounding Haskell code. So bear in mind also that JMacro syntax is infinitely-extensible in the sense that you can not only write JavaScript combinators in JMacro, but Haskell combinators which produce JMacro that can be spliced directly back into a block of code. Jeff and I have, for instance, written a tiny set of infix combinators for chaining jQuery selectors. Another feature of JMacro as opposed to CoffeeScript is that almost all valid JavaScript code is *also* valid JMacro. So you can take a code-sample or snippet from the web and place it directly into your application, refactoring it into a more functional style incrementally and at whatever pace you want. CoffeeScript allows for "escaping" into raw javascript, but that's in my opinion a much weaker alternative. JMacro as it now stands is more than sufficient for the paces that Jeff and I put it through -- and we use it all the time for the systems that we build. That said, if there was interest from others who wanted to use it, there are plenty of features that could be further developed. For one, the output could be made more efficient, and hooked into hjsmin as well. Syntax-wise, destructuring bind could be added as well as infix composition and a pleasant sugar for partial application. So if there are more JMacro users, and they want more features, I'll be as responsive as possible within my time constraints. The parser is also pretty straightforward to hack on if you want to add anything yourself. One reason that we haven't needed more out of JMacro is that we're only really using JavaScript for the raw UI, and have managed to push the complicated bits all into Haskell, which we communicate with via lightweight ajax/json RPCs, with autogenerated stubs (a 'la haxr). There's proof-of-concept code that demonstrates how to do this (with a dependency on jQuery) in the package [1]. Attempting to cut dependencies down, this code is written to be generic over backends rather than tied to any particular server/framework. So it'll take a tiny bit of glue to get working on your stack of choice. The really nice new stuff I've been doing isn't in the repo at all yet -- I've been meaning to find time to abstract it out in the right way so that it isn't too specific to one given setup. The RPCs I described above are all served from a given directory. However, there's now a concept of *conversations* which hold state local to a single load of a webpage from a given client. Their RPCs are tied to the webpage itself. This per-page state lets you write rich, stateful, web applications which hold all the important bits in the Haskell server and allow the browser-side client to act as a thin layer for display. If anyone is interested in using JMacro, or, better yet, hacking on it a bit, please let me know. Some users and/or collaborators would be a big incentive for me to do more work on adding features and building up the conversation/session machinery that I've been working with, etc. Cheers, Gershom [1] http://patch-tag.com/r/gershomb/jmacro/snapshot/current/content/pretty/Lang…

1 0

Re: [web-devel] richer client experiences
by Greg Weber 25 Jan '11

25 Jan '11

> > I get this definite feeling that people are assuming that I'm somehow "afraid" of the client side Please don't take anything personally! I was just suggesting an alternative models that I think are achievable right now, even if yours may be more ideal when completed. > - Testing is horrendous. I definitely agree, but now I *am* going to state (as someone who works in typeless languages that if that is your opinion (and it is mine of javascript) that there is a fear of the client side, or at least a recognition that programming it will be less productive because of the effort to test. This point goes in tandem with the lack of static typing- you can make up for some of the lack of static typing with more testing. I am looking into better ways to test javascript, looking into this at the moment: http://javascriptmvc.com/docs/FuncUnit.html. I hope you build the framework you are setting out to do and that I can use it to build cool sites. Cheers, Greg Weber

2 1

richer client experiences
by Greg Weber 25 Jan '11

25 Jan '11

To Bardur Arantsson and those with the vision of a richer client-side experience- I very much share that. The Yesod Widget model may be basic, but provides you with the concept of bundling the client-side aspects of html, css, and javascript together. Currently the server-side integration is for form elements that can be integrated with Persistent. We are certainly open to adding more advanced functionality. The advantage of this widget system is that it is at a level of abstraction that is still very approachable for web developers, and works well for its current use case (nicer form inputs). To me, the disadvantage of (extending) the current way of doing things is that it relies on javascript widgets (specifically jQuery-UI, although it is pluggable to use different frameworks) which hide everything away from you, so if there isn't a configuration option for what you want things get frustrating. I think the best solution may not be focusing on creating even greater abstractions on the server side, but instead to use the right ones on the client side. Cappacino had a vision of rich clients, and went to the effort of turning javascript into a (apple-based) desktop programming environment, but they simply adopted the REST model for communicating back to the server [1]. One could easily use Yesod, Rails, or any framework configured to be based on REST. What cappacion has accomplished is very neat, but as someone with experience in web devlopment and little in desktop development I don't need to learn how to program an apple desktop and deal with the leaky abstractions. There are a plethora of client-side tools (SproutCore, ExtJS, qooxdoo, much more) that can give you a richer client-side experience without tying one down to a specific server-side implementation while still feeling like web development. However, they are still generally very widget-based and heavy-weight, which is why I have been trying out backbone.js lately [2]. Backbone provides an MVc framework on the client side- the basic plumbing for creating a rich client, giving you control of your data in the way you are used to on the server side. You can choose to use javascript framework plugin or to program custom views. This direct client-heavy model works well because you can program it more directly instead of working through layers of abstraciton on the server side to generate a richer client. I would say the main down-side is duplicated logic and templates between the server and the client. I would like to start evolving techniques to be able to share server and client-side logic and templates, but in the mean-time I can be productive today without having to create new frameworks. I don't think the final solution requires throwing away all existing server-side web frameworks. One of the problems with client-heavy is programming in javascript, but much of this can be solved by using coffeescript [3]. Certainly there is still a problem with lack of type safety and difficulty of testing, but not one that can't be overcome and helped by integration with tools provided by the server-side framework. [1] cappuccino.org/ [2] documentcloud.github.com/backbone/ [3] jashkenas.github.com/coffee-script/

4 7

Changes to WAI and Warp
by Michael Snoyman 25 Jan '11

25 Jan '11

Hi all, There have been a number of feature requests for WAI and Warp. For all those interested, please check out the respective Github repositories[1][2]. A quick rundown of the changes: WAI * Some documentation updates. * Providing statusOK, statusNotFound etc aliases. Warp * Some documentation updates. * Exporting Port and InvalidRequest. * A new function, runOnException, to allow users to specify an exception handler. * serveConnections is exposed, allowing users to supply their own sockets for listening. This can allow you use use Unix named sockets with reverse HTTP proxying on nginx (possibly other frontend servers too). * runInteractive, which allows ctrl-C to work in Windows. Thanks especially to Neil Mitchell for most of these recommendations, as well as Liam O'Connor for the Unix named sockets idea, and Bas van Dijk for the exception handler idea. For the record: all of these are non-breaking changes, so both packages will be released at version 0.3.1 when these changes are finalized. Michael [1] https://github.com/snoyberg/wai [2] https://github.com/snoyberg/warp

1 0

Yesod. Handle Exception.
by Антон Чешков 25 Jan '11

25 Jan '11

Hello Michael. Please explain how to handle exceptions in Yesod applications. For example i would to catch the error generated by unique constraint on table. *runDB $ insert $ Table field1 field2 * Thanks. -- Best regards, Cheshkov Anton

2 2

More power, more configurable subsites
by Michael Snoyman 25 Jan '11

25 Jan '11

Hi Matt (and the whole web-devel list), Now that Warp is out, and now that the Hamlet decisions have been made, I can (finally) start focusing on yesod-core. Most of the changes we want are already made I think, there are only two open issues that I'm aware of: * Proper request body parsing[1], which is *almost* done. * Disabling sessions for subsites[2] On the second point, I want to broaden our scope: I want to make it possible to run a full WAI application as a subsite. I'll give my current use case: I just wrote a fully-featured wai-app-static application, which takes care of redirecting from "/foo/directory" to "/foo/directory/" and other such things. Now, let's say I have a directory named "my.folder" or a file named "file". In Yesod, the URL cleaning will remove the trailing slash from the former, and add the trailing slash to the latter. However, wai-app-static will do the exact opposite, resulting in an infinite redirect loop. One possible solution to this predicament is to hard-code /static as a special prefix, and not do URL cleaning. But this is a horrible, ugly, evil hack that makes unicorns cry and babies vomit (trust me, I have two kids, you don't want to know what happened hear after I added that commit). What we *really* want is to give subsites much more control over their execution. As the Yesod dispatch functions are written right now, that's not really possible: we do all path cleanup first and then start routing. So here is a possible proposal for how Yesod dispatch should work: * Break up the pathinfo (/static/directory/) into pieces (["static", "directory", ""], the empty string at the end indicates a trailing slash). * Dispatch to subsites only. In other words, we'll keep a list of subsite prefixes separate from other routes, and check those against the unmodified pieces. * If there are any matches, we strip out the relevant prefix from the pieces and pass off control to the subsite. * Subsites created with normal Yesod functions (mkYesodSub) will then go right back into the dispatch function, but now the specific settings for that subsite will be in place. This means that they can control how cleanup is done, whether sessions are on, etc. * You can also write your own subsite code directly and bypass Yesod's dispatch system. This will also make it possible to write a appToSubSite function so that plain WAI applications can be included directly. (I'm hoping that with the release of Warp, there will be more non-Yesod WAI apps out there.) I haven't looked at implementing this yet, but it doesn't sound too hard. I wanted to ask what you thought about how this would interact with your more modular subsite code already. One other thing that comes up as related: Aristid Breitkreuz emailed me and asked why Yesod is a typeclass and not a record type. I gave an answer[3], but I wouldn't mind other people looking into it as well. I'm starting to think about using the records approach on the YesodSubSite typeclass at least and see how that works out. But I have not given this much thought, and this is really an orthogonal- albeit related- question. Michael [1] http://wiki.yesodweb.com/Proper%20request%20body%20parsing [2] https://github.com/snoyberg/yesod/issues#issue/24 [3] http://wiki.yesodweb.com/Yesod%20as%20typeclass%20or%20record

2 4

Re: [web-devel] Yesod. Problem with compile
by Michael Snoyman 23 Jan '11

23 Jan '11

Did you turn on quasiquotes? 2011/1/23 Антон Чешков <acheshkov(a)gmail.com>: > Hello Michael. I have the little problem > i can not compile this: > registrationWidget :: String -> Widget () > registrationWidget s = do > addJulius [$julius|alert("This is Javascript");|] > I got: > Handler/Registration.hs:10:50: parse error on input `;' > I have the same problem when try to add hamlet via $addHamlet. > Do i forget import some stuff module ? > Thanks. > -- > Best regards, > Cheshkov Anton > Phone: +7 909 005 18 82 > Phone: +7 931 511 47 37 > Skype: cheshkov_anton >

1 0

Looking for criticism and comments on web-mongrel2.
by Clint Moore 21 Jan '11

21 Jan '11

After sufficient hand-wringing I finally uploaded web-mongrel2 up to hackage and I'm interested in criticism of my approach. The module itself is terribly simple as it's meant to provide a lightweight layer between an application or framework and Mongrel2, but if nothing else, it's a start. Anyway, the hackage page is at http://hackage.haskell.org/package/web-mongrel2-0.0.2.2 with a link to the github repo.

2 5

Re: [web-devel] [Haskell-cafe] Looking for criticism and comments on web-mongrel2.
by Clint Moore 21 Jan '11

21 Jan '11

On Fri, Jan 21, 2011 at 5:30 AM, Vo Minh Thu <noteed(a)gmail.com> wrote: > The link given on hackage to git is broken, it seems to be > web-mongrel2 instead of haskell-mongrel2. If you click on the latest version the link should be correct. And yes, it's web-mongrel2 - I caught that SECONDS after uploading it to hackage.

1 0

Re: [web-devel] [Haskell-cafe] Looking for criticism and comments on web-mongrel2.
by Michael Snoyman 21 Jan '11

21 Jan '11

On Fri, Jan 21, 2011 at 3:30 PM, Vo Minh Thu <noteed(a)gmail.com> wrote: > 2011/1/21 Clint Moore <cmoore(a)wamboli.com>: >> After sufficient hand-wringing I finally uploaded web-mongrel2 up to >> hackage and I'm interested in criticism of my approach. The module >> itself is terribly simple as it's meant to provide a lightweight layer >> between an application or framework and Mongrel2, but if nothing else, >> it's a start. >> >> Anyway, the hackage page is at >> http://hackage.haskell.org/package/web-mongrel2-0.0.2.2 with a link to >> the github repo. > > Hi, > > The link given on hackage to git is broken, it seems to be > web-mongrel2 instead of haskell-mongrel2. It worked fine for me...

1 0