From 18cf52f9027a036cd7e40e48074471d48182f5a0 Mon Sep 17 00:00:00 2001
From: snoyberg Routing
"GET" -> getHomeR
_ -> badMethod
-type Handler = HandlerT HelloWorld IO
+type Handler = HandlerFor HelloWorld
@@ -154,10 +154,10 @@ Handler function
whamlet
is another quasi-quoter. In this case, it converts Hamlet syntax into
a Widget. Hamlet is the default HTML templating engine in Yesod. Together with
its siblings Cassius, Lucius and Julius, you can create HTML, CSS and
-Javascript in a fully type-safe and compile-time-checked manner. We’ll see much
+JavaScript in a fully type-safe and compile-time-checked manner. We’ll see much
more about this in the Shakespeare chapter.
Widgets are another cornerstone of Yesod. They allow you to create modular -components of a site consisting of HTML, CSS and Javascript and reuse them +components of a site consisting of HTML, CSS and JavaScript and reuse them throughout your site. We’ll get into more detail on them in the widgets chapter.
@@ -204,7 +204,7 @@Once again we mention HelloWorld
in our main function. Our foundation
contains all the information we need to route and respond to requests in our
application; now we just need to convert it into something that can run. A
-useful function for this in Yesod is warp
, which runs the Warp webserver with
+useful function for this in Yesod is warp
, which runs the Warp web server with
a number of default settings enabled on the specified port (here, it’s 3000).
One of the features of Yesod is that you aren’t tied down to a single deployment strategy. Yesod is built on top of the Web Application Interface diff --git a/public/book-1.6/haskell.html b/public/book-1.6/haskell.html index d5ebe0a..9b01042 100644 --- a/public/book-1.6/haskell.html +++ b/public/book-1.6/haskell.html @@ -22,7 +22,7 @@
Additionally, there are a number of great articles on -School of Haskell.
+FP Complete’s Haskell’s hub.In order to use Yesod, you’re going to have to know at least the basics of Haskell. Additionally, Yesod uses some features of Haskell that aren’t covered in most introductory texts. While this book assumes the reader has a basic @@ -150,7 +150,7 @@
I personally never use the GHC command line argument approach. It’s a personal
-preference, but I like to have my settings clearly stated in a file. In general
+preference, but I like to have my settings clearly stated in a file. In general,
it’s recommended to avoid putting extensions in your cabal
file; however,
this rule mostly applies when writing publicly available libraries. When you’re
writing an application that you and your team will be working on, having all of
@@ -281,7 +281,7 @@
A nice trick is that TH code is allowed to perform arbitrary IO
actions, and
therefore we can place some input in external files and have it parsed at
compile time. One example usage is to have compile-time checked HTML, CSS, and
-Javascript templates.
If your Template Haskell code is being used to generate declarations, and is being placed at the top level of our file, we can leave off the dollar sign and parentheses. In other words:
diff --git a/public/book-1.6/introduction.html b/public/book-1.6/introduction.html index d3f6bff..b42dd8b 100644 --- a/public/book-1.6/introduction.html +++ b/public/book-1.6/introduction.html @@ -9,7 +9,7 @@ process a more pleasant one. As a community, we have continually pushed new techniques to try and solve some of the lingering difficulties of security threats, the stateless nature of HTTP, the multiple languages (HTML, CSS, -Javascript) necessary to create a powerful web application, and more. +JavaScript) necessary to create a powerful web application, and more.Yesod attempts to ease the web development process by playing to the strengths of the Haskell programming language. Haskell’s strong compile-time guarantees of correctness not only encompass types; referential transparency ensures that diff --git a/public/book-1.6/shakespearean-templates.html b/public/book-1.6/shakespearean-templates.html index 1162371..8198a71 100644 --- a/public/book-1.6/shakespearean-templates.html +++ b/public/book-1.6/shakespearean-templates.html @@ -6,7 +6,7 @@
Yesod uses the Shakespearean family of template languages as its standard -approach to HTML, CSS and Javascript creation. This language family shares some +approach to HTML, CSS and JavaScript creation. This language family shares some common syntax, as well as overarching principles:
In addition to HTML, CSS and Javascript helpers, there is also some more +
In addition to HTML, CSS and JavaScript helpers, there is also some more general-purpose Shakespeare available. shakespeare-text provides a simple way to create interpolated strings, much like people are accustomed to in scripting languages like Ruby and Python. This package’s utility is definitely not diff --git a/public/book-1.6/widgets.html b/public/book-1.6/widgets.html index 63e3eca..cc93c4c 100644 --- a/public/book-1.6/widgets.html +++ b/public/book-1.6/widgets.html @@ -6,13 +6,13 @@
One of the challenges in web development is that we have to coordinate three -different client-side technologies: HTML, CSS and Javascript. Worse still, we +different client-side technologies: HTML, CSS and JavaScript. Worse still, we have to place these components in different locations on the page: CSS in a -style tag in the head, Javascript in a script tag before the closing body tag, and HTML in the -body. And never mind if you want to put your CSS and Javascript in separate +style tag in the head, JavaScript in a script tag before the closing body tag, and HTML in the +body. And never mind if you want to put your CSS and JavaScript in separate files!
In practice, this works out fairly nicely when building a single page, because -we can separate our structure (HTML), style (CSS) and logic (Javascript). But +we can separate our structure (HTML), style (CSS) and logic (JavaScript). But when we want to build modular pieces of code that can be easily composed, it can be a headache to coordinate all three pieces separately. Widgets are Yesod’s solution to the problem. They also help with the issue of including @@ -126,7 +126,7 @@
-Javascript code +JavaScript code
But what if you want to add some <meta>
tags, which need to appear in
-the head? Or if you want some Javascript to appear in the body instead of the
+the head? Or if you want some JavaScript to appear in the body instead of the
head? For these purposes, Yesod provides two additional type classes:
ToWidgetHead
and ToWidgetBody
. These work exactly as they seem they should. One example use case for this is to have fine-grained control of where your <script>
tags end up getting inserted.
{-# LANGUAGE OverloadedStrings #-}
@@ -247,7 +247,7 @@ Constructing Widgets
Combining Widgets
The whole idea of widgets is to increase composability. You can take these
-individual pieces of HTML, CSS and Javascript, combine them together into
+individual pieces of HTML, CSS and JavaScript, combine them together into
something more complicated, and then combine these larger entities into
complete pages. This all works naturally through the Monad
instance of
Widget
, meaning you can use do-notation to compose pieces together.
@@ -333,20 +333,18 @@ Types
answer is that each widget is a value of type Widget
. But if you look through
the Yesod libraries, you’ll find no definition of the Widget
type. What
gives?
-Yesod defines a very similar type: data WidgetT site m a
. This data type is a
-monad transformer. The last two arguments are the underlying monad and the
-monadic value, respectively. The site parameter is the specific foundation
-type for your individual application. Since this type varies for each and every
-site, it’s impossible for the libraries to define a single Widget
datatype
-which would work for every application.
+Yesod defines a very similar type: data WidgetFor site a
. This data
+type is a monad transformer. The last argument a
is the monadic
+value. The site parameter is the specific foundation type for your
+individual application. Since this type varies for each and every
+site, it’s impossible for the libraries to define a single Widget
+datatype which would work for every application.
Instead, the mkYesod
Template Haskell function generates this type synonym
for you. Assuming your foundation data type is called MyApp
, your Widget
synonym is defined as:
-type Widget = WidgetT MyApp IO ()
+type Widget = WidgetFor MyApp ()
We set the monadic value to be ()
, since a widget’s value will ultimately be
-thrown away. IO
is the standard base monad, and will be used in almost all
-cases. The only exception is when writing a subsite. Subsites are a more
-advanced topic, and will be covered later in their own chapter.
+thrown away.
Once we know about our Widget
type synonym, it’s easy to add signatures to
our previous code samples:
footer :: Widget
@@ -371,7 +369,7 @@ Types
^{footer}
|]
When we start digging into handler functions some more, we’ll encounter a
-similar situation with the HandlerT
and Handler
types.
+similar situation with the HandlerFor
and Handler
types.
@@ -379,7 +377,7 @@ Using Widgets
It’s all well and good that we have these beautiful Widget datatypes, but how
exactly do we turn them into something the user can interact with? The most
commonly used function is defaultLayout
, which essentially has the type
-signature Widget → Handler Html
.
+signature WidgetFor → HandlerFor Html
.
defaultLayout
is actually a typeclass method, which can be overridden for
each application. This is how Yesod apps are themed. So we’re still left with
the question: when we’re inside defaultLayout
, how do we unwrap a Widget
?
@@ -525,7 +523,7 @@
Using handler functions
Summary
The basic building block of each page is a widget. Individual snippets of HTML,
-CSS, and Javascript can be turned into widgets via the polymorphic toWidget
+CSS, and JavaScript can be turned into widgets via the polymorphic toWidget
function. Using do-notation, you can combine these individual widgets into
larger widgets, eventually containing all the content of your page.
Unwrapping these widgets is usually performed within the defaultLayout
diff --git a/public/book/basics.html b/public/book/basics.html
index d7c89dd..254fb4b 100644
--- a/public/book/basics.html
+++ b/public/book/basics.html
@@ -90,7 +90,7 @@
Routing
"GET" -> getHomeR
_ -> badMethod
-type Handler = HandlerT HelloWorld IO
+type Handler = HandlerFor HelloWorld
In addition to using -ddump-splices
, it can often be useful to generate
Haddock documentation for your application to see which functions and data
types were generated for you.
whamlet
is another quasi-quoter. In this case, it converts Hamlet syntax into
a Widget. Hamlet is the default HTML templating engine in Yesod. Together with
its siblings Cassius, Lucius and Julius, you can create HTML, CSS and
-Javascript in a fully type-safe and compile-time-checked manner. We’ll see much
+JavaScript in a fully type-safe and compile-time-checked manner. We’ll see much
more about this in the Shakespeare chapter.
Widgets are another cornerstone of Yesod. They allow you to create modular -components of a site consisting of HTML, CSS and Javascript and reuse them +components of a site consisting of HTML, CSS and JavaScript and reuse them throughout your site. We’ll get into more detail on them in the widgets chapter.
@@ -204,7 +204,7 @@Once again we mention HelloWorld
in our main function. Our foundation
contains all the information we need to route and respond to requests in our
application; now we just need to convert it into something that can run. A
-useful function for this in Yesod is warp
, which runs the Warp webserver with
+useful function for this in Yesod is warp
, which runs the Warp web server with
a number of default settings enabled on the specified port (here, it’s 3000).
One of the features of Yesod is that you aren’t tied down to a single deployment strategy. Yesod is built on top of the Web Application Interface diff --git a/public/book/haskell.html b/public/book/haskell.html index 427a2f2..b41575b 100644 --- a/public/book/haskell.html +++ b/public/book/haskell.html @@ -22,7 +22,7 @@
Additionally, there are a number of great articles on -School of Haskell.
+FP Complete’s Haskell’s hub.In order to use Yesod, you’re going to have to know at least the basics of Haskell. Additionally, Yesod uses some features of Haskell that aren’t covered in most introductory texts. While this book assumes the reader has a basic @@ -150,7 +150,7 @@
I personally never use the GHC command line argument approach. It’s a personal
-preference, but I like to have my settings clearly stated in a file. In general
+preference, but I like to have my settings clearly stated in a file. In general,
it’s recommended to avoid putting extensions in your cabal
file; however,
this rule mostly applies when writing publicly available libraries. When you’re
writing an application that you and your team will be working on, having all of
@@ -281,7 +281,7 @@
A nice trick is that TH code is allowed to perform arbitrary IO
actions, and
therefore we can place some input in external files and have it parsed at
compile time. One example usage is to have compile-time checked HTML, CSS, and
-Javascript templates.
If your Template Haskell code is being used to generate declarations, and is being placed at the top level of our file, we can leave off the dollar sign and parentheses. In other words:
diff --git a/public/book/introduction.html b/public/book/introduction.html index e00d8c1..003f105 100644 --- a/public/book/introduction.html +++ b/public/book/introduction.html @@ -9,7 +9,7 @@ process a more pleasant one. As a community, we have continually pushed new techniques to try and solve some of the lingering difficulties of security threats, the stateless nature of HTTP, the multiple languages (HTML, CSS, -Javascript) necessary to create a powerful web application, and more. +JavaScript) necessary to create a powerful web application, and more.Yesod attempts to ease the web development process by playing to the strengths of the Haskell programming language. Haskell’s strong compile-time guarantees of correctness not only encompass types; referential transparency ensures that diff --git a/public/book/shakespearean-templates.html b/public/book/shakespearean-templates.html index d6b2296..e1c5159 100644 --- a/public/book/shakespearean-templates.html +++ b/public/book/shakespearean-templates.html @@ -6,7 +6,7 @@
Yesod uses the Shakespearean family of template languages as its standard -approach to HTML, CSS and Javascript creation. This language family shares some +approach to HTML, CSS and JavaScript creation. This language family shares some common syntax, as well as overarching principles:
Cassius is in fact just an alternate syntax for Lucius. They both use the same processing engine underneath, but Cassius files have indentation converted into braces before processing. The choice between the two is purely one of @@ -90,7 +90,7 @@
String interpolation works slightly differently in Julius. This is important
from a security standpoint — all interpolated values are valid JSON by default
which helps prevent XSS attacks. You’ll need to use the rawJS
function to get
@@ -229,7 +229,7 @@
All Shakespearean languages share the same interpolation syntax, and are able to utilize type-safe URLs. They differ in the syntax specific for their target -language (HTML, CSS, or Javascript). Let’s explore each language in turn.
+language (HTML, CSS, or JavaScript). Let’s explore each language in turn.Hamlet is the most sophisticated of the languages. Not only does it provide @@ -617,11 +617,11 @@
Julius is the simplest of the languages discussed here. In fact, some might -even say it’s really just Javascript. Julius allows the three forms of +even say it’s really just JavaScript. Julius allows the three forms of interpolation we’ve mentioned so far, and otherwise applies no transformations to your content.
If you use Julius with the scaffolded Yesod site, you may notice that -your Javascript is automatically minified. This is not a feature of Julius; +your JavaScript is automatically minified. This is not a feature of Julius; instead, Yesod uses the hjsmin package to minify Julius output.
We use a different set of functions, prefixed with an "s". So the quasiquoter
is shamlet
and the external file function is shamletFile
. How we
- pronounce those is still up for debate.
+ pronounce this is still up for debate.
In addition to HTML, CSS and Javascript helpers, there is also some more +
In addition to HTML, CSS and JavaScript helpers, there is also some more general-purpose Shakespeare available. shakespeare-text provides a simple way to create interpolated strings, much like people are accustomed to in scripting languages like Ruby and Python. This package’s utility is definitely not diff --git a/public/book/widgets.html b/public/book/widgets.html index a3f8df2..8a1e165 100644 --- a/public/book/widgets.html +++ b/public/book/widgets.html @@ -6,13 +6,13 @@
One of the challenges in web development is that we have to coordinate three -different client-side technologies: HTML, CSS and Javascript. Worse still, we +different client-side technologies: HTML, CSS and JavaScript. Worse still, we have to place these components in different locations on the page: CSS in a -style tag in the head, Javascript in a script tag before the closing body tag, and HTML in the -body. And never mind if you want to put your CSS and Javascript in separate +style tag in the head, JavaScript in a script tag before the closing body tag, and HTML in the +body. And never mind if you want to put your CSS and JavaScript in separate files!
In practice, this works out fairly nicely when building a single page, because -we can separate our structure (HTML), style (CSS) and logic (Javascript). But +we can separate our structure (HTML), style (CSS) and logic (JavaScript). But when we want to build modular pieces of code that can be easily composed, it can be a headache to coordinate all three pieces separately. Widgets are Yesod’s solution to the problem. They also help with the issue of including @@ -126,7 +126,7 @@
-Javascript code +JavaScript code
But what if you want to add some <meta>
tags, which need to appear in
-the head? Or if you want some Javascript to appear in the body instead of the
+the head? Or if you want some JavaScript to appear in the body instead of the
head? For these purposes, Yesod provides two additional type classes:
ToWidgetHead
and ToWidgetBody
. These work exactly as they seem they should. One example use case for this is to have fine-grained control of where your <script>
tags end up getting inserted.
{-# LANGUAGE OverloadedStrings #-}
@@ -247,7 +247,7 @@ Constructing Widgets
Combining Widgets
The whole idea of widgets is to increase composability. You can take these
-individual pieces of HTML, CSS and Javascript, combine them together into
+individual pieces of HTML, CSS and JavaScript, combine them together into
something more complicated, and then combine these larger entities into
complete pages. This all works naturally through the Monad
instance of
Widget
, meaning you can use do-notation to compose pieces together.
@@ -333,20 +333,18 @@ Types
answer is that each widget is a value of type Widget
. But if you look through
the Yesod libraries, you’ll find no definition of the Widget
type. What
gives?
-Yesod defines a very similar type: data WidgetT site m a
. This data type is a
-monad transformer. The last two arguments are the underlying monad and the
-monadic value, respectively. The site parameter is the specific foundation
-type for your individual application. Since this type varies for each and every
-site, it’s impossible for the libraries to define a single Widget
datatype
-which would work for every application.
+Yesod defines a very similar type: data WidgetFor site a
. This data
+type is a monad transformer. The last argument a
is the monadic
+value. The site parameter is the specific foundation type for your
+individual application. Since this type varies for each and every
+site, it’s impossible for the libraries to define a single Widget
+datatype which would work for every application.
Instead, the mkYesod
Template Haskell function generates this type synonym
for you. Assuming your foundation data type is called MyApp
, your Widget
synonym is defined as:
-type Widget = WidgetT MyApp IO ()
+type Widget = WidgetFor MyApp ()
We set the monadic value to be ()
, since a widget’s value will ultimately be
-thrown away. IO
is the standard base monad, and will be used in almost all
-cases. The only exception is when writing a subsite. Subsites are a more
-advanced topic, and will be covered later in their own chapter.
+thrown away.
Once we know about our Widget
type synonym, it’s easy to add signatures to
our previous code samples:
footer :: Widget
@@ -371,7 +369,7 @@ Types
^{footer}
|]
When we start digging into handler functions some more, we’ll encounter a
-similar situation with the HandlerT
and Handler
types.
+similar situation with the HandlerFor
and Handler
types.
@@ -379,7 +377,7 @@ Using Widgets
It’s all well and good that we have these beautiful Widget datatypes, but how
exactly do we turn them into something the user can interact with? The most
commonly used function is defaultLayout
, which essentially has the type
-signature Widget → Handler Html
.
+signature WidgetFor → HandlerFor Html
.
defaultLayout
is actually a typeclass method, which can be overridden for
each application. This is how Yesod apps are themed. So we’re still left with
the question: when we’re inside defaultLayout
, how do we unwrap a Widget
?
@@ -525,7 +523,7 @@
Using handler functions
Summary
The basic building block of each page is a widget. Individual snippets of HTML,
-CSS, and Javascript can be turned into widgets via the polymorphic toWidget
+CSS, and JavaScript can be turned into widgets via the polymorphic toWidget
function. Using do-notation, you can combine these individual widgets into
larger widgets, eventually containing all the content of your page.
Unwrapping these widgets is usually performed within the defaultLayout