My advice is to try the demo in migrationexample first, and then - refer to the googlegroups thread if necessary. +
My advice is to try the demo in migrationexample first, + following the directions in the readme file, and then refer to the googlegroups thread if necessary. hunk ./templates/mainfunction.st 3 -
Have a look at Main.hs module at the core of this web application.
+Have a look at the Main.hs module which is at the core of this web application.
+ +In particular, notice the line + +
smartserver (Conf p Nothing) "happs-tutorial" (controller allowStressTests) stateProxy + +
This is a library function, which can be looked up via the ghci info directive (or i for short):
+
+
*Main> :i smartserver
+
smartserver ::
+
(Methods st, Component st, ToMessage a) =>
+
Conf -> String -> [ServerPartT IO a] -> Proxy st -> IO ()
+
-- Defined in HAppS.Server.Helpers
+
+
Each of these arguments is important enough to say something brief about. + +
In this case, the configuration argument just specifies the port the server runs on. + +
The second string argument controls where serialized app state will + be stored: in this case, under "_local/happs-tutorial". This is mainly for convenience, so the state + directory is the same whether we are running in ghci or ghc. (HAppS out of the box just looks + at the executable name, which in the case of ghci is something weird.) + +
The third argument tells HAppS what to use as a controller, in the MVC sense. + Basically, how to handle http requests. + +
The fourth argument tells happs what data structure to use for application state. + We'll cover about the HAppS state system in depth, but later.
hunk ./templates/mainfunction.st 32 -Two bits of code that should jump out at you as being important are hunk ./templates/mainfunction.st 33 -
We'll pospone learning about the HAppS state system (the first line) for later.
hunk ./templates/mainfunction.st 38 -*Main> :i controller
-
controller :: [ServerPartT IO Response]
+
+
*Main> :i controller
+
controller :: Bool -> [ServerPartT IO Response]
hunk ./templates/mainfunction.st 42
+
hunk ./templates/mainfunction.st 44
-
newtype ServerPartT m a
-
= ServerPartT {unServerPartT :: Request -> WebT m a}
+
newtype ServerPartT m a = ServerPartT {unServerPartT :: Request -> WebT m a}
hunk ./templates/mainfunction.st 48
+
hunk ./templates/mainfunction.st 54
+
hunk ./templates/mainfunction.st 61
-
hunk ./templates/mainfunction.st 63
-
The controller function is a list of ServerPartTs, which are basically handlers that -accept an HTTP request and return a response. -Well, ok... this is a bit obfuscated by the many types involved in the construction, -and if you want to be pedantic it's probably a bit more complicated than that, but you don't need to understand all +
The controller function is a list of ServerPartTs, which are handlers that +accept an HTTP request and return a response. (The boolean argument determines whether or not we +enable a certain handler -- "stress tests" -- which is discussed later; don't worry about it for now.) +This is a bit obfuscated by the many types involved in the construction, +and if you want to be pedantic it's actually a bit more complicated than that, but you don't need to understand all