- web-devel - Haskell.org

[Yesod][hjsmin] Could not handle UTF-8 literal in julius file?
by いとうかつとし 28 Jan '11

28 Jan '11

Hi I write julius file like this. (snip) var fs = $('<fieldset><legend>Recent Changes</legend></fieldset>'), ul = $('<ul/>'); $('#recent-changes').append(fs.append(ul)); (snip) This works good. But,... (snip) var fs = $('<fieldset><legend>最近の更新</legend></fieldset>'), // Japanese UTF-8 ul = $('<ul/>'); $('#recent-changes').append(fs.append(ul)); (snip) This script(with UTF-8) transform legend text to unreadable string. Then, I try to insert "debugger;" statement in order to disable to hjsmin, This try is success and make readable. Could you confirm this?

2 3

ANNOUNCE: WAI 0.3.1, Warp 0.3.1, wai-app-static 0.0.0 and warp-static 0.0.0
by Michael Snoyman 27 Jan '11

27 Jan '11

Hi everyone, Firstly, after some feedback, I'm releasing some point updates for WAI and Warp. They fix some documentation issues, add some status aliases, make it possible to handle exceptions more easily, and make things more responsive on Windows. Next, I'm releasing two new packages: wai-app-static is a static file serving application for WAI. It handles all of your basic needs in this department: * Proper 301 requests to fix trailing-slash issues for folder vs directory. * Directory listing support (if turned on), including a default listing function that uses Haskell colors and a Haskell logo in the corner. Thanks to Happstack for the basis of this code. * Directory index support (eg, index.html, index.htm), again configurable. * Mime type lookups. Thanks to Snap for this table. warp-static is simply a standalone executable that runs wai-app-static on the Warp webserver. The executable name is warp. I know I personally have needed such a light-weight web server at work a few times, so if nothing else, putting it on Hackage is a convenience for me :-). I hope people find these useful. Don't expect the performance to beat nginx, but it is still quite good. if there are any other features requests on any of these packages, let me know. Michael

1 0

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

26 Jan '11

Thanks for the great extra info on JMacro. I think haskellers would enjoy hearing about it and how you use it as a blog post. 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. coffee-script isn't designed to give javascript a ruby-like syntax. It is designed to add useful language level features and get rid of superfluous syntax, which Ruby and haskell also try to do. Maintaining a certain amount of javascript compatibility makes it look more like Ruby and less like Haskell. But there are definitely influences from other languages. For example, it uses layout syntax instead of an 'end' keyword (or brackets) in ruby. You can use groovy's existential operator. >From looking at the jmacro README I am slightly confused as to what syntaxes are required, and which are optional, but it seems like the following features are in coffee script but not jMacro * no need for the var keyword, scope is intelligently taken care of. * no need for semi-colons * no need for parentheses around conditionals for ifg * list comprehensions (as in python), an extremely useful feature. * removal of brackets and commas for objects * argument splats * single line conditionals * ranges * class/super class conveniences * 'this.' aliased to '@' * multi-line strings * string and regular expression variable interpolation There are other things that might be missing/different, but I can't tell because they aren't documented, such as: * removal of triple-equal- double equal acts as triple equal (or is this in just the lambda syntax?) 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. This is also true of coffeescript, but to a lesser extent. Function syntax must be converted, and the var keyword removed. After that, plain javascript should works, and there are usually many improvements that can be made incrementally. While this provides some downside, it also provides upside- there is one unified function syntax that is as convenient as the haskell anonymous lamba syntax instead of 2 different function syntaxes with different rules. I really like what you have done with jMacro. My previous comments were really directed to thinking about it in a different context. I think we just need to clarify that these are different tools for different jobs. For the goal of writing javascript instead of generating it, coffee-script holds a lot of advantages over jMacro. For the goal of generating javascript from haskell (which you are using it for), jMacro seems like the perfect tool, and I will definitely look into using it for that purpose in the Yesod framework or my Yesod applications. Greg Weber

2 1

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