- web-devel - Haskell.org

ANNOUNCE: TCache 0.8
by Alberto G. Corona 14 Apr '11

14 Apr '11

Tired of your persistence layer? Take persistence the haskelll way. Besides the backward compatible stuff, TCache now defines persistent STM variables (DBRef's) that leverages the traditional haskell reference syntax to perform fast in-memory database transactions and inter-object references. It includes indexing, triggers and an straightforward pure-haskell query language based on record field relations. http://hackage.haskell.org/package/TCache-0.8.0.2 This version includes a lot of changes and must be considered beta. Please submit any bugs, comments and so on. Cheers!

2 1

[Persist] Select all objects
by Konstantin Litvinenko 13 Apr '11

13 Apr '11

Hi All! I'am trying to use Persist to select all entities from table but can't figure out syntax to use. Now I was able to select using fake Filter. How can I avoid fake filter and select all record?

2 3

questions about hamlet syntax, and yesod-examples-.0.7.0.1
by Michael Litchard 12 Apr '11

12 Apr '11

I'm using yesod 0.7.3, and I'm trying to change one of the yesod examples to match the structure created by the scaffolding utility. Here's the source of my confusion. This is what the sample hamlet file looks like generated from the scaffold utility !!! <html <head <title>#{pageTitle pc} ^{pageHead pc} <body $maybe msg <- mmsg <div #message>#{msg} ^{pageBody pc} But here's a sample of the syntax used by yesod-examples 0.7.0.1 > instance Yesod Ajax where > approot _ = "" > defaultLayout widget = do > Ajax pages _ <- getYesod > content <- widgetToPageContent widget > hamletToRepHtml [$hamlet| > \<!DOCTYPE html> > > <html> > <head> > <title>#{pageTitle content} > <link rel="stylesheet" href="@{StaticR style_css}"> > <script src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js"> > <script src="@{StaticR script_js}"> > \^{pageHead content} > <body> > <ul id="navbar"> > $forall page <- pages > <li> > <a href="@{PageR (pageSlug page)}">#{pageName page} > <div id="content"> > \^{pageBody content} > |] This doesn't look like the same syntax to me. Am I right? How would I decouple the hamlet, as the scaffolding utility does?

2 1

strange link behavior in yesod
by Chris Casinghino 10 Apr '11

10 Apr '11

Hi all, I'm running the Yesod 0.8 beta on GHC 7.0.3 and seeing some strange behavior. I'm a total Yesod newbie, so please forgive me if I'm missing something obvious. Below is a simplification of the Links example from the Yesod book. When I run the program with "runhaskell links.hs", the link on page1 points back to page1, instead of home. I'd be very grateful if someone could explain what I'm doing wrong. Thanks! --Chris Casinghino > {-# LANGUAGE TypeFamilies, QuasiQuotes, MultiParamTypeClasses, TemplateHaskell, OverloadedStrings #-} > module Links where > > import Yesod > > data Links = Links > > mkYesod "Links" [parseRoutes| > / HomeR GET > /page1 Page1R GET > |] > > instance Yesod Links where > approot _ = "" > > getHomeR = defaultLayout [hamlet|<a href="@{Page1R}">Go to page 1!|] > getPage1R = defaultLayout [hamlet|<a href="@{HomeR}">Go home!|] > > main :: IO () > main = warpDebug 3000 Links

2 1

Setting variables in hamlet forall
by vagif.verdi＠gmail.com 10 Apr '11

10 Apr '11

I noticed a pattern that in hamlet $forall i often retrieve the same value from a map, Sometimes 3,4 times. $forall row <- rs <td><a href=@{FormR (getInt "form_id" row)}>#{getStr "form_name" row} <td>#{getStr "docname" row} ... <td>#{fromMaybe "" (IntMap.lookup (getInt "form_id" row) counties)} <td>#{fromMaybe "" (IntMap.lookup (getInt "form_id" row) customers)} Would it be possible to allow let statement in forall for often used values ? Regards, Vagif Verdi

6 22

Re: [web-devel] Data and Typeable
by Clint Moore 09 Apr '11

09 Apr '11

On Thu, Apr 7, 2011 at 12:01 PM, Michael Snoyman <michael(a)snoyman.com>wrote: > > First, what's the 'right way' to get a string representation of a Key? >> I generate select form elements from subsets of data in a table. Usually, >> resulting in 'select name="name_column" value="id_column"' >> >> I would probably use the Show instance, unless you have a compelling > reason not to. > Show on the key gives me 'TableId 1' instead of simply 1. I'm assuming the expectation is not to split the table name off every time, though I don't see a function to get just the id of a row. ie tableId > x <- myConnect $ selectList [TableNameNe "honk"] [] 0 0 > fst $ head x TableId 1 > tableId $ snd x <- convenient! Second, for types that have relationships, is there a shortcut or something >> I'm not seeing that will allow me to derive Data and Typeable? >> example: >> >> Species >> name String Eq >> deriving Data Typeable >> >> Animal >> name String >> species SpeciesId >> deriving Data Typeable <-- error! There aren't instances generated, at >> least that it can find, of SpeciesId for Data.Data >> >> I wanted to enable this by default in Persistent, but it would require > user code to have DeriveDataTypeable enabled. I can consider putting it back > in, but I wouldn't mind web-devels input. > For my uses, the only place that this makes life much easier is when using HStringTemplate. If it were enabled, you could simply set a row as an argument directly with 'setAttribute' instead of having to massage the data beforehand. Other than that, I can't think of a compelling reason to enable it by default. As I write this, I thought perhaps you could add cabal flags to enable this if you knew that you needed it, but then you start having to litter your code with #ifdefs and that starts to make code look very ugly very quickly. Maybe someone has another compelling use case for enabling this by default?

2 3

style for html IDs in hamlet
by Max Cantor 09 Apr '11

09 Apr '11

In an effort to get more type-checked goodness in hamlet, I started using string constants for all my dom IDs and classes. We're not using the newIdent function because I want control over what the IDs and classes will be named. I wrote up a little typeclass as such: class CustomIdentString a where jqVal :: a -> String; idVal :: a -> String newtype CustomIdentCls = MkCls String instance CustomIdentString CustomIdentCls where jqVal (MkCls s) = "." ++ s; idVal (MkCls s) = s; newtype CustomIdentId = MkId String instance CustomIdentString CustomIdentId where jqVal (MkId s) = "#" ++ s; idVal (MkId s) = s; This way, I can refer to divs in javascript using: $("#{jqVal myId}").foo.. And create the elements in hamlet using <div ##{idVal myId}> ... I'm wondering is there a datatype for IDs and Classes that I can use to make the IDs and Classes directly so that: <div .#{foo myId}> and <div ##{foo myCls}> would fail to typecheck? In general, are there any good, safe ways to do this instead of just unwrapping to strings? max

3 3

Overhaul of wai-handler-devel
by Michael Snoyman 08 Apr '11

08 Apr '11

Hi all, I think it's no secret that wai-handler-devel is not living up to its full potential. Here's a few of the issues that I know about: * Doesn't integrate well with cabal-dev. (Fair warning: I haven't yet started using cabal-dev.) * It reinterprets the entire application, instead of just the files that changed and their dependencies. * It has no knowledge of your cabal file, and so simply tries to use the most recent version of each package available. A few people this week noticed problems running wai-handler-devel since WAI 0.4 was released but is not yet supported by Yesod. Some of these issues can be solved while still sticking with Hint. However, that will require reimplementing a significant amount of work that already exists in other places. I think our best bet is to re-evaluate entirely what we need, and think about the best way to get there. Let's start by pointing out why "cabal build && ./dist/build/myapp/myapp" isn't good enough: * Linking an executable is *very* slow. * You have to manually kill your application and rerun the above command each time you change a file. * If an external file included by Template Haskell, such as a Hamlet template, is modified, cabal does not know to recompile that module. But the fact is that the simple cabal build approach *does* solve all of the issues we currently have with wai-handler-devel. (Well, at least the three I mention above, feel free to chime in here.) So here's an idea: let's try to build on top of cabal so we can take advantage of its features. As for the points listed above, I'll address them in reverse order. wai-handler-devel already contains code that determines which "extra" files are actually dependencies for a module. For example, it looks for hamletFile through your source code and, when it finds it, notes that the specified file is a dependency. We can easily write a tool that checks the timestamps on all the files, determines if a file needs to be updated, and modifies timestamps accordingly. For example, if Handler/Root.hs uses hamlet/root.hamlet, and the latter has a newer modification date than the former, the tool would change the former's modification date to the same as the latter. As far as manually killing applications and rerunning the compile steps, that's also very simple: we simply have a monitor program that sees if source files have been modified since the last build. wai-handler-devel already does this. We can optimize this on Linux with inotify, and the equivalent on other operating systems, but I think it's fair to say that this is a solved problem. The big question is how to avoid long links. The simple answer is to skip them: we don't actually need an executable, just the object files. We'll then use plugins[1] to hot-load the code... except that plugins seems to be (1) buggy and (2) not cross-platform. We can try out direct-plugins[2] instead, but it seems that it will require us to install the package into GHC's database, which isn't necessarily a good idea. (Perhaps we can ask Dan very nicely to make some API changes to help us here?) The third route is writing the hot-loading code ourselves. Andy Stewart pointed out to me that manatee[3] does this directly against the GHC API. My guess: our best bet is to ask Dan (direct-plugins's author) to work with us on augmenting his package with the features we need. This can have ramifications outside the realm of wai-handler-devel, such as having a server that hot-loads code for individual applications. (I was thinking of this for Lambda Engine actually.) But before starting down that route, I'd love to hear if others have any opinions on the subject. Sorry for the long email :) Michael [1] http://hackage.haskell.org/package/plugins [2] http://hackage.haskell.org/package/direct-plugins [3] http://hackage.haskell.org/package/manatee

4 3

GGHandler and MonadPeelIO
by Aur Saraf 08 Apr '11

08 Apr '11

Hello, ----------------->>>>>>>>>><<<<<<<<<-------------------- runDB: need liftIOHandler ⁋For the impatient: stick liftIOHandler at the beginning of runDB like so: runDB db = liftIOHandler $ fmap connPool getYesod >>= Settings.runConnectionPool dbNo comments Add a commentName: ⁋For everyone else: WAI 0.2 contained the request body as an Enumerator in the Request datatype, and an Application was Request -> IO Response. In WAI 0.3, an Application is Request -> Iteratee ByteString IO Response. Long story short: all code in your Handler function now lives on top of an Iteratee monad so that it can access the request body.No comments Add a commentName: ⁋This works great most of the time. The only downside is when you need to deal with exceptions. It's impossible to define a MonadPeelIO instance for Iteratee. Therefore, in Yesod 0.7, we have a new datatype called GGHandler, which is just a generalization of GHandler to allow an arbitrary inner monad.No comments Add a commentName: ⁋GHandler defaults to having an Iteratee on the inside. But when you need a MonadPeelIO (like we do in Persistent), you need to have an IO on the inside. Eventually though, you'll need to convert your GGHandler IO to a GHandler. That's what liftIOHandler does.No comments ----------------->>>>>>>>>><<<<<<<<<-------------------- Could anyone please explain this better, and what it means to someone upgrading an application? Specifically, what happens to: -- | A useful synonym; most of the DB handler functions are of this type type DB = SqlPersist Handler ? Thanks :-), Aur

2 1

Passing a MongoDB connection through to Yesod
by Xavier Shay 08 Apr '11

08 Apr '11

Hello, I am having trouble wiring up Persistent.MongoDB into a Yesod app - I can't quite wrap my head around how it fits together. I have this test file: https://gist.github.com/909264 I know withMongoDBConn wiring is incorrect, but I can't find a good example to base it off. Also not sure what the correct `select` call is to use - Database.MongoDB or Database.Persist.MongoDB. Cheers, Xavier PS I'm using: https://github.com/gregwebs/persistent/tree/MongoDB5

2 1