Let's wrap this up, Ada
We've seen how to use directives in general, and how to use interpreters to make our own parameter directives, and even how to make our own interpreters. Our closing example will be one that you've had with you all along: the default Unfiltered giter8 template.
Setting up the Template
If you don't have the template project already, skip @ref:back to the beginning and follow the directions up until the Consoled section.
Instead of entering a Scala console this time, we want to examine and use the Scala sources included in the project. Go ahead and compile and run them:
The main class in the project will start an HTTP server on some available port, and it will attempt to open the root document on that server in your default browser. If you see a big ugly form, you're all set.
Understanding the Source
Take a look at the source for the server, located here:
You should be able to understand most of what's happening, but there are a few things worth mentioning. Unlike previous examples in this chapter, this is a web server intended for browser clients. Our output is HTML and our input for the POST is a form serialized by the browser.
view function is defined for displaying the page in both
its initial, error, and success states. The function takes a map of
parameters so that it can serve back the form inputs exactly as they
were submitted, without being affected by any interpreters. We can get
this separately from our parameter directives, using the trusty old
@@@ note Since we're just calling out snippets of the code, you won't be able to copy and paste these into a console as you can with most sections of this documentation. Feel free to play around with the template project source though, that's what it's there for. @@@
Also worth noting is that we defined our
BadParam case class inside
the match expression, since it needs a reference to
params to build
its error response. Another option would have been to take the
params as a constructor parameter for the class.
Finally, since we're dealing with user input via a serialized form rather than a programmatic web service, our expectations for errors are different. An "empty" field in the form is still submitted as a parameter -- an empty string. Since this will be a common user error, we should handle it much like we would if the parameter were not submitted at all.
But of course, we still need to define a
required function since it
is possible that some client will fail to submit a parameter.
Finally, in this case the code keeps the logic of the conditional interpreter separate from the implementation, which is inline.
This is just to show the variety of what's possible, it's up to you to decide how to organize and apply your own interpreters. Good luck, and don't be shy about contributing back interpreters of standard library types back into the Unfiltered directives source!