Merge pull request #285 from yesodweb/docs-book

Minor fixes till the routing chapter

book/asciidoc/routing-and-handlers.asciidoc

@@ -324,30 +324,27 @@ Yesod libraries. Instead, the libraries provide the data type:
 
 [source, haskell]
 ----
-data HandlerT site m a
+data HandlerFor site a
 ----
 
-And like +WidgetT+, this has three arguments: a base monad +m+, a monadic value
-+a+, and the foundation data type +site+. Each application defines a +Handler+
-synonym which constrains +site+ to that application's foundation data type, and
-sets +m+ to +IO+. If your foundation is +MyApp+, in other words, you'd have the
+And like +WidgetFor+, this has two arguments: a monadic value +a+, and
+the foundation data type +site+. Each application defines a +Handler+
+synonym which constrains +site+ to that application's foundation data
+type. If your foundation is +MyApp+, in other words, you'd have the
 synonym:
 
 [source, haskell]
 ----
-type Handler = HandlerT MyApp IO
+type Handler = HandlerFor MyApp
 ----
 
-We need to be able to modify the underlying monad when writing subsites, but
-otherwise we'll use +IO+.
-
-The +HandlerT+ monad provides access to information about the user request
+The +HandlerFor+ monad provides access to information about the user request
 (e.g. query-string parameters), allows modifying the response (e.g., response
 headers), and more. This is the monad that most of your Yesod code will live
 in.
 
-In addition, there's a type class called +MonadHandler+. Both +HandlerT+ and
-+WidgetT+ are instances of this type class, allowing many common functions to
+In addition, there's a type class called +MonadHandler+. Both +HandlerFor+ and
++WidgetFor+ are instances of this type class, allowing many common functions to
 be used in both monads. If you see +MonadHandler+ in any API documentation, you
 should remember that the function can be used in your +Handler+ functions.
 
@@ -546,7 +543,7 @@ expiresAt:: Sets the Expires header to the specified date/time.
 
 === I/O and debugging
 
-The +HandlerT+ and +WidgetT+ monad transformers are both instances of a number
+The +HandlerFor+ and +WidgetFor+ monad transformers are both instances of a number
 of typeclasses. For this section, the important typeclasses are +MonadIO+ and
 +MonadLogger+. The former allows you to perform arbitrary +IO+ actions inside
 your handler, such as reading from a file. In order to achieve this, you just
@@ -558,7 +555,7 @@ sent. By default, logs are sent to standard output, in development all messages
 are logged, and in production, warnings and errors are logged.
 
 Often times when logging, we want to know where in the source code the logging
-occured. For this, +MonadLogger+ provides a number of convenience Template
+occurred. For this, +MonadLogger+ provides a number of convenience Template
 Haskell functions which will automatically insert source code location into the
 log messages. These functions are +$logDebug+, +$logInfo+, +$logWarn+, and
 +$logError+. Let's look at a short example of some of these functions.

book/asciidoc/yesod-typeclass.asciidoc

@@ -47,7 +47,7 @@ still need to deal with ports. And even if we get the port number from the
 request, are we using HTTP or HTTPS? And even if you know _that_, such an
 approach would mean that, depending on how the user submitted a request would
 generate different URLs. For example, we would generate different URLs
-depending if the user connected to "example.com" or "www.example.com". For
+depending on if the user connected to "example.com" or "www.example.com". For
 Search Engine Optimization, we want to be able to consolidate on a single
 canonical URL.
 
@@ -368,13 +368,13 @@ In fact, you could even use special responses like redirects:
 NOTE: Even though you _can_ do this, I don't actually recommend such practices.
 A 404 should be a 404.
 
-=== External CSS and Javascript
+=== External CSS and JavaScript
 
 NOTE: The functionality described here is automatically included in the scaffolded site, so you don't need to worry about implementing this yourself.
 
 One of the most powerful, and most intimidating, methods in the Yesod typeclass
 is +addStaticContent+. Remember that a Widget consists of multiple components,
-including CSS and Javascript. How exactly does that CSS/JS arrive in the user's
+including CSS and JavaScript. How exactly does that CSS/JS arrive in the user's
 browser? By default, they are served in the +<head>+ of the page, inside
 +<style>+ and +<script>+ tags, respectively.
 
@@ -412,7 +412,7 @@ The scaffolded +addStaticContent+ does a number of intelligent things to help
 you out:
 
 
-* It automatically minifies your Javascript using the hjsmin package.
+* It automatically minifies your JavaScript using the hjsmin package.
 * It names the output files based on a hash of the file contents. This means
   you can set your cache headers to far in the future without fears of stale
   content.
@@ -461,19 +461,19 @@ Yesod, it's just plain old Haskell. There are three methods involved:
 isWriteRequest:: Determine if the current request is a "read" or "write" operations. By default, Yesod follows RESTful principles, and assumes +GET+, +HEAD+, +OPTIONS+, and +TRACE+ requests are read-only, while all others are writable.
 
 isAuthorized:: Takes a route (i.e., type-safe URL) and a boolean indicating whether or not the request is a write request. It returns an +AuthResult+, which can have one of three values:
-*  +Authorized+ 
-*  +AuthenticationRequired+ 
-*  +Unauthorized+ 
+*  +Authorized+
+*  +AuthenticationRequired+
+*  +Unauthorized+
 
 By default, it returns +Authorized+ for all requests.
 
 authRoute:: If +isAuthorized+ returns +AuthenticationRequired+, then redirect
 to the given route. If no route is provided (the default), return a 401
 ``authentication required'' message.
 
-These methods tie in nicely with the yesod-auth package, which is used by the
-scaffolded site to provide a number of authentication options, such as OpenID,
-Mozilla Persona, email, username and Twitter. We'll cover more concrete
+These methods tie in nicely with the yesod-auth package, which is used
+by the scaffolded site to provide a number of authentication options,
+such as OpenID, email, username and Twitter. We'll cover more concrete
 examples in the auth chapter.
 
 === Some Simple Settings