github.com/riscv/riscv-go@v0.0.0-20200123204226-124ebd6fcc8e/doc/articles/wiki/index.html (about)

     1  <!--{
     2  	"Title": "Writing Web Applications",
     3  	"Template": true
     4  }-->
     5  
     6  <h2>Introduction</h2>
     7  
     8  <p>
     9  Covered in this tutorial:
    10  </p>
    11  <ul>
    12  <li>Creating a data structure with load and save methods</li>
    13  <li>Using the <code>net/http</code> package to build web applications
    14  <li>Using the <code>html/template</code> package to process HTML templates</li>
    15  <li>Using the <code>regexp</code> package to validate user input</li>
    16  <li>Using closures</li>
    17  </ul>
    18  
    19  <p>
    20  Assumed knowledge:
    21  </p>
    22  <ul>
    23  <li>Programming experience</li>
    24  <li>Understanding of basic web technologies (HTTP, HTML)</li>
    25  <li>Some UNIX/DOS command-line knowledge</li>
    26  </ul>
    27  
    28  <h2>Getting Started</h2>
    29  
    30  <p>
    31  At present, you need to have a FreeBSD, Linux, OS X, or Windows machine to run Go.
    32  We will use <code>$</code> to represent the command prompt.
    33  </p>
    34  
    35  <p>
    36  Install Go (see the <a href="/doc/install">Installation Instructions</a>).
    37  </p>
    38  
    39  <p>
    40  Make a new directory for this tutorial inside your <code>GOPATH</code> and cd to it:
    41  </p>
    42  
    43  <pre>
    44  $ mkdir gowiki
    45  $ cd gowiki
    46  </pre>
    47  
    48  <p>
    49  Create a file named <code>wiki.go</code>, open it in your favorite editor, and
    50  add the following lines:
    51  </p>
    52  
    53  <pre>
    54  package main
    55  
    56  import (
    57  	"fmt"
    58  	"io/ioutil"
    59  )
    60  </pre>
    61  
    62  <p>
    63  We import the <code>fmt</code> and <code>ioutil</code> packages from the Go
    64  standard library. Later, as we implement additional functionality, we will
    65  add more packages to this <code>import</code> declaration.
    66  </p>
    67  
    68  <h2>Data Structures</h2>
    69  
    70  <p>
    71  Let's start by defining the data structures. A wiki consists of a series of
    72  interconnected pages, each of which has a title and a body (the page content).
    73  Here, we define <code>Page</code> as a struct with two fields representing
    74  the title and body.
    75  </p>
    76  
    77  {{code "doc/articles/wiki/part1.go" `/^type Page/` `/}/`}}
    78  
    79  <p>
    80  The type <code>[]byte</code> means "a <code>byte</code> slice".
    81  (See <a href="/doc/articles/slices_usage_and_internals.html">Slices: usage and
    82  internals</a> for more on slices.)
    83  The <code>Body</code> element is a <code>[]byte</code> rather than
    84  <code>string</code> because that is the type expected by the <code>io</code>
    85  libraries we will use, as you'll see below.
    86  </p>
    87  
    88  <p>
    89  The <code>Page</code> struct describes how page data will be stored in memory.
    90  But what about persistent storage? We can address that by creating a
    91  <code>save</code> method on <code>Page</code>:
    92  </p>
    93  
    94  {{code "doc/articles/wiki/part1.go" `/^func.*Page.*save/` `/}/`}}
    95  
    96  <p>
    97  This method's signature reads: "This is a method named <code>save</code> that
    98  takes as its receiver <code>p</code>, a pointer to <code>Page</code> . It takes
    99  no parameters, and returns a value of type <code>error</code>."
   100  </p>
   101  
   102  <p>
   103  This method will save the <code>Page</code>'s <code>Body</code> to a text
   104  file. For simplicity, we will use the <code>Title</code> as the file name.
   105  </p>
   106  
   107  <p>
   108  The <code>save</code> method returns an <code>error</code> value because
   109  that is the return type of <code>WriteFile</code> (a standard library function
   110  that writes a byte slice to a file).  The <code>save</code> method returns the
   111  error value, to let the application handle it should anything go wrong while
   112  writing the file.  If all goes well, <code>Page.save()</code> will return
   113  <code>nil</code> (the zero-value for pointers, interfaces, and some other
   114  types).
   115  </p>
   116  
   117  <p>
   118  The octal integer literal <code>0600</code>, passed as the third parameter to
   119  <code>WriteFile</code>, indicates that the file should be created with
   120  read-write permissions for the current user only. (See the Unix man page
   121  <code>open(2)</code> for details.)
   122  </p>
   123  
   124  <p>
   125  In addition to saving pages, we will want to load pages, too:
   126  </p>
   127  
   128  {{code "doc/articles/wiki/part1-noerror.go" `/^func loadPage/` `/^}/`}}
   129  
   130  <p>
   131  The function <code>loadPage</code> constructs the file name from the title
   132  parameter, reads the file's contents into a new variable <code>body</code>, and
   133  returns a pointer to a <code>Page</code> literal constructed with the proper
   134  title and body values.
   135  </p>
   136  
   137  <p>
   138  Functions can return multiple values. The standard library function
   139  <code>io.ReadFile</code> returns <code>[]byte</code> and <code>error</code>.
   140  In <code>loadPage</code>, error isn't being handled yet; the "blank identifier"
   141  represented by the underscore (<code>_</code>) symbol is used to throw away the
   142  error return value (in essence, assigning the value to nothing).
   143  </p>
   144  
   145  <p>
   146  But what happens if <code>ReadFile</code> encounters an error?  For example,
   147  the file might not exist. We should not ignore such errors.  Let's modify the
   148  function to return <code>*Page</code> and <code>error</code>.
   149  </p>
   150  
   151  {{code "doc/articles/wiki/part1.go" `/^func loadPage/` `/^}/`}}
   152  
   153  <p>
   154  Callers of this function can now check the second parameter; if it is
   155  <code>nil</code> then it has successfully loaded a Page. If not, it will be an
   156  <code>error</code> that can be handled by the caller (see the
   157  <a href="/ref/spec#Errors">language specification</a> for details).
   158  </p>
   159  
   160  <p>
   161  At this point we have a simple data structure and the ability to save to and
   162  load from a file. Let's write a <code>main</code> function to test what we've
   163  written:
   164  </p>
   165  
   166  {{code "doc/articles/wiki/part1.go" `/^func main/` `/^}/`}}
   167  
   168  <p>
   169  After compiling and executing this code, a file named <code>TestPage.txt</code>
   170  would be created, containing the contents of <code>p1</code>. The file would
   171  then be read into the struct <code>p2</code>, and its <code>Body</code> element
   172  printed to the screen.
   173  </p>
   174  
   175  <p>
   176  You can compile and run the program like this:
   177  </p>
   178  
   179  <pre>
   180  $ go build wiki.go
   181  $ ./wiki
   182  This is a sample page.
   183  </pre>
   184  
   185  <p>
   186  (If you're using Windows you must type "<code>wiki</code>" without the
   187  "<code>./</code>" to run the program.)
   188  </p>
   189  
   190  <p>
   191  <a href="part1.go">Click here to view the code we've written so far.</a>
   192  </p>
   193  
   194  <h2>Introducing the <code>net/http</code> package (an interlude)</h2>
   195  
   196  <p>
   197  Here's a full working example of a simple web server:
   198  </p>
   199  
   200  {{code "doc/articles/wiki/http-sample.go"}}
   201  
   202  <p>
   203  The <code>main</code> function begins with a call to
   204  <code>http.HandleFunc</code>, which tells the <code>http</code> package to
   205  handle all requests to the web root (<code>"/"</code>) with
   206  <code>handler</code>.
   207  </p>
   208  
   209  <p>
   210  It then calls <code>http.ListenAndServe</code>, specifying that it should
   211  listen on port 8080 on any interface (<code>":8080"</code>). (Don't
   212  worry about its second parameter, <code>nil</code>, for now.)
   213  This function will block until the program is terminated.
   214  </p>
   215  
   216  <p>
   217  The function <code>handler</code> is of the type <code>http.HandlerFunc</code>.
   218  It takes an <code>http.ResponseWriter</code> and an <code>http.Request</code> as
   219  its arguments.
   220  </p>
   221  
   222  <p>
   223  An <code>http.ResponseWriter</code> value assembles the HTTP server's response; by writing
   224  to it, we send data to the HTTP client.
   225  </p>
   226  
   227  <p>
   228  An <code>http.Request</code> is a data structure that represents the client
   229  HTTP request. <code>r.URL.Path</code> is the path component
   230  of the request URL. The trailing <code>[1:]</code> means
   231  "create a sub-slice of <code>Path</code> from the 1st character to the end."
   232  This drops the leading "/" from the path name.
   233  </p>
   234  
   235  <p>
   236  If you run this program and access the URL:
   237  </p>
   238  <pre>http://localhost:8080/monkeys</pre>
   239  <p>
   240  the program would present a page containing:
   241  </p>
   242  <pre>Hi there, I love monkeys!</pre>
   243  
   244  <h2>Using <code>net/http</code> to serve wiki pages</h2>
   245  
   246  <p>
   247  To use the <code>net/http</code> package, it must be imported:
   248  </p>
   249  
   250  <pre>
   251  import (
   252  	"fmt"
   253  	"io/ioutil"
   254  	<b>"net/http"</b>
   255  )
   256  </pre>
   257  
   258  <p>
   259  Let's create a handler, <code>viewHandler</code> that will allow users to
   260  view a wiki page. It will handle URLs prefixed with "/view/".
   261  </p>
   262  
   263  {{code "doc/articles/wiki/part2.go" `/^func viewHandler/` `/^}/`}}
   264  
   265  <p>
   266  First, this function extracts the page title from <code>r.URL.Path</code>,
   267  the path component of the request URL.
   268  The <code>Path</code> is re-sliced with <code>[len("/view/"):]</code> to drop
   269  the leading <code>"/view/"</code> component of the request path.
   270  This is because the path will invariably begin with <code>"/view/"</code>,
   271  which is not part of the page's title.
   272  </p>
   273  
   274  <p>
   275  The function then loads the page data, formats the page with a string of simple
   276  HTML, and writes it to <code>w</code>, the <code>http.ResponseWriter</code>.
   277  </p>
   278  
   279  <p>
   280  Again, note the use of <code>_</code> to ignore the <code>error</code>
   281  return value from <code>loadPage</code>. This is done here for simplicity
   282  and generally considered bad practice. We will attend to this later.
   283  </p>
   284  
   285  <p>
   286  To use this handler, we rewrite our <code>main</code> function to
   287  initialize <code>http</code> using the <code>viewHandler</code> to handle
   288  any requests under the path <code>/view/</code>.
   289  </p>
   290  
   291  {{code "doc/articles/wiki/part2.go" `/^func main/` `/^}/`}}
   292  
   293  <p>
   294  <a href="part2.go">Click here to view the code we've written so far.</a>
   295  </p>
   296  
   297  <p>
   298  Let's create some page data (as <code>test.txt</code>), compile our code, and
   299  try serving a wiki page.
   300  </p>
   301  
   302  <p>
   303  Open <code>test.txt</code> file in your editor, and save the string "Hello world" (without quotes)
   304  in it.
   305  </p>
   306  
   307  <pre>
   308  $ go build wiki.go
   309  $ ./wiki
   310  </pre>
   311  
   312  <p>
   313  (If you're using Windows you must type "<code>wiki</code>" without the
   314  "<code>./</code>" to run the program.)
   315  </p>
   316  
   317  <p>
   318  With this web server running, a visit to <code><a
   319  href="http://localhost:8080/view/test">http://localhost:8080/view/test</a></code>
   320  should show a page titled "test" containing the words "Hello world".
   321  </p>
   322  
   323  <h2>Editing Pages</h2>
   324  
   325  <p>
   326  A wiki is not a wiki without the ability to edit pages. Let's create two new
   327  handlers: one named <code>editHandler</code> to display an 'edit page' form,
   328  and the other named <code>saveHandler</code> to save the data entered via the
   329  form.
   330  </p>
   331  
   332  <p>
   333  First, we add them to <code>main()</code>:
   334  </p>
   335  
   336  {{code "doc/articles/wiki/final-noclosure.go" `/^func main/` `/^}/`}}
   337  
   338  <p>
   339  The function <code>editHandler</code> loads the page
   340  (or, if it doesn't exist, create an empty <code>Page</code> struct),
   341  and displays an HTML form.
   342  </p>
   343  
   344  {{code "doc/articles/wiki/notemplate.go" `/^func editHandler/` `/^}/`}}
   345  
   346  <p>
   347  This function will work fine, but all that hard-coded HTML is ugly.
   348  Of course, there is a better way.
   349  </p>
   350  
   351  <h2>The <code>html/template</code> package</h2>
   352  
   353  <p>
   354  The <code>html/template</code> package is part of the Go standard library.
   355  We can use <code>html/template</code> to keep the HTML in a separate file,
   356  allowing us to change the layout of our edit page without modifying the
   357  underlying Go code.
   358  </p>
   359  
   360  <p>
   361  First, we must add <code>html/template</code> to the list of imports. We
   362  also won't be using <code>fmt</code> anymore, so we have to remove that.
   363  </p>
   364  
   365  <pre>
   366  import (
   367  	<b>"html/template"</b>
   368  	"io/ioutil"
   369  	"net/http"
   370  )
   371  </pre>
   372  
   373  <p>
   374  Let's create a template file containing the HTML form.
   375  Open a new file named <code>edit.html</code>, and add the following lines:
   376  </p>
   377  
   378  {{code "doc/articles/wiki/edit.html"}}
   379  
   380  <p>
   381  Modify <code>editHandler</code> to use the template, instead of the hard-coded
   382  HTML:
   383  </p>
   384  
   385  {{code "doc/articles/wiki/final-noerror.go" `/^func editHandler/` `/^}/`}}
   386  
   387  <p>
   388  The function <code>template.ParseFiles</code> will read the contents of
   389  <code>edit.html</code> and return a <code>*template.Template</code>.
   390  </p>
   391  
   392  <p>
   393  The method <code>t.Execute</code> executes the template, writing the
   394  generated HTML to the <code>http.ResponseWriter</code>.
   395  The <code>.Title</code> and <code>.Body</code> dotted identifiers refer to
   396  <code>p.Title</code> and <code>p.Body</code>.
   397  </p>
   398  
   399  <p>
   400  Template directives are enclosed in double curly braces.
   401  The <code>printf "%s" .Body</code> instruction is a function call
   402  that outputs <code>.Body</code> as a string instead of a stream of bytes,
   403  the same as a call to <code>fmt.Printf</code>.
   404  The <code>html/template</code> package helps guarantee that only safe and
   405  correct-looking HTML is generated by template actions. For instance, it
   406  automatically escapes any greater than sign (<code>&gt;</code>), replacing it
   407  with <code>&amp;gt;</code>, to make sure user data does not corrupt the form
   408  HTML.
   409  </p>
   410  
   411  <p>
   412  Since we're working with templates now, let's create a template for our
   413  <code>viewHandler</code> called <code>view.html</code>:
   414  </p>
   415  
   416  {{code "doc/articles/wiki/view.html"}}
   417  
   418  <p>
   419  Modify <code>viewHandler</code> accordingly:
   420  </p>
   421  
   422  {{code "doc/articles/wiki/final-noerror.go" `/^func viewHandler/` `/^}/`}}
   423  
   424  <p>
   425  Notice that we've used almost exactly the same templating code in both
   426  handlers. Let's remove this duplication by moving the templating code
   427  to its own function:
   428  </p>
   429  
   430  {{code "doc/articles/wiki/final-template.go" `/^func renderTemplate/` `/^}/`}}
   431  
   432  <p>
   433  And modify the handlers to use that function:
   434  </p>
   435  
   436  {{code "doc/articles/wiki/final-template.go" `/^func viewHandler/` `/^}/`}}
   437  {{code "doc/articles/wiki/final-template.go" `/^func editHandler/` `/^}/`}}
   438  
   439  <p>
   440  If we comment out the registration of our unimplemented save handler in
   441  <code>main</code>, we can once again build and test our program.
   442  <a href="part3.go">Click here to view the code we've written so far.</a>
   443  </p>
   444  
   445  <h2>Handling non-existent pages</h2>
   446  
   447  <p>
   448  What if you visit <a href="http://localhost:8080/view/APageThatDoesntExist">
   449  <code>/view/APageThatDoesntExist</code></a>? You'll see a page containing
   450  HTML. This is because it ignores the error return value from
   451  <code>loadPage</code> and continues to try and fill out the template
   452  with no data. Instead, if the requested Page doesn't exist, it should
   453  redirect the client to the edit Page so the content may be created:
   454  </p>
   455  
   456  {{code "doc/articles/wiki/part3-errorhandling.go" `/^func viewHandler/` `/^}/`}}
   457  
   458  <p>
   459  The <code>http.Redirect</code> function adds an HTTP status code of
   460  <code>http.StatusFound</code> (302) and a <code>Location</code>
   461  header to the HTTP response.
   462  </p>
   463  
   464  <h2>Saving Pages</h2>
   465  
   466  <p>
   467  The function <code>saveHandler</code> will handle the submission of forms
   468  located on the edit pages. After uncommenting the related line in
   469  <code>main</code>, let's implement the handler:
   470  </p>
   471  
   472  {{code "doc/articles/wiki/final-template.go" `/^func saveHandler/` `/^}/`}}
   473  
   474  <p>
   475  The page title (provided in the URL) and the form's only field,
   476  <code>Body</code>, are stored in a new <code>Page</code>.
   477  The <code>save()</code> method is then called to write the data to a file,
   478  and the client is redirected to the <code>/view/</code> page.
   479  </p>
   480  
   481  <p>
   482  The value returned by <code>FormValue</code> is of type <code>string</code>.
   483  We must convert that value to <code>[]byte</code> before it will fit into
   484  the <code>Page</code> struct. We use <code>[]byte(body)</code> to perform
   485  the conversion.
   486  </p>
   487  
   488  <h2>Error handling</h2>
   489  
   490  <p>
   491  There are several places in our program where errors are being ignored.  This
   492  is bad practice, not least because when an error does occur the program will
   493  have unintended behavior. A better solution is to handle the errors and return
   494  an error message to the user. That way if something does go wrong, the server
   495  will function exactly how we want and the user can be notified.
   496  </p>
   497  
   498  <p>
   499  First, let's handle the errors in <code>renderTemplate</code>:
   500  </p>
   501  
   502  {{code "doc/articles/wiki/final-parsetemplate.go" `/^func renderTemplate/` `/^}/`}}
   503  
   504  <p>
   505  The <code>http.Error</code> function sends a specified HTTP response code
   506  (in this case "Internal Server Error") and error message.
   507  Already the decision to put this in a separate function is paying off.
   508  </p>
   509  
   510  <p>
   511  Now let's fix up <code>saveHandler</code>:
   512  </p>
   513  
   514  {{code "doc/articles/wiki/part3-errorhandling.go" `/^func saveHandler/` `/^}/`}}
   515  
   516  <p>
   517  Any errors that occur during <code>p.save()</code> will be reported
   518  to the user.
   519  </p>
   520  
   521  <h2>Template caching</h2>
   522  
   523  <p>
   524  There is an inefficiency in this code: <code>renderTemplate</code> calls
   525  <code>ParseFiles</code> every time a page is rendered.
   526  A better approach would be to call <code>ParseFiles</code> once at program
   527  initialization, parsing all templates into a single <code>*Template</code>.
   528  Then we can use the
   529  <a href="/pkg/html/template/#Template.ExecuteTemplate"><code>ExecuteTemplate</code></a>
   530  method to render a specific template.
   531  </p>
   532  
   533  <p>
   534  First we create a global variable named <code>templates</code>, and initialize
   535  it with <code>ParseFiles</code>.
   536  </p>
   537  
   538  {{code "doc/articles/wiki/final.go" `/var templates/`}}
   539  
   540  <p>
   541  The function <code>template.Must</code> is a convenience wrapper that panics
   542  when passed a non-nil <code>error</code> value, and otherwise returns the
   543  <code>*Template</code> unaltered. A panic is appropriate here; if the templates
   544  can't be loaded the only sensible thing to do is exit the program.
   545  </p>
   546  
   547  <p>
   548  The <code>ParseFiles</code> function takes any number of string arguments that
   549  identify our template files, and parses those files into templates that are
   550  named after the base file name. If we were to add more templates to our
   551  program, we would add their names to the <code>ParseFiles</code> call's
   552  arguments.
   553  </p>
   554  
   555  <p>
   556  We then modify the <code>renderTemplate</code> function to call the
   557  <code>templates.ExecuteTemplate</code> method with the name of the appropriate
   558  template:
   559  </p>
   560  
   561  {{code "doc/articles/wiki/final.go" `/func renderTemplate/` `/^}/`}}
   562  
   563  <p>
   564  Note that the template name is the template file name, so we must
   565  append <code>".html"</code> to the <code>tmpl</code> argument.
   566  </p>
   567  
   568  <h2>Validation</h2>
   569  
   570  <p>
   571  As you may have observed, this program has a serious security flaw: a user
   572  can supply an arbitrary path to be read/written on the server. To mitigate
   573  this, we can write a function to validate the title with a regular expression.
   574  </p>
   575  
   576  <p>
   577  First, add <code>"regexp"</code> to the <code>import</code> list.
   578  Then we can create a global variable to store our validation 
   579  expression:
   580  </p>
   581  
   582  {{code "doc/articles/wiki/final-noclosure.go" `/^var validPath/`}}
   583  
   584  <p>
   585  The function <code>regexp.MustCompile</code> will parse and compile the
   586  regular expression, and return a <code>regexp.Regexp</code>.
   587  <code>MustCompile</code> is distinct from <code>Compile</code> in that it will
   588  panic if the expression compilation fails, while <code>Compile</code> returns
   589  an <code>error</code> as a second parameter.
   590  </p>
   591  
   592  <p>
   593  Now, let's write a function that uses the <code>validPath</code>
   594  expression to validate path and extract the page title:
   595  </p>
   596  
   597  {{code "doc/articles/wiki/final-noclosure.go" `/func getTitle/` `/^}/`}}
   598  
   599  <p>
   600  If the title is valid, it will be returned along with a <code>nil</code>
   601  error value. If the title is invalid, the function will write a
   602  "404 Not Found" error to the HTTP connection, and return an error to the
   603  handler. To create a new error, we have to import the <code>errors</code>
   604  package.
   605  </p>
   606  
   607  <p>
   608  Let's put a call to <code>getTitle</code> in each of the handlers:
   609  </p>
   610  
   611  {{code "doc/articles/wiki/final-noclosure.go" `/^func viewHandler/` `/^}/`}}
   612  {{code "doc/articles/wiki/final-noclosure.go" `/^func editHandler/` `/^}/`}}
   613  {{code "doc/articles/wiki/final-noclosure.go" `/^func saveHandler/` `/^}/`}}
   614  
   615  <h2>Introducing Function Literals and Closures</h2>
   616  
   617  <p>
   618  Catching the error condition in each handler introduces a lot of repeated code.
   619  What if we could wrap each of the handlers in a function that does this
   620  validation and error checking? Go's
   621  <a href="/ref/spec#Function_literals">function
   622  literals</a> provide a powerful means of abstracting functionality
   623  that can help us here.
   624  </p>
   625  
   626  <p>
   627  First, we re-write the function definition of each of the handlers to accept
   628  a title string:
   629  </p>
   630  
   631  <pre>
   632  func viewHandler(w http.ResponseWriter, r *http.Request, title string)
   633  func editHandler(w http.ResponseWriter, r *http.Request, title string)
   634  func saveHandler(w http.ResponseWriter, r *http.Request, title string)
   635  </pre>
   636  
   637  <p>
   638  Now let's define a wrapper function that <i>takes a function of the above
   639  type</i>, and returns a function of type <code>http.HandlerFunc</code>
   640  (suitable to be passed to the function <code>http.HandleFunc</code>):
   641  </p>
   642  
   643  <pre>
   644  func makeHandler(fn func (http.ResponseWriter, *http.Request, string)) http.HandlerFunc {
   645  	return func(w http.ResponseWriter, r *http.Request) {
   646  		// Here we will extract the page title from the Request,
   647  		// and call the provided handler 'fn'
   648  	}
   649  }
   650  </pre>
   651  
   652  <p>
   653  The returned function is called a closure because it encloses values defined
   654  outside of it. In this case, the variable <code>fn</code> (the single argument
   655  to <code>makeHandler</code>) is enclosed by the closure. The variable
   656  <code>fn</code> will be one of our save, edit, or view handlers.
   657  </p>
   658  
   659  <p>
   660  Now we can take the code from <code>getTitle</code> and use it here
   661  (with some minor modifications):
   662  </p>
   663  
   664  {{code "doc/articles/wiki/final.go" `/func makeHandler/` `/^}/`}}
   665  
   666  <p>
   667  The closure returned by <code>makeHandler</code> is a function that takes
   668  an <code>http.ResponseWriter</code> and <code>http.Request</code> (in other
   669  words, an <code>http.HandlerFunc</code>).
   670  The closure extracts the <code>title</code> from the request path, and
   671  validates it with the <code>TitleValidator</code> regexp. If the
   672  <code>title</code> is invalid, an error will be written to the
   673  <code>ResponseWriter</code> using the <code>http.NotFound</code> function.
   674  If the <code>title</code> is valid, the enclosed handler function
   675  <code>fn</code> will be called with the <code>ResponseWriter</code>,
   676  <code>Request</code>, and <code>title</code> as arguments.
   677  </p>
   678  
   679  <p>
   680  Now we can wrap the handler functions with <code>makeHandler</code> in
   681  <code>main</code>, before they are registered with the <code>http</code>
   682  package:
   683  </p>
   684  
   685  {{code "doc/articles/wiki/final.go" `/func main/` `/^}/`}}
   686  
   687  <p>
   688  Finally we remove the calls to <code>getTitle</code> from the handler functions,
   689  making them much simpler:
   690  </p>
   691  
   692  {{code "doc/articles/wiki/final.go" `/^func viewHandler/` `/^}/`}}
   693  {{code "doc/articles/wiki/final.go" `/^func editHandler/` `/^}/`}}
   694  {{code "doc/articles/wiki/final.go" `/^func saveHandler/` `/^}/`}}
   695  
   696  <h2>Try it out!</h2>
   697  
   698  <p>
   699  <a href="final.go">Click here to view the final code listing.</a>
   700  </p>
   701  
   702  <p>
   703  Recompile the code, and run the app:
   704  </p>
   705  
   706  <pre>
   707  $ go build wiki.go
   708  $ ./wiki
   709  </pre>
   710  
   711  <p>
   712  Visiting <a href="http://localhost:8080/view/ANewPage">http://localhost:8080/view/ANewPage</a>
   713  should present you with the page edit form. You should then be able to
   714  enter some text, click 'Save', and be redirected to the newly created page.
   715  </p>
   716  
   717  <h2>Other tasks</h2>
   718  
   719  <p>
   720  Here are some simple tasks you might want to tackle on your own:
   721  </p>
   722  
   723  <ul>
   724  <li>Store templates in <code>tmpl/</code> and page data in <code>data/</code>.
   725  <li>Add a handler to make the web root redirect to
   726  	<code>/view/FrontPage</code>.</li>
   727  <li>Spruce up the page templates by making them valid HTML and adding some
   728  	CSS rules.</li>
   729  <li>Implement inter-page linking by converting instances of
   730  	<code>[PageName]</code> to <br>
   731  	<code>&lt;a href="/view/PageName"&gt;PageName&lt;/a&gt;</code>.
   732  	(hint: you could use <code>regexp.ReplaceAllFunc</code> to do this)
   733  	</li>
   734  </ul>