I am in the process of migrating patch-tag to the latest version of happstack, and I thought I would post some diffs to aid others who have the same task.
This probably isn’t of much interest unless you are actually faced with a migration — but if you are, could save you some time and starting at compile complaints.
< happstack-data == 0.1,
< happstack-helpers == 0.11,
< happstack-ixset == 0.1,
< happstack-server == 0.1,
< happstack-state == 0.1,
< happstack-util == 0.1,
---
> happstack-data == 0.3.3,
> happstack-helpers == 0.30,
> happstack-ixset == 0.3.2,
> happstack-server == 0.3.3,
> happstack-state == 0.3.3,
> happstack-util == 0.3.2,
notice msum
< controller pubdom privdom ts dynamicTemplateReload realEmail wikitmpl mime useGoogAnalytics =
< (staticfiles ++)
---
> controller pubdom privdom ts dynamicTemplateReload realEmail wikitmpl mime useGoogAnalytics =
> msum [ staticfiles
notice ReaderT
< mainController pubdom privdom ts' dynamicTemplateReload realEmail wikitmpl mime ga =
< [ ServerPartT $ \rq -> do
---
> mainController pubdom privdom ts' dynamicTemplateReload realEmail wikitmpl mime ga =
> ServerPartT $ ReaderT $ \rq -> do
notice s/unserverPartT/runServerPartT/
< unServerPartT ( multi $ mainCommon pubdom privdom (RenderGlobals rq ts mbSession ga) mailFx wikitmpl mime) rq
< ]
---
> runServerPartT ( msum $ mainCommon pubdom privdom (RenderGlobals rq ts mbSession ga) mailFx wikitmpl mime) rq
</code></pre>
Instead of:
ServerPartT $ ReaderT $ \rq -> do …
you can probably write:
do rq <- askRq
…
Also, It's not obvious from the context why you are using runServerPartT. If it is because you wanted to modify the incoming request somehow, you might consider localRq instead.
An advantage of using askRq and localRq over explicit matching is that they work in any monad for which there is a ServerMonad instance. This will sound more useful once I have my latest happstack demo running and you can see the source.
Anyway, those are just happstack 3.x stylistic changes. The code you wrote should work fine too.
- jeremy