April 2011 - web-devel

Join support in persistent
by Michael Snoyman 04 Apr '11

04 Apr '11

Hey all, After a long discussion with Aur Saraf, I think we came up with a good approach to join support in Persistent. Let's review the goals: * Allow for non-relational backends, such as Redis (simple key-value stores) * Allow SQL backends to take advantage of the database's JOIN abilities. * Not force SQL backends to use JOIN if they'd rather avoid it. * Keep a simple, straight-forward, type-safe API like we have everywhere else in Persistent. * Cover the most common (say, 95%) of use cases out-of-the-box. So our idea (well, if you don't like it, don't blame Aur...) is to provide a separate module (Database.Persist.Join) which provides special functions for the most common join operations. To start with, I want to handle a two-table one-to-many relationship. For demonstration purposes, let's consider a blog entry application, with entities Author and Entry. Each Entry has precisely one Author, and each Author can have many entries. In Persistent, it looks like: Author name String Asc isPublic Bool Eq Entry author AuthorId Eq title String published UTCTime Desc isPublic Bool Eq In order to get a list of all entries along with their authors, you can use the newly added[1] selectOneMany function: selectOneMany [AuthorIsPublicEq True] [AuthorNameAsc] [EntryIsPublicEqTrue] [EntryPublishedDesc] EntryAuthorEq This will return a value of type: type AuthorPair = (AuthorId, Author) type EntryPair = (EntryId, Entry) [(AuthorPair, [EntryPair])] In addition to Database.Persist.Join, there is also a parallel module named Database.Persist.Join.Sql, which has an alternative version of selectOneMany that is powered by a SQL JOIN. It has almost identical semantics: the only catch comes in when you don't fully specify ordering. But then again, if you don't specify ordering in the first place the order of the results is undefined, so it really *is* identical semantics, just slightly different behavior. Anyway, it's almost 1 in the morning, so I hope I haven't rambled too much. The basic idea is this: Persistent 0.5 will provide a nice, high-level approach to relations. I'll be adding more functions to these modules as necessary, and I'd appreciate input on what people would like to see there. Michael [1] https://github.com/snoyberg/persistent/commit/d2b52a6a7b7a6af6234315492f24f…

2 10

embedding hamlet/julius/cassius in a hamlet file
by Max Cantor 04 Apr '11

04 Apr '11

If I add several julius widgets using addJulius $(Settings.juliusFile xxx) addJulius $(Settings.juliusFile yyy) I get a link in the head of my generated html file. is there an easy way to get the plain javascript text either automatically embedded between <script> tags on the generated HTML file or just to extract the text from several julius files and embed it outselves between script tags in hamlet? I tried this: j <- extractBody $ addJulius $(Settings.juliusFile xxx) and including, in the hamlet file: ^{j} but that didn't compile with this erorr: Couldn't match expected type `GGWidget sub a (GHandler sub a) ()' against inferred type `(Route a -> [(String, String)] -> String) -> Html' Max

2 1

CRUD Example
by Francisco José CHAVES ALONSO 03 Apr '11

03 Apr '11

Hi There is a CRUD example that I could try? Thanks

1 0

(Yesod) PersistEntity Key types
by Rick Richardson 03 Apr '11

03 Apr '11

I ran into another snag getting the tests running for MongoDB backend. The PersistEntity class, and, it appears, the TH is hardcoded to set the key type as Int64. This is a problem since the key type in MongoDB is a 12 byte blob. The other problem is that it looks like PersistBackends are pretty much hardcoded to that type as well. I guess the correct approach would be to allow the designation in mkPersist and then ensure that the PersistBackends can parametrically deal with differing Key types. Or, in the case of MongoDB, hardcode it to a 12 byte blob, because other key types (ObjectId's) rarely make sense. Thoughts?

3 7

Cascading/Scoping via indenting/whitespace in Cassius
by "Timo B. Hübel" 03 Apr '11

03 Apr '11

Hi, one of my most loved features in SASS is automatic scoping/cascading via indenting/significant whitespace. Consider the following SASS code: #header p color: red #content p color: blue Sass does automatically cascade the two p definitions in the resulting CSS: #header p { color: red; } #content p { color: blue; } Is this possible in Cassius? Or considered as feature for the future? IMHO does this feature lead to very concisely scoped CSS while removing the burden of specifying the cascades from the developer. Cheers, T.

2 3

YesodAuth and E-Mail
by "Timo B. Hübel" 03 Apr '11

03 Apr '11

Hi, I am using YesodAuth with the e-mail plugin for login/signup. I have successfully spread some links for login and logout throughout my app, but I also want to link to the signup page from somewhere else (the one which is accessible via the "I don't have an account" link on the login page). Is this possible? Thanks, T.

2 1

Error logging in Yesod
by Michael Snoyman 02 Apr '11

02 Apr '11

Hi all, Hot on the heels of the decision to remove logging from WAI, I would like to add it to Yesod. I think (at least to start with), we really need two modifications: a new method in the Yesod typeclass that specifies what to do with log messages, and a function living in the Handler monad that calls that method. I do not have any strong opinions on this topic, so I would appreciate input. Here's a strawman proposal: data LogLevel = LevelInfo | LevelWarn | LevelError | LevelOther Text class Yesod a where messageLogger :: a -> LogLevel -> Text -> IO () messageLogger _ level msg = formatLogMessage level msg >>= Data.Text.Lazy.IO.hPutStrLn System.IO.stderr formatLogMessage :: LogLevel -> Text -> IO Text formatLogMessage = ... -- print timestamp, log level, message, maybe process ID? to stderr -- make sure to expose the logInfo :: MonadIO m => Text -> GGHandler sub master m () logInfo t = do y < getYesod liftIO $ messageLogger y LevelInfo t ... and so on and so forth This should give completely flexibility to users to send their logs anywhere (database, printer, missiles) and in whatever format they want. Other ideas: * It would be nice to include file/line number information, but I'm not sure how easy/possible that will be without requiring the user to manually enter CPP macros. * Actually, that was my only other idea :) Michael

4 6

Mongo for Yesod? [Continued]
by kenny lu 02 Apr '11

02 Apr '11

@Greg, I knew that you guys been working on this. I do not mean to rush... I've been trying out to use your development branch on https://github.com/gregwebs/persistent/tree/MongoDB5/backends It compiles, but I am still unable to crack it, the test1.hs example is still demanding an update. Regards, Kenny Lu

2 1

Last call for comments: WAI 0.4
by Michael Snoyman 01 Apr '11

01 Apr '11

Hi all, Just wanted to give everyone a last chance to give input on WAI 0.4 before its release. You can see the code on Github[1]. The main things to point out in this release are: * We've switched to using http-types, so WAI needs to define much less on its own (i.e., statuses, HTTP versions, etc). Additionally, we now rely on the case-insensitive library for header keys. * The Request datatype now contains parsed pathInfo and queryString. This makes it more efficient to write middlewares. The raw path info and query string are still available as rawPathInfo and rawQueryString, respectively. * Partial file responses are now supported. The ResponseFile constructor takes a fourth argument, Maybe FilePart. FilePart contains the offset and count. If anyone has other ideas that they'd like to see implemented in WAI, please get them in sooner, rather than later. I'm hoping that this release will last for quite a while. We'll also be releasing a number of associated packages at the same time (wai-extra, warp, wai-test, etc), so if you have comments on those, feel free to submit them as well. Michael [1] https://github.com/snoyberg/wai/blob/master/Network/Wai.hs

11 28