February 2011 - web-devel

[Yesod] widgets in default layout
by Dmitry Kurochkin 22 Feb '11

22 Feb '11

Hello. I am trying to make a menu widget for a site. It would render list of menu items and mark the active one. I started with a new Menu module that exports (mainMenu :: Widget ()) function. The function gets the current route, iterates over a list of (item title, item route) list and constructs the menu. Now I can import Menu in a handler module and use ^{mainMenu} in hamlet template. Next I tried to put the menu widget to default layout - menu should be on every page so default layout is where it belongs. Rest of the email describes problems I got. 1. Module import loop. I need to import the widget module in the module which defines defaultLayout, i.e. the main application module. But the widget module uses the main application module to have routes and probably other staff, hence import loop. I tried to separate foundation and route declaration from Yesod instance declaration, so that the widget module could import just routes declaration and Yesod instance could import the widget module. Turns out that does not work: Attempting to interpret your app... Compile failed: Menu.hs:20:23: Couldn't match expected type `Route m' against inferred type `TestAppRoute' NB: `Route' is a type function, and may not be injective In the first argument of `\ u[a7Kv] -> hamlet-0.7.0.2:Text.Hamlet.Quasi.urlToHamletMonad u[a7Kv] []', namely `AboutR' In a stmt of a 'do' expression: \ u[a7Kv] -> hamlet-0.7.0.2:Text.Hamlet.Quasi.urlToHamletMonad u[a7Kv] [] AboutR In the first argument of `hamlet-0.7.0.2:Text.Hamlet.Quasi.toHamletValue', namely `do { (hamlet-0.7.0.2:Text.Hamlet.Quasi.htmlToHamletMonad . preEscapedString) "<div id=\"menu\"><div class=\"left\"><div class=\"right\"></div><div class=\"container\"><a href=\""; \ u[a7Kv] -> hamlet-0.7.0.2:Text.Hamlet.Quasi.urlToHamletMonad u[a7Kv] [] AboutR; (hamlet-0.7.0.2:Text.Hamlet.Quasi.htmlToHamletMonad . preEscapedString) "\">itemTitle item</a></div></div></div>" }' I do not understand details, but it is clear that the widget needs the Yesod instance. So I have to put the widget in the main application module. This does not look good considering that application may have many widgets. I have also stumbled upon a bug in devel server: It tries to recompile the source in a loop, without changing source of course. Annoying but not a critical issue. 2. Widget does not work in default layout. I guess this is a known and expected behavior. My feeling is that hamletToRepHtml can not embed widgets because it may be too late to add cassius and julius. As a workaround I split default layout into outer and inner layout. Outer layout renders just HTML <head> and <body>. While outer layout is rendered as a widget that embeds the actual page contents. Since outer layout is rendered as a widget, it may embed other widgets like menu. I imagine that hamletToRepHtml could render all embedded widgets before the main body. Though, it may be difficult to implement, have performance or other issues. Anyway, I think it is not uncommon to include a widget in default layout. So Yesod should provide an easy way to do it. The last issue is that (mainMenu :: Widget ()) does not work, I had to change it to (GWidget sub TestApp ()). Again I do not know details, but this was unexpected to me. Perhaps the Widget type synonim should be changed? I would appreciate advices on how to solve the above problems. Perhaps I am just missing something and there is a proper way to do what I want. For now I will avoid using widgets in default layout and move part of layout to individual handler templates, primarily because I find it too ugly to define widgets in the main application module. Regards, Dmitry

2 10

Sql join feature in persistent
by James 22 Feb '11

22 Feb '11

Hi all, I'm new to this mailing list. I did web development in python with Django framework before. But I really like the haskell language, so considering building my next site (a LBS-SN like service) in haskell. I learn snap for a while and think it's not so mature and powerful. After I learned the yesod docs in one day and read some yesod and haskellers.com codes in the following few days, I appreciate it and try to use it seriously. Now I need a database query across two table, so as to sql join feature. Currently, persistent doesn't provide this functionality. I think maybe adding a function to PersistBackend class, and implementing it in PersistBackend (SqlPersist m) may solve the problem. However, I am not sured. Will it be difficult and consistent to implement this feature? Thanks for any help. Sincerely, -- James Deng department of computer science, school of information science & technology, Sun-yat-sen University, Guangzhou, China mailTo: cnJamesDeng(a)gmail.com homepage: http://cnjdeng.appspot.com

4 4

[Yesod][Sitemap][bug] wrong translation from yesod 0.6.7 to 0.7.*
by Katsutoshi Itoh 21 Feb '11

21 Feb '11

hi, just now, i found a bug in yesod-sitemap-0.0.0(and HEAD), when i try translate my application to 0.7.1. -------------------------- diff --git a/Yesod/Helpers/Sitemap.hs b/Yesod/Helpers/Sitemap.hs index 05debf5..60562bc 100644 --- a/Yesod/Helpers/Sitemap.hs +++ b/Yesod/Helpers/Sitemap.hs @@ -61,7 +61,6 @@ template urls = #else [$xhamlet| #endif -<div id="endif"> <urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"> $forall url <- urls <url> ----------------------------- regards.

3 2

[Yesod] teach me how to convert 0.6.7 to 0.7.1
by Katsutoshi Itoh 21 Feb '11

21 Feb '11

Hi, i'm trying to convert my apps from yesod-0.6.7 to yesod-0.7.1. If you do the following: How would I change? on yesod-0.6.7. RootR = do : : runDB $ do xs <- selectList [UserNameEq x] [] 0 0 lift $ defaultLayout $ do setTitle $ string $ "homepage" addHamlet $(hamletFile "homepage") on yesod-0.7.1, an error occurred like as: Couldn't match expected type `YesodDB MyApp (GGHandler MyApp MyApp IO) RepHtml against inferred type `t (GGHandler sub master (Data.Enumerator.Iteratee Data.ByteString.Internal.ByteString IO)) RepHtml' NB: `YesodDB' is a type function, and may nnot be injective In the expression: lift $ defaultLayout $ do { setTitle $ ...... I guess convert `lift' to somewhat... would you teach me how to convert this?

2 1

[Yesod] Bookmarklet web app development.
by William Pearson 21 Feb '11

21 Feb '11

Hi, I'm trying to figure out the best way to do a webapp based around a bookmarklet. This means I am slightly out on the left field. The bookmarklet requests a javascript file which should be customized on a per user basis (based on session). I've been fiddling about with Yesod and have come across Julius and renderJulius, which I hoped would be able to do what I wanted, but I am coming to the conclusion that it is harder than I thought. My current thinking is that I might be able to do something using getCurrentRoute and judicious monadic magic, but I suspect I am tying myself up in knots. I'd like to keep type safe urls if possible. Thanks for any help, Will

3 4

[Yesod] database tables migration problem.
by Katsutoshi Itoh 20 Feb '11

20 Feb '11

Hi I am developping web service *incrementally* by using devel-server. This is very good feel. but, a bit problem occurred, when the program install and setup new mathine. This service's Model.hs has 2 tables these are cross-reference like as below. User : avatar FileHeaderId Update : FileHeader : creator UserId : i settled like ... 1. migrate tables which has no column without id. 2. alter add columns. i think yesod should separate the migration to 2 steps. 1 is to create tables these has no columns without id. 2 is to add colums and so on. How about this?

2 1

[Yesod] sendFile depends on approot?
by Katsutoshi Itoh 20 Feb '11

20 Feb '11

Hi when i set approot = "http://foo.bar.buz/quz", then favicon.ico could not get at web brawser. is this a bug? i use yesod 0.6.7.

2 1

[Yesod] Where is Yesod.Helpers.Crud on Yesod 0.7.1
by Katsutoshi Itoh 20 Feb '11

20 Feb '11

I'm trying 0.7.1. Which library has Yesod.Helpers.Crud?

2 1

How exactly do you add cassius files to a hamlet template?
by Ian Duncan 18 Feb '11

18 Feb '11

I assumed that I could change: defaultLayout widget = do mmsg <- getMessage pc <- widgetToPageContent $ do widget addCassius $(Settings.cassiusFile "default-layout") hamletToRepHtml $(Settings.hamletFile "default-layout") To: defaultLayout widget = do mmsg <- getMessage pc <- widgetToPageContent $ do widget addCassius $(Settings.cassiusFile "other-stuff") addCassius $(Settings.cassiusFile "default-layout") hamletToRepHtml $(Settings.hamletFile "default-layout") And that it would minify other-stuff.cassius and include it, but this is clearly wrong. I also tried this: defaultLayout widget = do mmsg <- getMessage pc <- widgetToPageContent $ do widget addCassius $(Settings.cassiusFile "other-stuff") hamletToRepHtml $(Settings.hamletFile "default-layout") Replacing default-layout completely, and it didn't work either. What am I doing wrong here?-- Ian Duncan

2 2

Haskell Web Framework Happstack 6 Released
by Jeremy Shaw 17 Feb '11

17 Feb '11

Hello, I am pleased to announce the release of Happstack 6. We fully recommend that all Happstack users migrate to the new release. Happstack is a high-performance Haskell web framework. It has high- level functionality for routing requests, extracting parameters, manipulating responses, serving static file contents, compression responses, and more. It includes an integrated HTTP server and a native RAM-cloud database system known as MACID. This allows you to deploy your web application with out having to configure apache, php, mysql, memcached, etc! Install instructions can be found here: http://happstack.com/download If you are porting existing applications you should check out the Happstack 6 migration guide: http://code.google.com/p/happstack/wiki/Happstack6Migration Porting should be pretty straight-forward. Despite the massive reorganization, the exports from Happstack.Server are largely the same. What's Exciting! ---------------- The focus of this release has been happstack-server. The primary goal was to make happstack-server much easier to learn and to use. This includes: 1. improving the overall organization of the library 2. greatly improving the documentation 3. making it easier to install 4. ensuring that the server provides fast, reliable performance 5. making it easier for new (and old) developers to understand and get started If you have looked at Happstack before and found it too difficult to understand, I highly recommend you take another look. The new organization and documentation make it far easier to understand. More Logical Organiation ------------------------ In prior versions, the Happstack.Server.SimpleHTTP module contained just about everything, with little organization, and no real differentiation between the external API and the library internals. In Happstack 6, SimpleHTTP has been refactored into numerous, smaller modules. The internals have been moved into Happstack.Server.Internal.* so that they are not leaking into the external API. This should make it much easier to find what you are looking for, and prevent you from accidently running across internal things like the WebT monad, which you do not really need to know anything about. Better Documentation -------------------- The API documentation for happstack-server is also much better. All external API functions should now have good haddock documentation with many inline examples. However, learning a new library by studying the API documentation can still be pretty frustrating. So we also have the brand new Happstack Crash Course. http://happstack.com/docs/crashcourse/index.html. The Happstack Crash Course covers a vast majority of the happstack- server API. It covers the API in a logical manner and includes many downloadable, runnable examples. It is intended to be read start to finish, and to also be usable as a reference guide for specific "How do I do XXX" questions. Additionally, the guestbook example has been updated to a cleaner, more modern style of Happstack coding. It also has more comments/ haddock documentation. Better API ---------- During the process of documenting Happstack, many small improvements where made to the API. Once you try to document something stupid you realize how stupid it is and decided it would be good to fix it first ;) For example, the Cookie API now makes it more obvious how to create session cookies vs persistent cookies. And makes it obvious how to expire a cookie. The functions for looking up values in the query string and require body no longer require the use of the RqData monad. You can use the look* functions directly in the ServerPart monad. If you do choose to use RqData, it now has an Applicative instance which can accummulate and report lookup errors. (http://happstack.blogspot.com/2010/10/is-rqdata-monad-still-needed.html ) There are a bunch of other improvements to request data handling documented here, http://happstack.com/docs/crashcourse/RqData.html. Easier Install -------------- In order to make Happstack easier to install we have removed as many dependencies as possible. happstack-data no longer depends on happstack-util, which makes it easier to install happstack-data or happstack-state with out the rest of the framework. HSP and HStringTemplate support has been moved into *optional* happstack-hsp and happstack-hstringtemplate packages. New Features ------------ Happstack also has a number of new features including: - support for Heist templates (http://happstack.com/docs/crashcourse/Templates.html#helloheist ) - support for Hamlet templates - improved environment for extracting query string and form values (http://happstack.blogspot.com/2010/10/is-rqdata-monad-still-needed.html ) - support for recompilation and reloading of templates in a running server (http://happstack.blogspot.com/2010/10/recompile-your-haskell-based-template… ) - directory browsing when using serveDirectory And numerous other improvements including enhancements to IxSet, file locking, and much more. Bigger, Better Version Number ----------------------------- We have also upgraded our version numbers! We have decided to call this release Happstack 6.0 instead of Happstack 0.6. There are two reasons for this: 1. the amount of changes we are making really do represent a new major release 2. it will make it easier to comply with the Haskell package version policy. Now that Happstack 6 is out, we plan to make more frequent releases. The new version scheme will allow us to talk about the next major release (Happstack 7), but still put out changes to Happstack 6 which change the API (aka, Happstack 6.2, etc). GHC 7 - mostly -------------- Happstack mostly works with GHC 7. Due to some compiler bugs, HSP does not work with GHC 7.0.1. These bugs were reported and are fixed in the upcoming GHC 7.0.2 release. If you are not using the optional happstack-hsp package, then GHC 7 is fine. If you are using happstack- hsp, then you will need to use GHC 6.12, a recent version of GHC from darcs, or wait until GHC 7.0.2 comes out. The Future ========== The current future plan looks like this: Happstack 7 ----------- The next major release of Happstack will be Happstack 7. The primary focus of Happstack 7 will be improving happstack-state (also known as MACID). Big features include: - sharding support - a rewrite of IxSet based on kdtrees with much better RAM and CPU performance - performance testing to show how awesome MACID is - much better documentation and examples - better tools for examining and modifying state in running applications There are also a bunch of lower-level API improvements planned which should make it nicer to use happstack-state. Happstack 8 ----------- Happstack 8 will finally feature an enumerator-based HTTP backend. This is a feature we have been hoping to add since January of 2009. http://code.google.com/p/happstack/issues/detail?id=29 Rather than develop a competing HTTP backend, Happstack will put its efforts into improving an existing HTTP backend. We currently have our eye on WAI/warp. However, we will also consider snap and hyena when the time comes. It should be noted that the current lazy I/O based backend is not the relentless nightmare of space leaks that some people might lead you to believe it is. The current happstack-server can easily handle uploads and downloads of large or streaming files with out leaks. But, enumerators *are* nice. How You can Help ================ You are encouraged to get involved in Happstack. The easiest way to get involved is to complain about how horrible Happstack is. If you don't voice your complaints, then we might not know something things to be fixed. If you are looking to make code contributions, please feel free to ask on #happs or the mailing list. There are tasks that are easy for novices, tasks that are worthy of a Ph.D, and everything in between. If you want to work, we can certainly find a way to use your talents! There are also plenty of non-coding related tasks including documentation, graphic design, user surveys, etc. You are also encouraged to blog about your Happstack projects! Thanks! - jeremy shaw

1 0