
I'd like to support getBy404 as like as get404 on yesod framework. getBy404 ukey = do mres <- getBy ukey case mres of Nothing -> lift notFound Just res -> return res for example, on wiki site, the resource url include wikiname as key(String) not id (Int). In this situation, getBy404 are frequently encountered. How about this?

That's a good idea. I've pushed a commit with that code to Git. I'm
not sure if I'm going to release a 0.6.8 including some recent
changes, or just wait for 0.7. If you need the function sooner rather
than later, then speak up ;).
Now a question for everyone: what do people think of removing
persistent as a dependency for yesod, and creating a separate
yesod-persistent package? Similar arguments apply here as for
yesod-auth and yesod-form: yesod is lighter, APIs can change more
freely, and less dependencies. Another possible change would be to
remove the hamlet and web-routes-quasi dependencies from persistent,
and instead stick orphan instances in a yesod-persistent package.
Thoughts are welcome on this, I'm rather ambivalent at the moment.
Michael
2010/12/20 いとうかつとし
I'd like to support getBy404 as like as get404 on yesod framework. getBy404 ukey = do mres <- getBy ukey case mres of Nothing -> lift notFound Just res -> return res for example, on wiki site, the resource url include wikiname as key(String) not id (Int). In this situation, getBy404 are frequently encountered. How about this?
_______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel

2010/12/20 Michael Snoyman
Now a question for everyone: what do people think of removing persistent as a dependency for yesod, and creating a separate yesod-persistent package? Similar arguments apply here as for yesod-auth and yesod-form: yesod is lighter, APIs can change more freely, and less dependencies. Another possible change would be to remove the hamlet and web-routes-quasi dependencies from persistent, and instead stick orphan instances in a yesod-persistent package.
I like separation in many packages. Especially with persistent, given that in many cases it may be not sufficient. Maybe it would be even nicer to rename the lighter yesod into yesod-base, and then create a metapackage yesod that depends on everything else with consistent, tested version numbers. Cheers, -- Felipe.

2010/12/20 Felipe Almeida Lessa
2010/12/20 Michael Snoyman
: Now a question for everyone: what do people think of removing persistent as a dependency for yesod, and creating a separate yesod-persistent package? Similar arguments apply here as for yesod-auth and yesod-form: yesod is lighter, APIs can change more freely, and less dependencies. Another possible change would be to remove the hamlet and web-routes-quasi dependencies from persistent, and instead stick orphan instances in a yesod-persistent package.
I like separation in many packages. Especially with persistent, given that in many cases it may be not sufficient.
Maybe it would be even nicer to rename the lighter yesod into yesod-base, and then create a metapackage yesod that depends on everything else with consistent, tested version numbers.
OK, the code is separated in the 0.7 branch[1]. I'm also thinking about creating a yesod-base package like you mentioned. Here's some bikeshedding stuff: * Should it be yesod-base or yesod-core? * Maybe we should leave it as yesod and create a new package called yesod-complete? (I don't particularly like this...) * Should yesod-base have a plain Yesod module, or should that be in the yesod-complete package and export all the stuff (forms, persistent) that we have right now? * And should we split the scaffolding tool into its own package as well? This probably depends a lot on which base (base or complete) ends up getting the plain "yesod" name. Michael [1] https://github.com/snoyberg/yesod/tree/ver0.7

2010/12/20 Michael Snoyman
* Should it be yesod-base or yesod-core?
yesod-core sounds better :).
* Maybe we should leave it as yesod and create a new package called yesod-complete? (I don't particularly like this...)
Neither do I.
* Should yesod-base have a plain Yesod module, or should that be in the yesod-complete package and export all the stuff (forms, persistent) that we have right now?
I think "Yesod" module should be in 'yesod' package. See below.
* And should we split the scaffolding tool into its own package as well? This probably depends a lot on which base (base or complete) ends up getting the plain "yesod" name.
I think it should be in 'yesod' package as well. The scaffolding tool prefers using libraries from the yesod ecosystem, so I can't see the advantage of splitting it from 'yesod' package. My 2¢. Cheers! -- Felipe.
participants (3)
-
Felipe Almeida Lessa
-
Michael Snoyman
-
いとうかつとし