chap-lift_architecture.lyx

#LyX 1.6.7 created this file. For more info see http://www.lyx.org/
\lyxformat 345
\begin_document
\begin_header
\textclass book
\use_default_options false
\language english
\inputencoding auto
\font_roman default
\font_sans default
\font_typewriter default
\font_default_family default
\font_sc false
\font_osf false
\font_sf_scale 100
\font_tt_scale 100

\graphics default
\paperfontsize default
\spacing single
\use_hyperref false
\papersize default
\use_geometry false
\use_amsmath 1
\use_esint 1
\cite_engine basic
\use_bibtopic false
\paperorientation portrait
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\defskip medskip
\quotes_language english
\papercolumns 1
\papersides 1
\paperpagestyle default
\tracking_changes false
\output_changes false
\author "" 
\author "" 
\end_header

\begin_body

\begin_layout Chapter
Lift Fundamentals
\begin_inset CommandInset label
LatexCommand label
name "cha:Lift-Architecture"

\end_inset


\end_layout

\begin_layout Standard
In this chapter we will cover some of the fundamental aspects of writing
 a lift application, including the architecture of the Lift library and
 how it processes requests.
\end_layout

\begin_layout Section
Entry into Lift
\begin_inset CommandInset label
LatexCommand label
name "sec:Entry-into-Lift"

\end_inset


\end_layout

\begin_layout Standard
The first step in Lift's request processing is intercepting the HTTP request.
 Originally, Lift used a 
\family typewriter
java.servlet.Servlet
\family default
 instance to process incoming requests.
 This was changed to use a 
\family typewriter
java.servlet.Filter
\family default
 instance
\begin_inset Foot
status open

\begin_layout Plain Layout
You can see the discussion on the Lift mailing list that led to this change
 here: 
\begin_inset Flex URL
status open

\begin_layout Plain Layout

http://tinyurl.com/dy9u9d
\end_layout

\end_inset


\end_layout

\end_inset

 because this allows the container to handle any requests that Lift does
 not (in particular, static content).
 The filter acts as a thin wrapper on top of the existing 
\family typewriter
LiftServlet
\family default
 (which still does all of the work), so don't be confused when you look
 at the Lift API and see both classes (
\family typewriter
LiftFilter
\family default
 and 
\family typewriter
LiftServlet
\family default
).
 The main thing to remember is that your 
\family typewriter
web.xml
\family default

\begin_inset Index
status open

\begin_layout Plain Layout
web.xml
\end_layout

\end_inset

 should specify the filter and not the servlet, as shown in Listing 
\begin_inset CommandInset ref
LatexCommand ref
reference "lst:LiftFilter-setup-in-web.xml"

\end_inset

.
\end_layout

\begin_layout Standard
\begin_inset listings
lstparams "language=XML"
inline false
status open

\begin_layout Plain Layout

\begin_inset Caption

\begin_layout Plain Layout
\begin_inset CommandInset label
LatexCommand label
name "lst:LiftFilter-setup-in-web.xml"

\end_inset

LiftFilter Setup in web.xml
\end_layout

\end_inset


\end_layout

\begin_layout Plain Layout

<?xml version="1.0" encoding="ISO-8859-1"?>
\end_layout

\begin_layout Plain Layout

<!DOCTYPE web-app
\end_layout

\begin_layout Plain Layout

  PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
\end_layout

\begin_layout Plain Layout

  "http://java.sun.com/j2ee/dtds/web-app_2_3.dtd">
\end_layout

\begin_layout Plain Layout

<web-app>
\end_layout

\begin_layout Plain Layout

  <filter>
\end_layout

\begin_layout Plain Layout

    <filter-name>LiftFilter</filter-name>
\end_layout

\begin_layout Plain Layout

    <display-name>Lift Filter</display-name>
\end_layout

\begin_layout Plain Layout

    <description>The Filter that intercepts lift calls</description>
\end_layout

\begin_layout Plain Layout

    <filter-class>net.liftweb.http.LiftFilter</filter-class>
\end_layout

\begin_layout Plain Layout

  </filter>      
\end_layout

\begin_layout Plain Layout

  <filter-mapping>
\end_layout

\begin_layout Plain Layout

    <filter-name>LiftFilter</filter-name>
\end_layout

\begin_layout Plain Layout

    <url-pattern>/*</url-pattern>
\end_layout

\begin_layout Plain Layout

  </filter-mapping>
\end_layout

\begin_layout Plain Layout

</web-app>
\end_layout

\end_inset


\end_layout

\begin_layout Standard
A full 
\family typewriter
web.xml
\family default
 example is shown in Section 
\begin_inset CommandInset ref
LatexCommand vref
reference "lst:JPA-web.xml"

\end_inset

.
 In particular, the filter-mapping (lines 13-16) specifies that the Filter
 is responsible for everything.
 When the filter receives the request, it checks a set of rules to see if
 it can handle it.
 If the request is one that Lift handles, it passes it on to an internal
 
\family typewriter
LiftServlet
\family default
 instance for processing; otherwise, it chains the request and allows the
 container to handle it.
\end_layout

\begin_layout Section
Bootstrap
\begin_inset CommandInset label
LatexCommand label
name "sec:Bootstrap"

\end_inset


\begin_inset Index
status open

\begin_layout Plain Layout
Bootstrap
\end_layout

\end_inset


\end_layout

\begin_layout Standard
When Lift starts up an application there are a number of things that you'll
 want to set up before any requests are processed.
 These things include setting up a site Menu (called SiteMap, Chapter 
\begin_inset CommandInset ref
LatexCommand ref
reference "cha:SiteMap"

\end_inset

), URL rewriting (Section 
\begin_inset CommandInset ref
LatexCommand ref
reference "sec:URL-Rewriting"

\end_inset

), custom dispatch (Section 
\begin_inset CommandInset ref
LatexCommand ref
reference "sec:Custom-dispatch-func"

\end_inset

), and classpath search (Section 
\begin_inset CommandInset ref
LatexCommand ref
reference "sub:Class-Resolution"

\end_inset

).
 The Lift servlet looks for the 
\family typewriter
bootstrap.liftweb.Boot
\family default

\begin_inset Index
status open

\begin_layout Plain Layout
Boot
\end_layout

\end_inset

 class and executes the 
\family typewriter
boot
\family default
 method in the class.
 You can also specify your own Boot instance by using the 
\family typewriter
bootloader
\begin_inset Index
status open

\begin_layout Plain Layout
bootloader
\end_layout

\end_inset


\family default
 init param for the 
\family typewriter
LiftFilter
\family default
 as shown in Listing 
\begin_inset CommandInset ref
LatexCommand ref
reference "lst:Overriding-bootloader"

\end_inset


\end_layout

\begin_layout Standard
\begin_inset listings
lstparams "language=XML"
inline false
status open

\begin_layout Plain Layout

\begin_inset Caption

\begin_layout Plain Layout
Overriding the Boot Loader Class
\begin_inset CommandInset label
LatexCommand label
name "lst:Overriding-bootloader"

\end_inset


\end_layout

\end_inset


\end_layout

\begin_layout Plain Layout

<filter>
\end_layout

\begin_layout Plain Layout

  ...
 filter setup here ...
\end_layout

\begin_layout Plain Layout

  <init-param>     
\end_layout

\begin_layout Plain Layout

    <param-name>bootloader</param-name>
\end_layout

\begin_layout Plain Layout

    <param-value>foo.bar.baz.MyBoot</param-value>
\end_layout

\begin_layout Plain Layout

  </init-param> 
\end_layout

\begin_layout Plain Layout

</filter>
\end_layout

\end_inset


\end_layout

\begin_layout Standard
Your custom boot class class must subclass 
\family typewriter
Bootable
\family default

\begin_inset Foot
status open

\begin_layout Plain Layout

\family typewriter
net.liftweb.http.Bootable
\end_layout

\end_inset

 and implement the 
\family typewriter
boot
\family default
 method.
 The 
\family typewriter
boot
\family default
 method will only be run once, so you can place any initialization calls
 for other libraries here as well.
\end_layout

\begin_layout Subsection
Class Resolution
\begin_inset CommandInset label
LatexCommand label
name "sub:Class-Resolution"

\end_inset


\end_layout

\begin_layout Standard
As part of our discussion of the Boot class, it's also important to explain
 how Lift determines where to find classes for Views and Snippet rendering
 when using implicit dispatch (we'll cover this in Section 
\begin_inset CommandInset ref
LatexCommand vref
reference "sub:Implicit-Dispatch-Via"

\end_inset

).
 The 
\family typewriter
LiftRules.addToPackages
\family default
 method tells lift which Scala packages to look in for a given class.
 Lift has implicit extensions to the paths you enter: in particular, if
 you tell Lift to use the 
\family typewriter
com.pocketchangeapp
\family default
 package, Lift will look for View classes (Section ???)under 
\family typewriter
com.pocketchangeapp.view
\family default
 , Comet classes (Section 
\begin_inset CommandInset ref
LatexCommand ref
reference "sec:COMET"

\end_inset

) under 
\family typewriter
com.pocketchange.comet
\family default
, and Snippet classes (Chapter 
\begin_inset CommandInset ref
LatexCommand ref
reference "cha:Snippets"

\end_inset

) under 
\family typewriter
com.pocketchangeapp.snippet
\family default
.
 The 
\family typewriter
addToPackages
\family default
 method should almost always be executed in your Boot class.
 A minimal Boot class would look like:
\end_layout

\begin_layout Standard
\begin_inset listings
inline false
status open

\begin_layout Plain Layout

\begin_inset Caption

\begin_layout Plain Layout
A Minimal Boot Class
\begin_inset CommandInset label
LatexCommand label
name "lst:Minimal-Boot-class"

\end_inset


\end_layout

\end_inset


\end_layout

\begin_layout Plain Layout

class Boot {
\end_layout

\begin_layout Plain Layout

  def boot = {
\end_layout

\begin_layout Plain Layout

    LiftRules.addToPackages("com.pocketchangeapp")
\end_layout

\begin_layout Plain Layout

  }
\end_layout

\begin_layout Plain Layout

}
\end_layout

\end_inset


\end_layout

\begin_layout Section
A Note on Standard Imports
\end_layout

\begin_layout Standard
For the sake of saving space, the following import statements are assumed
 for all example code throughout the rest of the book:
\end_layout

\begin_layout Standard
\begin_inset listings
inline false
status open

\begin_layout Plain Layout

\begin_inset Caption

\begin_layout Plain Layout
Standard Import Statements
\begin_inset CommandInset label
LatexCommand label
name "lst:Standard-import-statements"

\end_inset


\end_layout

\end_inset


\end_layout

\begin_layout Plain Layout

import net.liftweb.common._
\end_layout

\begin_layout Plain Layout

\end_layout

\begin_layout Plain Layout

import net.liftweb.http._
\end_layout

\begin_layout Plain Layout

import S._
\end_layout

\begin_layout Plain Layout

\end_layout

\begin_layout Plain Layout

import net.liftweb.util._
\end_layout

\begin_layout Plain Layout

import Helpers._
\end_layout

\begin_layout Plain Layout

\end_layout

\begin_layout Plain Layout

import scala.xml._
\end_layout

\end_inset


\end_layout

\begin_layout Section
Lift's Main Objects
\end_layout

\begin_layout Standard
Before we dive into Lift's fundamentals, we want to briefly discuss three
 objects you will use heavily in your Lift code.
 We'll be covering these in more detail later in this chapter and in further
 chapters, so feel free to skip ahead if you want more details.
\end_layout

\begin_layout Subsection
S
\begin_inset Index
status open

\begin_layout Plain Layout
S
\end_layout

\end_inset

 object
\begin_inset CommandInset label
LatexCommand label
name "sub:S-object"

\end_inset


\end_layout

\begin_layout Standard
The 
\family typewriter
net.liftweb.http.S
\family default
 object represents the state of the current request (according to David
 Pollak, 
\begin_inset Quotes eld
\end_inset

S
\begin_inset Quotes erd
\end_inset

 is for Stateful).
 As such, it is used to retrieve information about the request and modify
 information that is sent in the response.
 Among other things, it can be used for notices (Section 
\begin_inset CommandInset ref
LatexCommand ref
reference "cha:Message-Handling"

\end_inset

) , cookie management (Section 
\begin_inset CommandInset ref
LatexCommand ref
reference "sec:Cookies"

\end_inset

), localization/internationalization (Chapter 
\begin_inset CommandInset ref
LatexCommand ref
reference "cha:Internationalization"

\end_inset

) and redirection (Section 
\begin_inset CommandInset ref
LatexCommand ref
reference "sec:HTTP-redirects"

\end_inset

).
\end_layout

\begin_layout Subsection
SHtml
\begin_inset Index
status open

\begin_layout Plain Layout
SHtml
\end_layout

\end_inset


\begin_inset CommandInset label
LatexCommand label
name "sub:SHtml"

\end_inset


\end_layout

\begin_layout Standard
The 
\family typewriter
net.liftweb.http.SHtml
\family default
 object's main purpose is to define HTML generation functions, particularly
 those having to do with form elements.
 We cover forms in detail in Chapter 
\begin_inset CommandInset ref
LatexCommand ref
reference "cha:Forms-in-Lift"

\end_inset

).
 In addition to normal form elements, SHtml defines functions for AJAX and
 JSON form elements (Chapters 
\begin_inset CommandInset ref
LatexCommand ref
reference "cha:AJAX-and-COMET"

\end_inset

 and 
\begin_inset CommandInset ref
LatexCommand ref
reference "cha:Lift-and-Javascript"

\end_inset

, respectively).
\end_layout

\begin_layout Subsection
LiftRules
\begin_inset Index
status open

\begin_layout Plain Layout
LiftRules
\end_layout

\end_inset


\end_layout

\begin_layout Standard
The 
\family typewriter
net.liftweb.http.LiftRules
\family default
 object is where the vast majority of Lift's global configuration is handled.
 Almost everything that is configurable about Lift is set up based on variables
 in 
\family typewriter
LiftRules
\family default
.
 Because LiftRules spans such a diverse range of functionality, we won't
 be covering 
\family typewriter
LiftRules
\family default
 directly, but as we discuss each Lift mechanism we'll touch on the 
\family typewriter
LiftRules
\family default
 variables and methods related to the configuration of that mechanism.
\end_layout

\begin_layout Section
The Rendering Process
\begin_inset CommandInset label
LatexCommand label
name "sec:The-Rendering-Process"

\end_inset


\end_layout

\begin_layout Standard
The rest of this chapter, as well as the next few chapters, are dedicated
 to the stages of rendering in Lift.
 We'll start here by giving a brief overview of the processes by which Lift
 transforms a request into a response
\begin_inset Index
status open

\begin_layout Plain Layout
rendering pipeline
\end_layout

\end_inset

.
 We're only going to touch on the major points here, although the steps
 we do discuss will be in the order that Lift performs them.
 A much more detailed tour of the pipeline is given in Section 
\begin_inset CommandInset ref
LatexCommand ref
reference "sec:Request/Response-Lifecycle"

\end_inset

.
 Starting from the initial invocation on a request, Lift will:
\end_layout

\begin_layout Enumerate
Perform any configured URL rewriting.
 This is covered in Section 
\begin_inset CommandInset ref
LatexCommand ref
reference "sec:URL-Rewriting"

\end_inset

.
\end_layout

\begin_layout Enumerate
Execute any matching custom dispatch functions.
 This is split into both stateless and stateful dispatch, and will be covered
 in more detail in Section 
\begin_inset CommandInset ref
LatexCommand ref
reference "sec:Custom-dispatch-func"

\end_inset

.
\end_layout

\begin_layout Enumerate
Perform automatic processing of Comet and AJAX requests (Chapter 
\begin_inset CommandInset ref
LatexCommand ref
reference "cha:AJAX-and-COMET"

\end_inset

).
\end_layout

\begin_layout Enumerate
Perform SiteMap setup and matching.
 SiteMap, covered in Chapter 
\begin_inset CommandInset ref
LatexCommand ref
reference "cha:SiteMap"

\end_inset

, not only provides a nice site-wide menu system, but can also perform security
 control, URL rewrite, and other custom functionality.
\end_layout

\begin_layout Enumerate
Locate the template XHTML to use for the request.
 This is handled via three mechanisms:
\end_layout

\begin_deeper
\begin_layout Enumerate
Checking the 
\family typewriter
LiftRules.viewDispatch
\begin_inset Index
status open

\begin_layout Plain Layout
viewDispatch
\end_layout

\end_inset


\begin_inset Index
status open

\begin_layout Plain Layout
Views ! Explicit dispatch
\end_layout

\end_inset


\family default
 
\family typewriter
RulesSeq
\family default
 to see if any custom dispatch rules have been defined.
 We cover custom view dispatch in Section 
\begin_inset CommandInset ref
LatexCommand vref
reference "sec:Request/Response-Lifecycle"

\end_inset

.
\end_layout

\begin_layout Enumerate
If there is no matching 
\family typewriter
viewDispatch
\family default
, locate a template
\begin_inset Index
status open

\begin_layout Plain Layout
template
\end_layout

\end_inset

 file that matches and use it.
 We'll cover templates, and how they're located, in Section 
\begin_inset CommandInset ref
LatexCommand ref
reference "sec:Templates"

\end_inset

.
\end_layout

\begin_layout Enumerate
If no templates files can be located, attempting to locate a view
\begin_inset Index
status open

\begin_layout Plain Layout
Views
\end_layout

\end_inset

 based on implicit dispatch.
 We'll cover views in Section 
\begin_inset CommandInset ref
LatexCommand ref
reference "sec:Views"

\end_inset

.
\end_layout

\end_deeper
\begin_layout Enumerate
Process the template, including embedding of other templates (Section 
\begin_inset CommandInset ref
LatexCommand ref
reference "sub:embed-tag"

\end_inset

), merging 
\family typewriter
<head/>
\family default
 elements from composited templates (Section 
\begin_inset CommandInset ref
LatexCommand ref
reference "sec:Head-Merge"

\end_inset

), and executing snippet functions (Chapter 
\begin_inset CommandInset ref
LatexCommand ref
reference "cha:Snippets"

\end_inset

).
\end_layout

\begin_layout Standard
The rest of this chapter will be devoted in part to the early stages of
 the rendering pipeline, as well as some notes on some general functionality
 in Lift like redirects
\begin_inset Index
status open

\begin_layout Plain Layout
redirect
\end_layout

\end_inset

.
\end_layout

\begin_layout Section
Notices, Warnings, and Error Messages
\begin_inset CommandInset label
LatexCommand label
name "sub:Notices/Warnings/Errors-messages"

\end_inset


\end_layout

\begin_layout Standard
Feedback to the user is important.
 The application must be able to notify the user of errors, warn the user
 of potential problems, and notify the user when system status changes.
 Lift provides a unified model for such messages that can be used for static
 pages as well as for AJAX and Comet calls.
 We cover messaging support in Appendix 
\begin_inset CommandInset ref
LatexCommand ref
reference "cha:Message-Handling"

\end_inset

.
\end_layout

\begin_layout Section
URL Rewriting 
\begin_inset CommandInset label
LatexCommand label
name "sec:URL-Rewriting"

\end_inset


\end_layout

\begin_layout Standard
\begin_inset Note Note
status open

\begin_layout Plain Layout
In 2.0 this bifurcates into stateful vs stateless rewrite, so we need to
 discuss both
\end_layout

\end_inset

Now that we've gone over Templates, Views, Snippets, and how requests are
 dispatched to a Class.method, we can discuss how to intercept requests and
 handle them the way we want to.
 URL rewriting
\begin_inset Index
status open

\begin_layout Plain Layout
rewriting
\end_layout

\end_inset


\begin_inset Index
status open

\begin_layout Plain Layout
URL rewriting
\end_layout

\end_inset

 is the mechanism that allows you to modify the incoming request so that
 it dispatches to a different URL.
 It can be used, among other things, to allow you to:
\end_layout

\begin_layout Itemize
Use user-friendly, bookmarkable URLs like 
\family typewriter
http://www.example.com/budget/2008
\end_layout

\begin_layout Itemize
Use short URLs instead of long, hard to remember ones, similar to 
\begin_inset CommandInset href
LatexCommand href
target "http://tinyurl.com"

\end_inset


\end_layout

\begin_layout Itemize
Use portions of the URL to determine how a particular snippet or view responds.
 For example, you could make it so that a user's profile is displayed via
 a URL such as
\begin_inset Newline linebreak
\end_inset


\family typewriter
http://someplace.com/user/derek
\family default
 instead of having the username sent as part of a query string.
\end_layout

\begin_layout Standard
The mechanism is fairly simple to set up.
 We need to write a partial function from a RewriteRequest to a RewriteResponse
 to determine if and how we want to rewrite particular requests.
 Once we have the partial function, we modify the 
\family typewriter
LiftRules.rewrite
\family default
 configuration to hook into Lift's processing chain.
 The simplest way to write a partial function is with Scala's match statement,
 which will allow us to selectively match on some or all of the request
 information.
 (Recall that for a partial function, the matches do not have to be exhaustive.
 In the instance that no RewriteRequest matches, no RewriteResponse will
 be generated.) It is also important to understand that when the rewrite
 functions run, the Lift session has not yet been created.
 This means that you generally can't set or access properties in the S object.
 RewriteRequest is a 
\family typewriter
case
\family default
 object that contains three items: the parsed path, the request type and
 the original HttpServletRequest
\begin_inset Index
status collapsed

\begin_layout Plain Layout
HttpServletRequest
\end_layout

\end_inset

 object.
 (If you are not familiar with case classes, you may wish to review the
 Scala documentation for them.
 Adding the 
\family typewriter
case
\family default
 modifier to a class results in some nice syntactic conveniences.)
\end_layout

\begin_layout Standard
The parsed path of the request is in a ParsePath
\begin_inset Index
status collapsed

\begin_layout Plain Layout
ParsePath
\end_layout

\end_inset

 
\family typewriter
case
\family default
 class instance.
 The ParsePath class contains
\end_layout

\begin_layout Enumerate
The parsed path as a List[String]
\end_layout

\begin_layout Enumerate
The suffix of the request (i.e.
 
\begin_inset Quotes eld
\end_inset

html
\begin_inset Quotes erd
\end_inset

, 
\begin_inset Quotes eld
\end_inset

xml
\begin_inset Quotes erd
\end_inset

, etc)
\end_layout

\begin_layout Enumerate
Whether this path is root-relative path.
 If true, then it will start with /<context-path>, followed by the rest
 of the path.
 For example, if your application is deployed on the app context path (
\begin_inset Quotes eld
\end_inset

/app
\begin_inset Quotes erd
\end_inset

) and we want to reference the file <webapp-folder>/pages/index.html, then
 the root-relative path will be /app/pages/index.html.
 
\end_layout

\begin_layout Enumerate
Whether the path ends in a slash (
\begin_inset Quotes eld
\end_inset

/
\begin_inset Quotes erd
\end_inset

)
\end_layout

\begin_layout Standard
The latter three properties are useful only in specific circumstances, but
 the parsed path is what lets us work magic.
 The path of the request is defined as the parts of the URI between the
 context path and the query string.
 The following table shows examples of parsed paths for a Lift application
 under the 
\begin_inset Quotes eld
\end_inset

myapp
\begin_inset Quotes erd
\end_inset

 context path:
\end_layout

\begin_layout Standard
\align center
\begin_inset Tabular
<lyxtabular version="3" rows="4" columns="2">
<features>
<column alignment="left" valignment="top" width="0">
<column alignment="left" valignment="top" width="0">
<row>
<cell alignment="center" valignment="top" topline="true" bottomline="true" leftline="true" usebox="none">
\begin_inset Text

\begin_layout Plain Layout

\series bold
\size footnotesize
Requested URL
\end_layout

\end_inset
</cell>
<cell alignment="center" valignment="top" topline="true" bottomline="true" leftline="true" rightline="true" usebox="none">
\begin_inset Text

\begin_layout Plain Layout

\series bold
\size footnotesize
Parsed Path
\end_layout

\end_inset
</cell>
</row>
<row>
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text

\begin_layout Plain Layout

\size footnotesize
http://foo.com/myapp/home?test_this=true
\end_layout

\end_inset
</cell>
<cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
\begin_inset Text

\begin_layout Plain Layout

\size footnotesize
List[String](
\begin_inset Quotes eld
\end_inset

home
\begin_inset Quotes erd
\end_inset

)
\end_layout

\end_inset
</cell>
</row>
<row>
<cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
\begin_inset Text

\begin_layout Plain Layout

\size footnotesize
http://foo.com/myapp/user/derek
\end_layout

\end_inset
</cell>
<cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
\begin_inset Text

\begin_layout Plain Layout

\size footnotesize
List[String](
\begin_inset Quotes eld
\end_inset

user
\begin_inset Quotes erd
\end_inset

, 
\begin_inset Quotes eld
\end_inset

derek
\begin_inset Quotes erd
\end_inset

)
\end_layout

\end_inset
</cell>
</row>
<row>
<cell alignment="center" valignment="top" topline="true" bottomline="true" leftline="true" usebox="none">
\begin_inset Text

\begin_layout Plain Layout

\size footnotesize
http://foo.com/myapp/view/item/14592
\end_layout

\end_inset
</cell>
<cell alignment="center" valignment="top" topline="true" bottomline="true" leftline="true" rightline="true" usebox="none">
\begin_inset Text

\begin_layout Plain Layout

\size footnotesize
List[String](
\begin_inset Quotes eld
\end_inset

view
\begin_inset Quotes erd
\end_inset

,
\begin_inset Quotes erd
\end_inset

item
\begin_inset Quotes erd
\end_inset

,
\begin_inset Quotes erd
\end_inset

14592
\begin_inset Quotes erd
\end_inset

)
\end_layout

\end_inset
</cell>
</row>
</lyxtabular>

\end_inset


\end_layout

\begin_layout Standard
The RequestType maps to one of the five HTTP methods: GET, POST, HEAD, PUT
 and DELETE.
 These are represented by the corresponding GetRequest, PostRequest, etc.
 case classes, with an UnknownRequest case class to cover anything strange.
\end_layout

\begin_layout Standard
The flexibility of Scala's matching system is what really makes this powerful.
 In particular, when matching on Lists, we can match parts of the path and
 capture others.
 For example, suppose we'd like to rewrite the 
\family typewriter
/account/<account name>
\family default
 path so that it's handled by the 
\family typewriter
/viewAcct
\family default
 template as shown in Listing 
\begin_inset CommandInset ref
LatexCommand ref
reference "lst:Simple-rewrite-example"

\end_inset

.
 In this case we provide two rewrites.
 The first matches /account/<account name> and redirects it to the /viewAcct
 template, passing the acctName as a 
\begin_inset Quotes eld
\end_inset

name
\begin_inset Quotes erd
\end_inset

 parameter.
 The second matches /account/<account name>/<tag>, redirecting it to /viewAcct
 as before, but passing both the 
\begin_inset Quotes eld
\end_inset

name
\begin_inset Quotes erd
\end_inset

 and a 
\begin_inset Quotes eld
\end_inset

tag
\begin_inset Quotes erd
\end_inset

 parameter with the acctName and tag matches from the ParsePath, respectively.
 Remember that the underscore (_) in these matching statements means that
 we don't care what that parameter is, i.e., match anything in that spot.
\end_layout

\begin_layout Standard
\begin_inset listings
inline false
status open

\begin_layout Plain Layout

\begin_inset Caption

\begin_layout Plain Layout
A Simple Rewrite Example
\begin_inset CommandInset label
LatexCommand label
name "lst:Simple-rewrite-example"

\end_inset


\end_layout

\end_inset


\end_layout

\begin_layout Plain Layout

LiftRules.rewrite.append {
\end_layout

\begin_layout Plain Layout

  case RewriteRequest(
\end_layout

\begin_layout Plain Layout

         ParsePath(List("account",acctName),_,_,_),_,_) => 
\end_layout

\begin_layout Plain Layout

         RewriteResponse("viewAcct" :: Nil, Map("name" -> acctName))
\end_layout

\begin_layout Plain Layout

  case RewriteRequest(
\end_layout

\begin_layout Plain Layout

         ParsePath(List("account",acctName, tag),_,_,_),_,_) => 
\end_layout

\begin_layout Plain Layout

         RewriteResponse("viewAcct" :: Nil, Map("name" -> acctName,
\end_layout

\begin_layout Plain Layout

                                                "tag" -> tag)))
\end_layout

\begin_layout Plain Layout

}
\end_layout

\end_inset


\end_layout

\begin_layout Standard
The RewriteResponse
\begin_inset Index
status collapsed

\begin_layout Plain Layout
RewriteResponse
\end_layout

\end_inset

 simply contains the new path to follow.
 It can also take a Map
\begin_inset Index
status collapsed

\begin_layout Plain Layout
Map
\end_layout

\end_inset

 that contains parameters that will be accessible via S.param
\begin_inset Index
status collapsed

\begin_layout Plain Layout
S.param
\end_layout

\end_inset


\begin_inset Index
status collapsed

\begin_layout Plain Layout
S
\end_layout

\end_inset

 in the snippet or view.
 As we stated before, the LiftSession (and therefore most of S) isn't available
 at this time, so the Map is the only way to pass information on to the
 rewritten location.
 
\end_layout

\begin_layout Standard
We can combine the ParsePath matching with the RequestType and HttpServletReques
t to be very specific with our matches.
 For example, if we wanted to support the DELETE HTTP verb for a RESTful
\begin_inset Foot
status open

\begin_layout Plain Layout
\begin_inset ERT
status open

\begin_layout Plain Layout


\backslash
url{http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm}
\end_layout

\end_inset


\end_layout

\end_inset


\begin_inset Index
status open

\begin_layout Plain Layout
RESTful
\end_layout

\end_inset

 interface through an existing template, we could redirect as shown in Listing
 
\begin_inset CommandInset ref
LatexCommand ref
reference "lst:Complex-rewrite-example"

\end_inset

.
\end_layout

\begin_layout Standard
\begin_inset listings
inline false
status open

\begin_layout Plain Layout

\begin_inset Caption

\begin_layout Plain Layout
A Complex Rewrite Example
\begin_inset CommandInset label
LatexCommand label
name "lst:Complex-rewrite-example"

\end_inset


\end_layout

\end_inset


\end_layout

\begin_layout Plain Layout

LiftRules.rewrite.append {
\end_layout

\begin_layout Plain Layout

  case RewriteRequest(ParsePath("username" :: Nil, _, _, _),
\end_layout

\begin_layout Plain Layout

                      DeleteRequest,
\end_layout

\begin_layout Plain Layout

                      httpreq) 
\end_layout

\begin_layout Plain Layout

                      if isMgmtSubnet(httpreq.getRemoteHost()) => 
\end_layout

\begin_layout Plain Layout

       RewriteResponse("deleteUser" :: Nil, Map("username" -> username))
\end_layout

\begin_layout Plain Layout

}
\end_layout

\end_inset


\end_layout

\begin_layout Standard
We'll go into more detail about how you can use this in the following sections.
 In particular, SiteMap
\begin_inset Index
status collapsed

\begin_layout Plain Layout
SiteMap
\end_layout

\end_inset

 (Chapter 
\begin_inset CommandInset ref
LatexCommand ref
reference "cha:SiteMap"

\end_inset

) provides a mechanism for doing rewrites combined with menu entries.
\end_layout

\begin_layout Section
Custom Dispatch Functions 
\begin_inset CommandInset label
LatexCommand label
name "sec:Custom-dispatch-func"

\end_inset


\end_layout

\begin_layout Standard
Once the rewriting phase is complete (whether we pass through or are redirected)
, the next phase is to determine whether there should be a custom dispatch
 for the request.
 A custom dispatch allows you to handle a matching request directly by a
 method instead of going through the template lookup system.
 Because it bypasses templating, you're responsible for the full content
 of the response.
 A typical use case would be a web service
\begin_inset Index
status collapsed

\begin_layout Plain Layout
web service
\end_layout

\end_inset

 returning XML or a service to return, say, a generated image or PDF.
 In that sense, the custom dispatch mechanism allows you to write your own
 
\begin_inset Quotes eld
\end_inset

sub-servlets
\begin_inset Quotes erd
\end_inset

 without all the mess of implementing the interface and configuring them
 in web.xml
\begin_inset Index
status collapsed

\begin_layout Plain Layout
web.xml
\end_layout

\end_inset

.
\end_layout

\begin_layout Standard
As with rewriting, custom dispatch is realized via a partial function.
 In this case, it's a function of type 
\family typewriter
PartialFunction[Req,
\begin_inset Formula $()\Rightarrow Box[LiftResponse]$
\end_inset

]
\family default
 that does the work.
 The 
\family typewriter
Req
\family default
 is similar to the 
\family typewriter
RewriteRequest
\family default
 case class: it provides the path as a 
\family typewriter
List[String]
\family default
, the suffix of the request, and the 
\family typewriter
RequestType
\family default
.
 There are three ways that you can set up a custom dispatch function:
\end_layout

\begin_layout Enumerate
Globally, via 
\family typewriter
LiftRules.dispatch
\family default

\begin_inset Index
status open

\begin_layout Plain Layout
LiftRules ! dispatch
\end_layout

\end_inset


\begin_inset Index
status open

\begin_layout Plain Layout
Custom dispatch ! stateful
\end_layout

\end_inset


\end_layout

\begin_layout Enumerate
Globally, via 
\family typewriter
LiftRules.statelessDispatchTable
\family default

\begin_inset Index
status open

\begin_layout Plain Layout
LiftRules ! statelessDispatchTable
\end_layout

\end_inset


\begin_inset Index
status open

\begin_layout Plain Layout
Custom dispatch ! stateless
\end_layout

\end_inset


\end_layout

\begin_layout Enumerate
Per-Session, via 
\family typewriter
S.addHighLevelSessionDispatcher
\family default

\begin_inset Index
status open

\begin_layout Plain Layout
S ! addHighLevelSessionDispatcher
\end_layout

\end_inset


\begin_inset Index
status open

\begin_layout Plain Layout
Custom dispatch ! per-session
\end_layout

\end_inset


\end_layout

\begin_layout Standard
If you attach the dispatch function via 
\family typewriter
LiftRules.dispatch
\family default
 or 
\family typewriter
S.addHighLevelSessionDispatcher
\family default
, then you'll have full access to the 
\family typewriter
S
\family default
 object, 
\family typewriter
SessionVar
\family default
s and 
\family typewriter
LiftSession
\family default
; if you use 
\family typewriter
LiftRules.statelessDispatchTable
\family default
 instead, then these aren't available.
 The result of the dispatch should be a function that returns a 
\family typewriter
Box[LiftResponse]
\family default
.
 If the function returns 
\family typewriter
Empty
\family default
, then Lift returns a 
\begin_inset Quotes eld
\end_inset

404 Not Found
\begin_inset Quotes erd
\end_inset

 response.
\end_layout

\begin_layout Standard
As a concrete example, let's look at returning a generated chart image from
 our application.
 There are several libraries for charting, but we'll take a look at JFreeChart
 in particular.
 First, let's write a method that will chart our account balances by month
 for the last year:
\end_layout

\begin_layout Standard
\begin_inset listings
inline false
status open

\begin_layout Plain Layout

\begin_inset Caption

\begin_layout Plain Layout
A Charting Method
\begin_inset CommandInset label
LatexCommand label
name "lst:Charting-method"

\end_inset


\end_layout

\end_inset


\end_layout

\begin_layout Plain Layout

def chart (endDate : String) : Box[LiftResponse] = {
\end_layout

\begin_layout Plain Layout

  // Query, set up chart, etc...
\end_layout

\begin_layout Plain Layout

  val buffered = balanceChart.createBufferedImage(width,height)
\end_layout

\begin_layout Plain Layout

  val chartImage = ChartUtilities.encodeAsPNG(buffered)
\end_layout

\begin_layout Plain Layout

  // InMemoryResponse is a subclass of LiftResponse
\end_layout

\begin_layout Plain Layout

  // it takes an Array of Bytes, a List[(String,String)] of
\end_layout

\begin_layout Plain Layout

  // headers, a List[Cookie] of Cookies, and an integer
\end_layout

\begin_layout Plain Layout

  // return code (here 200 for HTTP 200: OK)
\end_layout

\begin_layout Plain Layout

  Full(InMemoryResponse(chartImage, 
\end_layout

\begin_layout Plain Layout

                        ("Content-Type" -> "image/png") :: Nil,
\end_layout

\begin_layout Plain Layout

                        Nil,
\end_layout

\begin_layout Plain Layout

                        200))
\end_layout

\begin_layout Plain Layout

}
\end_layout

\end_inset


\end_layout

\begin_layout Standard
Once we've set up the chart, we use the ChartUtilities helper class from
 JFreeChart to encode the chart into a PNG byte array.
 We can then use Lift's InMemoryResponse
\begin_inset Index
status collapsed

\begin_layout Plain Layout
InMemoryResponse
\end_layout

\end_inset

 to pass the encoded data back to the client with the appropriate Content-Type
\begin_inset Index
status collapsed

\begin_layout Plain Layout
Type
\end_layout

\end_inset

 header.
 Now we just need to hook the request into the dispatch table from the Boot
 class as shown in Listing 
\begin_inset CommandInset ref
LatexCommand ref
reference "lst:Hooking-dispatch-into-Boot"

\end_inset

.
 In this instance, we want state so that we can get the current user's chart.
 For this reason, we use 
\family typewriter
LiftRules.dispatch
\family default
 as opposed to 
\family typewriter
LiftRules.statelessDispatch
\family default
.
 Because we're using a partial function to perform a Scala match operation,
 the case that we define here uses the 
\family typewriter
Req
\family default
 object's 
\family typewriter
unapply
\family default
 method, which is why we only need to provide the 
\family typewriter
List[String]
\family default
 argument.
 
\begin_inset listings
inline false
status open

\begin_layout Plain Layout

\begin_inset Caption

\begin_layout Plain Layout
Hooking Dispatch into Boot
\begin_inset CommandInset label
LatexCommand label
name "lst:Hooking-dispatch-into-Boot"

\end_inset


\end_layout

\end_inset


\end_layout

\begin_layout Plain Layout

LiftRules.dispatch.append {
\end_layout

\begin_layout Plain Layout

  case Req("chart" :: "balances" :: endDate :: Nil, _, _) =>
\end_layout

\begin_layout Plain Layout

    Charting.chart(endDate) _
\end_layout

\begin_layout Plain Layout

}
\end_layout

\end_inset


\end_layout

\begin_layout Standard
As you can see, we capture the endDate parameter from the path and pass
 it into our chart method.
 This means that we can use a URL like 
\family typewriter
http://foo.com/chart/balances/20080401
\family default
 to obtain the image.
 Since the dispatch function has an associated Lift session, we can also
 use the S.param method to get query string parameters, if, for example,
 we wanted to allow someone to send an optional width and height:
\end_layout

\begin_layout LyX-Code
val width = S.param(
\begin_inset Quotes eld
\end_inset

width
\begin_inset Quotes erd
\end_inset

).map(_.toInt) openOr 400
\end_layout

\begin_layout LyX-Code
val height = S.param(
\begin_inset Quotes eld
\end_inset

height
\begin_inset Quotes erd
\end_inset

).map(_.toInt) openOr 300
\end_layout

\begin_layout Standard
Or you can use a slightly different approach by using the 
\family typewriter
Box.dmap
\family default
 method:
\end_layout

\begin_layout LyX-Code
val width = S.param(
\begin_inset Quotes eld
\end_inset

width
\begin_inset Quotes erd
\end_inset

).dmap(400)(_.toInt)
\end_layout

\begin_layout LyX-Code
val height = S.param(
\begin_inset Quotes eld
\end_inset

height
\begin_inset Quotes erd
\end_inset

).dmap(300)(_.toInt)
\end_layout

\begin_layout Standard
Where dmap is identical with map function except that the first argument
 is the default value to use if the 
\family typewriter
Box
\family default
 is 
\family typewriter
Empty
\family default
.
 There are a number of other ListResponse subclasses to cover your needs,
 including responses for XHTML, XML, Atom, Javascript, CSS, and JSON.
 We cover these in more detail in Section 
\begin_inset CommandInset ref
LatexCommand ref
reference "sec:LiftResponse-in-Detail"

\end_inset

.
\end_layout

\begin_layout Standard
\begin_inset Note Note
status open

\begin_layout Plain Layout
Make note of multipart mime handling, Req.uploadedFiles
\end_layout

\end_inset


\end_layout

\begin_layout Section
HTTP Redirects 
\begin_inset CommandInset label
LatexCommand label
name "sec:HTTP-redirects"

\end_inset


\end_layout

\begin_layout Standard
HTTP redirects are an important part of many web applications.
 In Lift there are two main ways of sending a redirect to the client:
\end_layout

\begin_layout Enumerate
Call S.redirectTo.
 When you do this, Lift throws an exception and catches it later on.
 This means that any code following the redirect is skipped.
 If you're using a StatefulSnippet (Section 
\begin_inset CommandInset ref
LatexCommand ref
reference "sub:Stateless-versus-Stateful"

\end_inset

), use 
\family typewriter
this.redirectTo
\family default
 so that your snippet instance is used when the redirect is processed.
\end_layout

\begin_deeper
\begin_layout Standard
\begin_inset Box Shadowbox
position "t"
hor_pos "c"
has_inner_box 1
inner_pos "t"
use_parbox 0
width "80col%"
special "none"
height "1in"
height_special "totalheight"
status open

\begin_layout Plain Layout

\series bold
Important:
\series default
 if you use S.redirectTo within a try/catch block, you'll need to make sure
 that you aren't catching the redirect exception (Scala uses unchecked exception
s), or test for the redirect's exception and rethrow it.
 Ifyou mistakenly catch the redirect exception, then no redirect will occur.
 
\end_layout

\end_inset


\end_layout

\end_deeper
\begin_layout Enumerate
When you need to return a LiftResponse, you can simply return a RedirectResponse
 or a RedirectWithState response.
\end_layout

\begin_layout Standard
The RedirectWithState response allows you to specify a function to be executed
 when the redirected request is processed.
 You can also send Lift messages (notices, warnings, and errors) that will
 be rendered in the redirected page, as well as cookies to be set on redirect.
 Similarly, there is an overloaded version of S.redirectTo that allows you
 to specify a function to be executed when the redirect is processed.
\end_layout

\begin_layout Section
Cookies
\begin_inset CommandInset label
LatexCommand label
name "sec:Cookies"

\end_inset


\end_layout

\begin_layout Standard
Cookies
\begin_inset Foot
status open

\begin_layout Plain Layout
\begin_inset CommandInset href
LatexCommand href
target "http://java.sun.com/products/servlet/2.2/javadoc/javax/servlet/http/Cookie.html"

\end_inset


\end_layout

\end_inset

 are a useful tool when you want data persisted across user sessions.
 Cookies are essentially a token of string data that is stored on the user's
 machine.
 While they can be quite useful, there are a few things that you should
 be aware of:
\end_layout

\begin_layout Enumerate
The user's browser may have cookies disabled, in which case you need to
 be prepared to work without cookies or tell the user that they need to
 enable them for your site
\end_layout

\begin_layout Enumerate
Cookies are relatively insecure
\begin_inset Foot
status open

\begin_layout Plain Layout
See 
\begin_inset CommandInset href
LatexCommand href
target "http://www.w3.org/Security/Faq/wwwsf2.html"

\end_inset

 (Q10) and 
\begin_inset CommandInset href
LatexCommand href
target "http://www.cookiecentral.com/faq/"

\end_inset

 for details on cookies and their security issues.
\end_layout

\end_inset

.
 There have been a number of browser bugs related to data in cookies being
 read by viruses or other sites
\end_layout

\begin_layout Enumerate
Cookies are easy to fake, so you need to ensure that you validate any sensitive
 cookie data
\end_layout

\begin_layout Standard
Using Cookies in Lift is very easy.
 In a stateful context, everything you need is provided by a few methods
 on the S object:
\end_layout

\begin_layout Description
addCookie Adds a cookie to be sent in the response
\end_layout

\begin_layout Description
deleteCookie Deletes a cookie (technically, this adds a cookie with a maximum
 age of zero so that the browser removes it).
 You can either delete a cookie by name, or with a Cookie object
\end_layout

\begin_layout Description
findCookie Looks for a cookie with a given name and returns a Box[Cookie].
 Empty means that the cookie doesn't exist
\end_layout

\begin_layout Description
receivedCookies Returns a List[Cookie] of all of the cookies sent in the
 request
\end_layout

\begin_layout Description
responseCookies Returns a List[Cookie] of the cookies that will be sent
 in the response
\end_layout

\begin_layout Standard
If you need to work with cookies in a stateless context, many of the ListRespons
e classes (Section 
\begin_inset CommandInset ref
LatexCommand ref
reference "sec:LiftResponse-in-Detail"

\end_inset

) include a List[Cookie] in their constructor or 
\family typewriter
apply
\family default
 arguments.
 Simply provide a list of the cookies you want to set, and they'll be sent
 in the response.
 If you want to delete a cookie in a LiftResponse, you have to do it manually
 by adding a cookie with the same name and a 
\family typewriter
maxage
\family default
 of zero.
 
\end_layout

\begin_layout Section
Session and Request State
\begin_inset CommandInset label
LatexCommand label
name "sec:Session-and-Request"

\end_inset


\end_layout

\begin_layout Standard
Lift provides a very easy way to store per-session and per-request data
 through the SessionVar and RequestVar classes.
 In true Lift fashion, these classes provide:
\end_layout

\begin_layout Itemize
Type-safe access to the data they hold
\end_layout

\begin_layout Itemize
A mechanism for providing a default value if the session or request doesn't
 exist yet
\end_layout

\begin_layout Itemize
A mechanism for cleaning up the data when the variable's lifecycle ends
\end_layout

\begin_layout Standard
Additionally, Lift provides easy access to HTTP request parameters
\begin_inset Index
status open

\begin_layout Plain Layout
request parameters
\end_layout

\end_inset

 via the S.param method, which returns a Box[String].
 Note that HTTP request parameters (sent via GET or POST) differ from RequestVar
s in that query parameters are string values sent as part of the request;
 RequestVars, in contrast, use an internal per-request Map so that they
 can hold any type, and are initialized entirely in code.
 At this point you might ask what RequestVars can be used for.
 A typical example would be sharing state between different snippets, since
 there is no connection between snippets other than at the template level.
\end_layout

\begin_layout Standard
SessionVars and RequestVars are intended to be implemented as singleton
 objects so that they're accessible from anywhere in your code.
 Listing 
\begin_inset CommandInset ref
LatexCommand ref
reference "lst:Defining-a-RequestVar"

\end_inset

 shows an example definition of a RequestVar used to hold the number of
 entries to show per page.
 We start by defining the object as extending the RequestVar.
 You must provide the type of the RequestVar so that Lift knows what to
 accept and return.
 In this instance, the type is an Int.
 The constructor argument is a by-name parameter which must evaluate to
 the var's type.
 In our case, we attempt to use the HTTP request variable 
\begin_inset Quotes eld
\end_inset

pageSize,
\begin_inset Quotes erd
\end_inset

 and if that isn't present or isn't an integer, then we default to 25.
\end_layout

\begin_layout Standard
\begin_inset listings
inline false
status open

\begin_layout Plain Layout

\begin_inset Caption

\begin_layout Plain Layout
Defining a RequestVar
\begin_inset CommandInset label
LatexCommand label
name "lst:Defining-a-RequestVar"

\end_inset


\end_layout

\end_inset


\end_layout

\begin_layout Plain Layout

class AccountOps {
\end_layout

\begin_layout Plain Layout

  object pageSize extends RequestVar[Int](S.param("pageSize").map(_.toInt)
 openOr 25)
\end_layout

\begin_layout Plain Layout

  ...
\end_layout

\begin_layout Plain Layout

}
\end_layout

\end_inset


\end_layout

\begin_layout Standard
Accessing the value of the 
\family typewriter
RequestVar
\family default
 is done via the 
\family typewriter
is
\family default
 method.
 You can also set the value using the 
\family typewriter
apply
\family default
 method, which in Scala is syntactically like using the 
\family typewriter
RequestVar
\family default
 as a function.
 Common uses of apply in Scala include array element access by index and
 companion object methods that can approximate custom constructors.
 For example, the 
\family typewriter
Loc
\family default
 object (which we'll cover in Chapter 
\begin_inset CommandInset ref
LatexCommand ref
reference "cha:SiteMap"

\end_inset

), has an overloaded 
\family typewriter
apply
\family default
 method that creates a new 
\family typewriter
Loc
\family default
 class instance based on input parameters.
\end_layout

\begin_layout Standard
\begin_inset listings
inline false
status open

\begin_layout Plain Layout

\begin_inset Caption

\begin_layout Plain Layout
Accessing the RequestVar
\begin_inset CommandInset label
LatexCommand label
name "lst:Accessing-the-RequestVar"

\end_inset


\end_layout

\end_inset


\end_layout

\begin_layout Plain Layout

// get the value contained in the AccountOps.pageSize RequestVar
\end_layout

\begin_layout Plain Layout

query.setMaxResults(AccountOps.pageSize.is)
\end_layout

\begin_layout Plain Layout

\end_layout

\begin_layout Plain Layout

// Change the value of the RequestVar.
 The following two lines
\end_layout

\begin_layout Plain Layout

// of code are equivalent:
\end_layout

\begin_layout Plain Layout

AccountOps.pageSize(50)
\end_layout

\begin_layout Plain Layout

AccountOps.pageSize.apply(50)
\end_layout

\end_inset


\end_layout

\begin_layout Standard
In addition to taking a parameter that defines a default value for setup,
 you can also clean up the value when the variable ends it lifecycle.
 Listing 
\begin_inset CommandInset ref
LatexCommand ref
reference "lst:Defining-a-Cleanup"

\end_inset

 shows an example of opening a socket and closing it at the end of the request.
 This is all handled by passing a function to the 
\family typewriter
registerCleanupFunc
\family default
 method.
 The type of the function that you need to pass is 
\begin_inset Formula $CleanUpParam\Rightarrow Unit$
\end_inset

, where 
\family typewriter
CleanUpParam
\family default
 is defined based on whether you're using a 
\family typewriter
RequestVar
\family default
 or a 
\family typewriter
SessionVar
\family default
.
 With 
\family typewriter
RequestVar
\family default
, 
\family typewriter
CleanUpParam
\family default
 is of type 
\family typewriter
Box[LiftSession]
\family default
, reflecting that the session may not be in scope when the cleanup function
 executes.
 For a 
\family typewriter
SessionVar
\family default
 the 
\family typewriter
CleanUpParam
\family default
 is of type 
\family typewriter
LiftSession
\family default
, since the session is always in scope for a 
\family typewriter
SessionVar
\family default
 (it holds a reference to the session).
 In our example in Listing 
\begin_inset CommandInset ref
LatexCommand ref
reference "lst:Defining-a-Cleanup"

\end_inset

 we simply ignore the input parameter to the cleanup function, since closing
 the socket is independent of any session state.
 Another important thing to remember is that you're responsible for handling
 any exceptions that might be thrown during either default initialization
 or cleanup.
 
\end_layout

\begin_layout Standard
\begin_inset listings
inline false
status open

\begin_layout Plain Layout

\begin_inset Caption

\begin_layout Plain Layout
Defining a Cleanup Function
\begin_inset CommandInset label
LatexCommand label
name "lst:Defining-a-Cleanup"

\end_inset


\end_layout

\end_inset


\end_layout

\begin_layout Plain Layout

object mySocket extends RequestVar[Socket](new Socket("localhost:23")) {
\end_layout

\begin_layout Plain Layout

  registerCleanupFunc(ignore => this.is.close)
\end_layout

\begin_layout Plain Layout

}
\end_layout

\end_inset


\end_layout

\begin_layout Standard
The information we've covered here is equally applicable to SessionVars;
 the only difference between them is the scope of their respective lifecycles.
\end_layout

\begin_layout Standard
Another common use of 
\family typewriter
RequestVar
\family default
 is to pass state around between different page views (requests).
 We start by defining a 
\family typewriter
RequestVar
\family default
 on an object so that it's accesible from all of the snippet methods that
 will read and write to it.
 It's also possible to define it on a class if all of the snippets that
 will access it are in that class.
 Then, in the parts of your code that will transition to a new page you
 use the overloaded versions of 
\family typewriter
SHtml.link
\family default
 or
\family typewriter
 S.redirectTo
\family default
 that take a function as a second argument to 
\begin_inset Quotes eld
\end_inset

inject
\begin_inset Quotes erd
\end_inset

 the value you want to pass via the 
\family typewriter
RequestVar
\family default
.
 This is similar to using a query parameter on the URL to pass data, but
 there are two important advantages:
\end_layout

\begin_layout Enumerate
You can pass any type of data via a 
\family typewriter
RequestVar
\family default
, as opposed to just string data in a query parameter.
\end_layout

\begin_layout Enumerate
You're really only passing a reference to the injector function, as opposed
 to the data itself.
 This can be important if you don't want the user to be able to tamper with
 the passed data.
 One example would be passing the cost of an item from a 
\begin_inset Quotes eld
\end_inset

view item
\begin_inset Quotes erd
\end_inset

 page to an 
\begin_inset Quotes eld
\end_inset

add to cart
\begin_inset Quotes erd
\end_inset

 page.
\end_layout

\begin_layout Standard
Listing 
\begin_inset CommandInset ref
LatexCommand ref
reference "lst:Passing-an-Account"

\end_inset

 shows how we pass an Account from a listing table to a specific Account
 edit page using 
\family typewriter
SHtml.link
\family default
, as well as how we could transition from an edit page to a view page using
 
\family typewriter
S.redirectTo
\family default
.
 Another example of passing is shown in Listing 
\begin_inset CommandInset ref
LatexCommand vref
reference "lst:Passing-Detached-Instances"

\end_inset

.
\end_layout

\begin_layout Standard
\begin_inset listings
inline false
status open

\begin_layout Plain Layout

\begin_inset Caption

\begin_layout Plain Layout
Passing an Account to View
\begin_inset CommandInset label
LatexCommand label
name "lst:Passing-an-Account"

\end_inset


\end_layout

\end_inset


\end_layout

\begin_layout Plain Layout

class AccountOps {
\end_layout

\begin_layout Plain Layout

  ...
\end_layout

\begin_layout Plain Layout

  object currentAccountVar extends RequestVar[Account](null)
\end_layout

\begin_layout Plain Layout

  ...
\end_layout

\begin_layout Plain Layout

  def manage (xhtml : NodeSeq) ...
 {
\end_layout

\begin_layout Plain Layout

    ...
\end_layout

\begin_layout Plain Layout

    User.currentUser.map({user => 
\end_layout

\begin_layout Plain Layout

      user.accounts.flatMap({acct =>
\end_layout

\begin_layout Plain Layout

        bind("acct", chooseTemplate("account", "entry", xhtml),
\end_layout

\begin_layout Plain Layout

          ...
\end_layout

\begin_layout Plain Layout

          // The second argument injects the "acct" val back
\end_layout

\begin_layout Plain Layout

          // into the RequestVar
\end_layout

\begin_layout Plain Layout

          link("/editAcct", () => currentAccountVar(acct), Text("Edit"))
\end_layout

\begin_layout Plain Layout

      })
\end_layout

\begin_layout Plain Layout

    })
\end_layout

\begin_layout Plain Layout

    ...
\end_layout

\begin_layout Plain Layout

  }
\end_layout

\begin_layout Plain Layout

  def edit (xhtml : NodeSeq) : NodeSeq = {
\end_layout

\begin_layout Plain Layout

    def doSave () {
\end_layout

\begin_layout Plain Layout

      ...
\end_layout

\begin_layout Plain Layout

      val acct = currentAccountVar.is
\end_layout

\begin_layout Plain Layout

      S.redirectTo("/view", () => currentAccountVar(acct))
\end_layout

\begin_layout Plain Layout

    }
\end_layout

\begin_layout Plain Layout

    ...
\end_layout

\begin_layout Plain Layout

  }
\end_layout

\begin_layout Plain Layout

}
\end_layout

\end_inset


\end_layout

\begin_layout Standard
One important thing to note is that the injector variable is called in the
 scope of the 
\emph on
following
\emph default
 request.
 This means that if you want the value returned by the function at the point
 where you call the link or redirectTo, you'll need to capture it in a val.
 Otherwise, the function will be called 
\emph on
after
\emph default
 the redirect or link, which may result in a different value than you expect.
 As you can see in Listing 
\begin_inset CommandInset ref
LatexCommand ref
reference "lst:Passing-an-Account"

\end_inset

, we set up an acct val in our doSave method prior to redirecting.
 If we tried to do something like
\end_layout

\begin_layout LyX-Code
S.redirectTo("/view", () => currentAccountVar(currentAccountVar.is))
\end_layout

\begin_layout Standard
instead, we would get the default value of our RequestVar (null in this
 case).
\end_layout

\begin_layout Section
Conclusion
\end_layout

\begin_layout Standard
We've covered a lot of material and we still have a lot more to go.
 Hopefully this chapter provides a firm basis to start from when exploring
 the rest of the book.
\end_layout

\end_body
\end_document