Simply_Lift.lyx

#LyX 1.6.9 created this file. For more info see http://www.lyx.org/
\lyxformat 345
\begin_document
\begin_header
\textclass book
\begin_preamble
\usepackage[notbib]{tocbibind}
\usepackage{breakurl}
\usepackage{textcomp}
\usepackage[htt]{hyphenat}

% redefine the \LyX macro for PDF bookmarks
\def\LyX{\texorpdfstring{%
  L\kern-.1667em\lower.25em\hbox{Y}\kern-.125emX\@}
  {LyX }}


% "define" Scala
\lstdefinelanguage{scala}{morekeywords={abstract,case,catch,class,def,do,else,extends,false,final,finally,for,forSome,if,implicit,import,lazy,match,new,null,object,override,package,private,protected,return,sealed,super,this,throw,trait,try,true,type,val,var,while,with,yield},
otherkeywords={=>,<-,<:,<\%,>:},
sensitive=true,
morecomment=[l]{//},
morecomment=[s]{/*}{*/},
morestring=[b]"}

\definecolor{darkgreen}{rgb}{0,0.4,0}

% Default settings for code listings
\lstset{frame=tb,
language=scala,
aboveskip=3mm,
belowskip=3mm,
showstringspaces=false,
columns=flexible,
basicstyle={\small\ttfamily},
keywordstyle=\color{blue},
commentstyle=\color{darkgreen},
stringstyle=\color{red},
upquote=true,
showtabs=true,
tab=BADTAB,
numbers=left,
numberstyle=\tiny}

% Fix the List of Listings title
\renewcommand{\lstlistlistingname}{List of Listings}

% Be less rigorous with line breaking
\sloppy
\end_preamble
\use_default_options true
\begin_modules
theorems-ams
eqs-within-sections
figs-within-sections
\end_modules
\language english
\inputencoding auto
\font_roman palatino
\font_sans default
\font_typewriter courier
\font_default_family default
\font_sc false
\font_osf false
\font_sf_scale 100
\font_tt_scale 100

\graphics default
\paperfontsize 11
\spacing single
\use_hyperref true
\pdf_title "Simply Lift"
\pdf_author "David Pollak"
\pdf_bookmarks true
\pdf_bookmarksnumbered true
\pdf_bookmarksopen false
\pdf_bookmarksopenlevel 1
\pdf_breaklinks true
\pdf_pdfborder true
\pdf_colorlinks true
\pdf_backref false
\pdf_pdfusetitle false
\pdf_quoted_options "urlcolor=blue,linkcolor=blue"
\papersize letterpaper
\use_geometry true
\use_amsmath 1
\use_esint 1
\cite_engine basic
\use_bibtopic false
\paperorientation portrait
\leftmargin 1in
\topmargin 1in
\rightmargin 1in
\bottommargin 1in
\secnumdepth 2
\tocdepth 2
\paragraph_separation skip
\defskip medskip
\quotes_language english
\papercolumns 1
\papersides 2
\paperpagestyle headings
\tracking_changes false
\output_changes false
\author "" 
\author "" 
\end_header

\begin_body

\begin_layout Standard
\begin_inset ERT
status open

\begin_layout Plain Layout


\backslash
frontmatter
\end_layout

\end_inset


\end_layout

\begin_layout Title
Simply Lift
\end_layout

\begin_layout Author
David Pollak
\end_layout

\begin_layout Date
September 8, 2011
\end_layout

\begin_layout Standard
\noindent
Copyright © 2010-2011 by David Pollak
\begin_inset Newline newline
\end_inset

This document is licensed Creative Commons Attribution, Non Commercial,
 No Derivatives: 
\begin_inset Flex URL
status open

\begin_layout Plain Layout

http://creativecommons.org/licenses/by-nc-nd/3.0/
\end_layout

\end_inset

 
\end_layout

\begin_layout Standard
\begin_inset CommandInset toc
LatexCommand tableofcontents

\end_inset


\end_layout

\begin_layout Standard
\begin_inset FloatList figure

\end_inset


\end_layout

\begin_layout Standard
\begin_inset ERT
status open

\begin_layout Plain Layout


\backslash
lstlistoflistings
\end_layout

\end_inset


\end_layout

\begin_layout Standard
\begin_inset ERT
status open

\begin_layout Plain Layout


\backslash
mainmatter
\end_layout

\end_inset


\end_layout

\begin_layout Part
The Lift Web Framework
\end_layout

\begin_layout Chapter
Introduction
\end_layout

\begin_layout Standard
The Lift Web Framework provides web application developers tools to make
 writing security, interacting, scalable web applications easier than with
 any other web framework.
 After reading Part I of this book, you should understand Lift's core concepts
 and be able to write Lift applications.
 But with anything, practice is important.
 I have been writing Lift and Scala for 4 years, and even I learn new things
 about the language and the framework on a weekly basis.
 Please consider Lift an path and an exploration, rather than an end point.
\end_layout

\begin_layout Standard
\begin_inset Quotes eld
\end_inset

Yo, David, stop yer yappin'.
 I'm coming from Rails|Spring|Struts|Django and I want to get started super
 fast with Lift.
\begin_inset Quotes erd
\end_inset

 See From MVC (
\begin_inset CommandInset ref
LatexCommand vref
reference "cha:From-MVC"

\end_inset

).
\end_layout

\begin_layout Standard
Lift is built on top of the 
\begin_inset CommandInset href
LatexCommand href
name "Scala"
target "http://scala-lang.org"

\end_inset

 programming language.
 Scala runs on the 
\begin_inset CommandInset href
LatexCommand href
name "Java Virtual Machine"
target "http://www.oracle.com/technetwork/java/index.html"

\end_inset

.
 Lift applications are typically packaged as 
\begin_inset CommandInset href
LatexCommand href
name "WAR"
target "http://en.wikipedia.org/wiki/WAR_(Sun_file_format)"

\end_inset

 files and run as a 
\begin_inset CommandInset href
LatexCommand href
name "J/EE Servlets"
target "http://www.oracle.com/technetwork/java/index-jsp-135475.html"

\end_inset

 or Servlet Filters.
 This book will provide you with the core concepts you need to successfully
 write Lift web applications.
 The book assumes knowledge of Servlets and Servlet containers, the Scala
 Language (Chapters 1-6 of 
\shape italic

\begin_inset CommandInset href
LatexCommand href
name "Beginning Scala"
target "http://apress.com/book/view/9781430219897"

\end_inset


\shape default
 gives you a good grounding in the language), build tools, program editors,
 web development including HTML and JavaScript, etc.
 Further, this book will not explore persistence.
 Lift has additional modules for persisting to relational and non-relational
 data stores.
 Lift doesn't distinguish as to how an object is materialized into the address
 space...
 Lift can treat any object any old way you want.
 There are many resources (including 
\begin_inset CommandInset href
LatexCommand href
name "Exploring Lift"
target "http://exploring.liftweb.net/"

\end_inset

) that cover ways to persist data from a JVM.
\end_layout

\begin_layout Standard
Lift is different from most web frameworks and it's likely that Lift's differenc
es will present a challenge and a friction if you are familiar with the
 MVC
\begin_inset Index
status open

\begin_layout Plain Layout
MVC
\end_layout

\end_inset

 school of web frameworks
\begin_inset Foot
status open

\begin_layout Plain Layout
This includes Ruby on Rails, Struts, Java Server Faces, Django, TurboGears,
 etc.
\end_layout

\end_inset

.
 But Lift is different and Lift's differences give you more power to create
 interactive applications.
 Lift's differences lead to more concise web applications.
 Lift's differences result in more secure and scalable applications.
 Lift's differences let you be more productive and make maintaining applications
 easier for the future you or whoever is writing your applications.
 Please relax and work to understand Lift's differences...
 and see how you can make best use of Lift's features to build your web
 applications.
\end_layout

\begin_layout Standard
Lift creates abstractions that allow easier expression of business logic
 and then maps those abstractions to HTTP and HTML.
 This approach differs from traditional web frameworks which build abstractions
 on top of HTTP and HTML and require the developer to bridge between common
 business logic patterns and the underlying protocol.
 The difference means that you spend more time thinking about your application
 and less time thinking about the plumbing.
\end_layout

\begin_layout Standard
I am a 
\begin_inset Quotes eld
\end_inset

concept learner.
\begin_inset Quotes erd
\end_inset

 I learn concepts and then apply them over and over again as situations
 come up.
 This book focuses a lot on the concepts.
 If you're a concept learner and like my stream on conciousness style, this
 book will likely suit you well.
 On the other hand, it may not.
\end_layout

\begin_layout Standard
Up to date versions of this book are available in PDF form at 
\begin_inset Flex URL
status collapsed

\begin_layout Plain Layout

http://simply.liftweb.net/Simply_Lift.pdf
\end_layout

\end_inset

.
 The source code for this book is available at 
\begin_inset CommandInset href
LatexCommand href
name "https://github.com/dpp/simply_lift"
target "https://github.com/dpp/simply_lift"

\end_inset

.
\end_layout

\begin_layout Standard
If you've got questions, feedback, or improvements to this document, please
 join the conversation on the 
\begin_inset CommandInset href
LatexCommand href
name "Lift Google Group"
target "http://groups.google.com/group/liftweb"

\end_inset

.
\end_layout

\begin_layout Standard
I'm a 
\begin_inset Quotes eld
\end_inset

roll up your sleaves and get your hands dirty with code
\begin_inset Quotes erd
\end_inset

 kinda guy...
 so let's build a simple Chat application in Lift.
 This application will allow us to demonstrate some of Lift's core features
 as well as giving a 
\begin_inset Quotes eld
\end_inset

smack in the face
\begin_inset Quotes erd
\end_inset

 demonstration of how Lift is different.
\end_layout

\begin_layout Chapter
\begin_inset CommandInset label
LatexCommand label
name "cha:The-ubiquitous-Chat"

\end_inset

The ubiquitous Chat app
\end_layout

\begin_layout Standard
Writing a multi-user chat application in Lift is super-simple and illustrates
 many of Lift's core concepts.
\end_layout

\begin_layout Standard
The Source Code can be found at 
\begin_inset CommandInset href
LatexCommand href
target "https://github.com/dpp/simply_lift/tree/master/chat"

\end_inset

.
\end_layout

\begin_layout Section
The View
\end_layout

\begin_layout Standard
When writing a Lift app, it's often best to start off with the user interface...
 build what the user will see and then add behavior to the HTML page.
 So, let's look at the Lift template that will make up our chat application.
\end_layout

\begin_layout Standard
\begin_inset CommandInset include
LatexCommand lstinputlisting
filename "chat/src/main/webapp/index.html"
lstparams "caption={index.html},language=xml"

\end_inset


\end_layout

\begin_layout Standard
It's a valid HTML page, but there are some hinky looking class attributes.
 The first one is 
\family typewriter
<body class="lift:content_id=main">
\family default
.
 The class in this case says 
\begin_inset Quotes eld
\end_inset

the actual page content is contained by the element with id='main'.
\begin_inset Quotes erd
\end_inset

 This allows you to have valid HTML pages for each of your templates, but
 dynamically add 
\begin_inset Quotes eld
\end_inset

chrome
\begin_inset Quotes erd
\end_inset

 around the content based on one or more chrome templates.
\end_layout

\begin_layout Standard
Let's look at the 
\family typewriter
<div id="main">
\family default
.
 It's got a funky class as well: 
\family typewriter
lift:surround?with=default;at=content
\family default
.
 This class invokes a snippet which surrounds the 
\family typewriter
<div>
\family default
 with the default template and inserts the 
\family typewriter
<div>
\family default
 and its children at the element with id 
\begin_inset Quotes eld
\end_inset

content
\begin_inset Quotes erd
\end_inset

 in the default template.
 Or, it wraps the default chrome around the 
\family typewriter
<div>
\family default
.
 For more on snippets, see 
\begin_inset CommandInset ref
LatexCommand vref
reference "sec:Snippets"

\end_inset

.
\end_layout

\begin_layout Standard
Next, we define how we associate dynamic behavior with the list of chat
 elements: 
\family typewriter
<div class="lift:comet?type=Chat">
\family default
.
 The 
\begin_inset Quotes eld
\end_inset

comet
\begin_inset Quotes erd
\end_inset

 snippet looks for a class named 
\family typewriter
Chat
\family default
 that extends 
\family typewriter
CometActor
\family default
 and enables the mechanics of pushing content from the 
\family typewriter
CometActor
\family default
 to the browser when the state of the 
\family typewriter
CometActor
\family default
 changes.
 
\end_layout

\begin_layout Section
The Chat Comet component
\end_layout

\begin_layout Standard
The 
\begin_inset CommandInset href
LatexCommand href
name "Actor Model"
target "http://en.wikipedia.org/wiki/Actor_model"

\end_inset

 provides state in functional languages include Erlang.
 Lift has an Actor library and LiftActors (see 
\begin_inset CommandInset ref
LatexCommand ref
reference "sec:LiftActor"

\end_inset

) provides a powerful state and concurrency model.
 This may all seem abstract, so let's look at the 
\family typewriter
Chat
\family default
 class.
\end_layout

\begin_layout Standard
\begin_inset CommandInset include
LatexCommand lstinputlisting
filename "chat/src/main/scala/code/comet/Chat.scala"
lstparams "caption={Chat.scala},label={Chat}"

\end_inset


\end_layout

\begin_layout Standard
The 
\family typewriter
Chat
\family default
 component has private state, registers with the 
\family typewriter
ChatServer
\family default
, handles incoming messages and can render itself.
 Let's look at each of those pieces.
\end_layout

\begin_layout Standard
The private state, like any private state in prototypical object oriented
 code, is the state that defines the object's behavior.
\end_layout

\begin_layout Standard
registerWith is a method that defines what component to register the Chat
 component with.
 Registration is a part of the Listener (or 
\begin_inset CommandInset href
LatexCommand href
name "Observer"
target "http://en.wikipedia.org/wiki/Observer_pattern"

\end_inset

) pattern.
 We'll look at the definition of the 
\family typewriter
ChatServer
\family default
 in a minute.
\end_layout

\begin_layout Standard
The 
\family typewriter
lowPriority
\family default
 method defines how to process incoming messages.
 In this case, we're Pattern Matching (see 
\begin_inset CommandInset ref
LatexCommand prettyref
reference "sec:Pattern-Matching"

\end_inset

) the incoming message and if it's a 
\family typewriter
Vector[String]
\family default
, then we perform the action of setting our local state to the 
\family typewriter
Vector
\family default
 and re-rendering the component.
 The re-rendering will force the changes out to any browser that is displaying
 the component.
\end_layout

\begin_layout Standard
We define how to 
\family typewriter
render
\family default
 the component by defining the CSS to match and the replacement (See 
\begin_inset CommandInset ref
LatexCommand prettyref
reference "sec:CSS-Selector-Transforms"

\end_inset

).
 We match all the 
\family typewriter
<li>
\family default
 tags of the template and for each message, create an 
\family typewriter
<li>
\family default
 tag with the child nodes set to the message.
 Additionally, we clear all the elements that have the 
\family typewriter
clearable
\family default
 in the 
\family typewriter
class
\family default
 attribute.
\end_layout

\begin_layout Standard
That's it for the Chat CometActor component.
\end_layout

\begin_layout Section
The 
\family typewriter
ChatServer
\end_layout

\begin_layout Standard
The ChatServer code is:
\end_layout

\begin_layout Standard
\begin_inset CommandInset include
LatexCommand lstinputlisting
filename "chat/src/main/scala/code/comet/ChatServer.scala"
lstparams "caption={ChatServer.scala},label={ChatServer.scala}"

\end_inset


\end_layout

\begin_layout Standard
The 
\family typewriter
ChatServer
\family default
 is defined as an 
\family typewriter
object
\family default
 rather than a 
\family typewriter
class
\family default
.
 This makes it a singleton which can be referenced by the name 
\family typewriter
ChatServer
\family default
 anywhere in the application.
 Scala's singletons differ from Java's 
\family typewriter
static
\family default
 in that the singleton is an instance of an object and that instance can
 be passed around like any other instance.
 This is why we can return the 
\family typewriter
ChatServer
\family default
 instance from the 
\family typewriter
registerWith
\family default
 method in that 
\family typewriter
Chat
\family default
 component.
\end_layout

\begin_layout Standard
The ChatServer has private state, a 
\family typewriter
Vector[String]
\family default
 representing the list of chat messages.
 Note that Scala's type inferencer infers the type of 
\family typewriter
msgs
\family default
 so you do not have to explicitly define it.
\end_layout

\begin_layout Standard
The 
\family typewriter
createUpdate
\family default
 method generates an update to send to listeners.
 This update is sent when a listener registers with the 
\family typewriter
ChatServer
\family default
 or when the 
\family typewriter
updateListeners()
\family default
 method is invoked.
\end_layout

\begin_layout Standard
Finally, the 
\family typewriter
lowPriority
\family default
 method defines the messages that this component can handle.
 If the 
\family typewriter
ChatServer
\family default
 receives a 
\family typewriter
String
\family default
 as a message, it appends the 
\family typewriter
String
\family default
 to the 
\family typewriter
Vector
\family default
 of messages and updates listeners.
\end_layout

\begin_layout Section
User Input
\end_layout

\begin_layout Standard
Let's go back to the view and see how the behavior is defined for adding
 lines to the chat.
\end_layout

\begin_layout Standard

\family typewriter
<form class="lift:form.ajax">
\family default
 defines an input form and the 
\family typewriter
form.ajax
\family default
 snippet turns a form into an Ajax (see 
\begin_inset CommandInset ref
LatexCommand prettyref
reference "sec:Ajax"

\end_inset

) form that will be submitted back to the server without causing a full
 page load.
\end_layout

\begin_layout Standard
Next, we define the input form element: 
\family typewriter
<input class="lift:ChatIn" id="chat_in"/>
\family default
.
 It's a plain old input form, but we've told Lift to modify the 
\family typewriter
<input>
\family default
's behavior by calling the 
\family typewriter
ChatIn
\family default
 snippet.
\end_layout

\begin_layout Section
Chat In
\end_layout

\begin_layout Standard
The 
\family typewriter
ChatIn
\family default
 snippet (See 
\begin_inset CommandInset ref
LatexCommand prettyref
reference "sec:Snippets"

\end_inset

) is defined as:
\end_layout

\begin_layout Standard
\begin_inset CommandInset include
LatexCommand lstinputlisting
filename "chat/src/main/scala/code/snippet/ChatIn.scala"
lstparams "caption={ChatIn.scala},label={ChatIn.scala}"

\end_inset


\end_layout

\begin_layout Standard
The code is very simple.
 The snippet is defined as a method that associates a function with form
 element submission, 
\family typewriter
onSubmit
\family default
.
 When the element is submitted, be that normal form submission, Ajax, or
 whatever, the function is applied to the value of the form.
 In English, when the user submits the form, the function is called with
 the user's input.
\end_layout

\begin_layout Standard
The function sends the input as a message to the 
\family typewriter
ChatServer
\family default
 and returns JavaScript that sets the value of the input box to a blank
 string.
\end_layout

\begin_layout Section
Running it
\end_layout

\begin_layout Standard
Running the application is easy.
 Make sure you've got Java 1.6 or better installed on your machine.
 Change directories into the 
\family typewriter
chat
\family default
 directory and type 
\family typewriter
sbt
\family default
and inside the sbt prompt, type
\family typewriter
container:start
\family default
.
 The Simple Build Tool will download all necessary dependencies, compile
 the program and run it.
\end_layout

\begin_layout Standard
You can point a couple of browsers to 
\begin_inset Flex URL
status collapsed

\begin_layout Plain Layout

http://localhost:8080
\end_layout

\end_inset

 and start chatting.
\end_layout

\begin_layout Standard
Oh, and for fun, try entering 
\family typewriter
<script>alert('I ownz your browser');<script>
\family default
 and see what happens.
 You'll note it's what you want to happen.
\end_layout

\begin_layout Section
What you don't see
\end_layout

\begin_layout Standard
Excluding imports and comments, there are about 20 lines of Scala code to
 implement a multi-threaded, multi-user chat application.
 That's not a lot.
\end_layout

\begin_layout Standard
The first thing that's missing is synchronization or other explicit forms
 of thread locking.
 The application takes advantage of Actors and immutable data structures,
 thus the developer can focus on the business logic rather than the threading
 and locking primatives.
\end_layout

\begin_layout Standard
The next thing that's missing is routing and controllers and other stuff
 that you might have to do to wire up Ajax calls and polling for server-side
 changes (long or otherwise).
 In our application, we associated behavior with display and Lift took care
 of the rest (see 
\begin_inset CommandInset ref
LatexCommand prettyref
reference "sec:Page-rewriting"

\end_inset

).
\end_layout

\begin_layout Standard
We didn't do anything to explicitly to avoid cross-site scripting in our
 application.
 Because Lift takes advantage of Scala's strong typing and type safety (see
 
\begin_inset CommandInset ref
LatexCommand prettyref
reference "sec:Type-safety"

\end_inset

), Lift knows the difference between a String that must be HTML encoded
 and an HTML element that's already properly encoded.
 By default, Lift applications are resistant to many of the OWASP top 10
 security vulnerabilities (see 
\begin_inset CommandInset ref
LatexCommand prettyref
reference "sec:Security"

\end_inset

).
\end_layout

\begin_layout Standard
This example shows many of Lift's strengths.
 Let's expand the application and see how Lift's strengths continue to support
 the development of the application.
\end_layout

\begin_layout Standard
\begin_inset CommandInset include
LatexCommand include
filename "samples/snippet_and_sitemap/snippet_and_sitemap.lyx"

\end_inset


\end_layout

\begin_layout Standard
\begin_inset CommandInset include
LatexCommand include
filename "samples/forms/forms.lyx"

\end_inset


\end_layout

\begin_layout Standard
\begin_inset CommandInset include
LatexCommand include
filename "samples/http_rest/http_rest.lyx"

\end_inset


\end_layout

\begin_layout Standard
\begin_inset CommandInset include
LatexCommand include
filename "samples/shopwithme/wiring.lyx"

\end_inset


\end_layout

\begin_layout Chapter
Core Concepts
\end_layout

\begin_layout Standard
\begin_inset CommandInset include
LatexCommand include
filename "chapters/snippets.lyx"

\end_inset


\end_layout

\begin_layout Section
Box/Option
\begin_inset CommandInset label
LatexCommand label
name "sec:Box/Option"

\end_inset


\end_layout

\begin_layout Standard
Scala has a ton of nice features.
 One of the features that I was slow to adopt, until Burak Emir gently reminded
 me a bunch of times, is "Options".
 Read on about Options, Boxes, and how Lift makes good use of them to make
 clean, error resistant code.
 If you come from an imperative (Java, Ruby) background, you'll probably
 recognize the following code:
\end_layout

\begin_layout Standard
\begin_inset listings
inline false
status open

\begin_layout Plain Layout

x = someOperation 
\end_layout

\begin_layout Plain Layout

if !x.nil? 
\end_layout

\begin_layout Plain Layout

  y = someOtherOperation 
\end_layout

\begin_layout Plain Layout

  if !y.nil? 
\end_layout

\begin_layout Plain Layout

    doSomething(x,y) return "it worked" 
\end_layout

\begin_layout Plain Layout

  end
\end_layout

\begin_layout Plain Layout

end
\end_layout

\begin_layout Plain Layout

return "it failed" 
\end_layout

\end_inset


\end_layout

\begin_layout Standard
Okay, so that's pseudo-code, but there are tons of operation, guard, operation,
 guard, blah blah constructs.
\end_layout

\begin_layout Standard
Further, null/nil are passed around as failures.
 This is especially bad when it's null, but it's pretty bad when it's nil
 because it's not clear to the consumer of the API that there can be a "call
 failed" return value.
\end_layout

\begin_layout Standard
In Java, 
\family typewriter
null
\family default
 is a non-object.
 It has no methods.
 It is the exception to the statically typed rule (
\family typewriter
null
\family default
 has no class, but any reference of any class can be set to 
\family typewriter
null
\family default
.) Invoking a method on 
\family typewriter
null
\family default
 has one and only one result: an exception is thrown.
 
\family typewriter
null
\family default
 is often returned from methods as a flag indicating that the method ran
 successfully, but yielded no meaningful value.
 For example, 
\family typewriter
CardHolder.findByCreditCardNumber("2222222222")
\family default
 In fact, the guy who invented 
\family typewriter
null
\family default
 called it a 
\begin_inset CommandInset href
LatexCommand href
name "billion dollar mistake"
target "http://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare"

\end_inset

.
\end_layout

\begin_layout Standard
Ruby has 
\family typewriter
nil
\family default
 which is marginally better than 
\family typewriter
null
\family default
.
 
\family typewriter
nil
\family default
 is a real, singleton object.
 There's only one instance of 
\family typewriter
nil
\family default
 in the whole system.
 It has methods.
 It is a subclass of 
\family typewriter
Object
\family default
.
 
\family typewriter
Object
\family default
 has a method called "
\family typewriter
nil?
\family default
" which returns 
\family typewriter
false
\family default
, except the 
\family typewriter
nil
\family default
 singleton overrides this method to return 
\family typewriter
true
\family default
.
 
\family typewriter
nil
\family default
 is returned much like 
\family typewriter
null
\family default
 in Java.
 It's the "no valid answer" answer.
\end_layout

\begin_layout Standard
Scala does something different.
\end_layout

\begin_layout Standard
There's an abstract class, called 
\family typewriter
Option
\family default
.
 Options are strongly typed.
 They are declared 
\family typewriter
Option[T]
\family default
.
 This means an 
\family typewriter
Option
\family default
 can be of any type, but once its type is defined, it does not change.
 There are two subclasses of 
\family typewriter
Option
\family default
: 
\family typewriter
Some
\family default
 and 
\family typewriter
None
\family default
.
 
\family typewriter
None
\family default
 is a singleton (like 
\family typewriter
nil
\family default
).
 
\family typewriter
Some
\family default
 is a container around the actual answer.
 So, you might have a method that looks like:
\end_layout

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

\begin_layout Plain Layout

def findUser(name: String): Option[User] = { 
\end_layout

\begin_layout Plain Layout

  val query = buildQuery(name)
\end_layout

\begin_layout Plain Layout

  val resultSet = performQuery(query)
\end_layout

\begin_layout Plain Layout

  val retVal = if (resultSet.next) Some(createUser(resultSet)) else None
\end_layout

\begin_layout Plain Layout

  resultSet.close 
\end_layout

\begin_layout Plain Layout

  retVal 
\end_layout

\begin_layout Plain Layout

} 
\end_layout

\end_inset

 
\end_layout

\begin_layout Standard
Some, you've got a 
\family typewriter
findUser
\family default
 method that returns either 
\family typewriter
Some(User)
\family default
 or 
\family typewriter
None
\family default
.
 So far, it doesn't look a lot different than our example above.
 So, to confuse everyone, I'm going to talk about collections for a minute.
\end_layout

\begin_layout Standard
A really nice thing in Scala (yes, Ruby has this too) is rich list operations.
 Rather than creating a counter and pulling list (array) elements out one
 by one, you write a little function and pass that function to the list.
 The list calls the function with each element and returns a new list with
 the values returned from each call.
 It's easier to see it in code:
\end_layout

\begin_layout Standard
\begin_inset listings
inline false
status open

\begin_layout Plain Layout

scala> List(1,2,3).map(x => x * 2)
\end_layout

\begin_layout Plain Layout

line0: scala.List[scala.Int] = List(2,4,6)
\end_layout

\end_inset


\end_layout

\begin_layout Standard
The above code multiplies each list item by two and "map" returns the resulting
 list.
 Oh, and you can be more terse, if you want:
\end_layout

\begin_layout Standard
\begin_inset listings
inline false
status open

\begin_layout Plain Layout

scala> List(1,2,3).map(_ * 2)
\end_layout

\begin_layout Plain Layout

line2: scala.List[scala.Int] = List(2,4,6)
\end_layout

\end_inset

You can nest map operations:
\end_layout

\begin_layout Standard
\begin_inset listings
inline false
status open

\begin_layout Plain Layout

scala> List(1,2,3).map(x => List(4,5,6).map(y => x * y))
\end_layout

\begin_layout Plain Layout

line13: scala.List[scala.List[scala.Int]] = List(List(4,5,6),List(8,10,12),List(12,
15,18))
\end_layout

\end_inset


\end_layout

\begin_layout Standard
And, you can "flatten" the inner list:
\end_layout

\begin_layout Standard
\begin_inset listings
inline false
status open

\begin_layout Plain Layout

scala> List(1,2,3).flatMap(x => List(4,5,6).map(y => x * y))
\end_layout

\begin_layout Plain Layout

line14: scala.List[scala.Int] = List(4,5,6,8,10,12,12,15,18)
\end_layout

\end_inset

Finally, you can "filter" only the even numbers from the first list:
\end_layout

\begin_layout Standard
\begin_inset listings
inline false
status open

\begin_layout Plain Layout

scala> List(1,2,3).filter(_ % 2 == 0).
 flatMap(x => List(4,5,6).map(y => x * y))
\end_layout

\begin_layout Plain Layout

line16: scala.List[scala.Int] = List(8,10,12)
\end_layout

\end_inset

But, as you can see, the 
\family typewriter
map
\family default
/
\family typewriter
flatMap
\family default
/
\family typewriter
filter
\family default
 stuff gets pretty verbose.
 Scala introduced a "for" comprehension to make the code more readable:
\end_layout

\begin_layout Standard
\begin_inset listings
inline false
status open

\begin_layout Plain Layout

scala> for {
\end_layout

\begin_layout Plain Layout

  x <- List(1,2,3) if x % 2 == 0
\end_layout

\begin_layout Plain Layout

  y <- List(4,5,6)} yield x * y
\end_layout

\begin_layout Plain Layout

res0: List[Int] = List(8, 10, 12)
\end_layout

\end_inset

 
\end_layout

\begin_layout Standard
Okay, but what does this have to do with 
\family typewriter
Option[T]
\family default
?
\end_layout

\begin_layout Standard
Turns out that 
\family typewriter
Option
\family default
 implements 
\family typewriter
map
\family default
, 
\family typewriter
flatMap
\family default
, and 
\family typewriter
filter
\family default
 (the methods necessary for the Scala compiler to use in the 'for' comprehension
).
 Just as a side note, when I first encountered the phrase "'for' comprehension",
 I got scared.
 I've been doing programming for years and never heard of a "comprenhension"
 let alone a 'for' one.
 Turns out, that there's nothing fancy going on, but "'for' comprehension"
 is just a term of art for the above construct.
\end_layout

\begin_layout Standard
So, the cool thing is that you can use this construct very effectively.
 The first example is simple:
\end_layout

\begin_layout Standard
\begin_inset listings
inline false
status open

\begin_layout Plain Layout

scala> for {x <- Some(3); y <- Some(4)} yield x * y
\end_layout

\begin_layout Plain Layout

res1: Option[Int] = Some(12)
\end_layout

\end_inset

 
\end_layout

\begin_layout Standard
"That's nice, you just wrote a lot of code to multiply 3 by 4."
\end_layout

\begin_layout Standard
Let's see what happens if we have a "None" in there:
\end_layout

\begin_layout Standard
\begin_inset listings
inline false
status open

\begin_layout Plain Layout

scala> val yOpt: Option[Int] = None
\end_layout

\begin_layout Plain Layout

yOpt: Option[Int] = None 
\end_layout

\begin_layout Plain Layout

scala> for {x <- Some(3); y <- yOpt} yield x * y
\end_layout

\begin_layout Plain Layout

res3: Option[Int] = None
\end_layout

\end_inset


\end_layout

\begin_layout Standard
So, we get a "
\family typewriter
None
\family default
" back.
 How do we turn this into a default value?
\end_layout

\begin_layout Standard
\begin_inset listings
inline false
status open

\begin_layout Plain Layout

scala> (for {x <- Some(3); y <- yOpt} yield x * y) getOrElse -1
\end_layout

\begin_layout Plain Layout

res4: Int = -1
\end_layout

\end_inset

 
\end_layout

\begin_layout Standard
\begin_inset listings
inline false
status open

\begin_layout Plain Layout

scala> (for {x <- Some(3); y <- Some(4)} yield x * y) getOrElse -1
\end_layout

\begin_layout Plain Layout

res5: Int = 12
\end_layout

\end_inset


\end_layout

\begin_layout Standard
Note that the "
\family typewriter
getOrElse
\family default
" code is "passed by name".
 Put another way, that code is only executed if the "else" clause is valid.
\end_layout

\begin_layout Standard
Lift has an analogous construct called 
\family typewriter
Box
\family default
.
\end_layout

\begin_layout Standard
A 
\family typewriter
Box
\family default
 can be 
\family typewriter
Full
\family default
 or not.
 A non-
\family typewriter
Full
\family default
 
\family typewriter
Box
\family default
 can be the 
\family typewriter
Empty
\family default
 singleton or a 
\family typewriter
Failure
\family default
.
 A 
\family typewriter
Failure
\family default
 carries around information about why the 
\family typewriter
Box
\family default
 contains no value.
\end_layout

\begin_layout Standard

\family typewriter
Failure
\family default
 is very helpful because you can carry around information to display an
 error...
 an HTTP response code, a message, what have you.
\end_layout

\begin_layout Standard
In Lift, I put this all together in the following way:
\end_layout

\begin_layout Itemize
methods that return request parameters return 
\family typewriter
Box[String]
\family default
 
\end_layout

\begin_layout Itemize
finder methods on models (not find all, just the ones that return a single
 instance) return 
\family typewriter
Box[Model]
\end_layout

\begin_layout Itemize
any method that would have returned a null if I was writing in Java returns
 a 
\family typewriter
Box[T]
\family default
 in Lift 
\end_layout

\begin_layout Standard
That means you get code that looks like:
\end_layout

\begin_layout Standard
\begin_inset listings
inline false
status open

\begin_layout Plain Layout

scala> for {id <- S.param("id") ?~ "id param missing"
\end_layout

\begin_layout Plain Layout

u <- getUser(id) ?~ "User not found" 
\end_layout

\begin_layout Plain Layout

} yield u.toXml 
\end_layout

\begin_layout Plain Layout

res6: net.liftweb.common.Box[scala.xml.Elem] = Failure(id param missing,Empty,Empty)
 
\end_layout

\end_inset


\end_layout

\begin_layout Standard
There's no explicit guard/test to see if the "
\family typewriter
id
\family default
" parameter was passed in and there's no explicit test to see if the user
 was found.
\end_layout

\begin_layout Standard
Note also that this code is completely type-safe.
 While there was no explicit type declarations, the compiler was able to
 figure out what types the various objects were.
\end_layout

\begin_layout Standard
So, let's look at the code inside a REST handler:
\end_layout

\begin_layout Standard
\begin_inset listings
inline false
status open

\begin_layout Plain Layout

serve { 
\end_layout

\begin_layout Plain Layout

  case "user" :: "info" :: _ XmlGet _ => 
\end_layout

\begin_layout Plain Layout

    for {
\end_layout

\begin_layout Plain Layout

      id <- S.param("id") ?~ "id param missing" ~> 401 
\end_layout

\begin_layout Plain Layout

      u <- User.find(id) ?~ "User not found" 
\end_layout

\begin_layout Plain Layout

    } yield u.toXml 
\end_layout

\begin_layout Plain Layout

}
\end_layout

\end_inset


\end_layout

\begin_layout Standard
If the 
\family typewriter
id
\family default
 parameter is missing, present a nice error message and return a 401 (okay...
 this is random, but you get the point).
 And by default, if the user isn't found, return a 404 with the error that
 the user isn't found.
\end_layout

\begin_layout Standard
Here's what it looks like using wget:
\end_layout

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

\begin_layout Plain Layout

dpp@bison:~/lift_sbt_prototype$ wget http://localhost:8080/user/info.xml
\end_layout

\begin_layout Plain Layout

--2010-06-01 15:07:27-- http://localhost:8080/user/info.xml
\end_layout

\begin_layout Plain Layout

Resolving localhost...
 ::1, 127.0.0.1 
\end_layout

\begin_layout Plain Layout

Connecting to localhost|::1|:8080...
 connected.
 
\end_layout

\begin_layout Plain Layout

HTTP request sent, awaiting response...
 401 Unauthorized 
\end_layout

\begin_layout Plain Layout

Authorization failed.
\end_layout

\begin_layout Plain Layout

\end_layout

\begin_layout Plain Layout

dpp@bison:~/lift_sbt_prototype$ wget http://localhost:8080/user/info.xml?id=2
\end_layout

\begin_layout Plain Layout

--2010-06-01 15:07:44-- http://localhost:8080/user/info.xml?id=2
\end_layout

\begin_layout Plain Layout

Resolving localhost...
 ::1, 127.0.0.1
\end_layout

\begin_layout Plain Layout

Connecting to localhost|::1|:8080...
 connected.
 
\end_layout

\begin_layout Plain Layout

HTTP request sent, awaiting response...
 404 Not Found 
\end_layout

\begin_layout Plain Layout

2010-06-01 15:07:44 ERROR 404: Not Found.
\end_layout

\begin_layout Plain Layout

\end_layout

\begin_layout Plain Layout

dpp@bison:~/lift_sbt_prototype$ wget http://localhost:8080/user/info.xml?id=1
\end_layout

\begin_layout Plain Layout

--2010-06-01 15:24:12-- http://localhost:8080/user/info.xml?id=1
\end_layout

\begin_layout Plain Layout

Resolving localhost...
 ::1, 127.0.0.1
\end_layout

\begin_layout Plain Layout

Connecting to localhost|::1|:8080...
 connected.
 
\end_layout

\begin_layout Plain Layout

HTTP request sent, awaiting response...
 
\end_layout

\begin_layout Plain Layout

200 OK Length: 274 [text/xml] Saving to: `info.xml?id=1'
\end_layout

\begin_layout Plain Layout

\end_layout

\begin_layout Plain Layout

dpp@bison:~/lift_sbt_prototype$ cat info.xml
\backslash
?id
\backslash
=1
\end_layout

\begin_layout Plain Layout

<?xml version="1.0" encoding="UTF-8"?>
\end_layout

\begin_layout Plain Layout

  <User id="1" firstName="Elwood" ...
 validated="true" superUser="false">
\end_layout

\begin_layout Plain Layout

</User> 
\end_layout

\end_inset


\end_layout

\begin_layout Standard
One more thing about 
\family typewriter
Box
\family default
 and 
\family typewriter
Option
\family default
...
 they lead to less complex, more maintainable code.
 Even if you didn't know anything about Scala or Lift, you can read the
 XML serving code and the console exchange and figure out what happened
 any why it happened.
 This is a lot more readable than deeply nested if statements.
 And if it's readable, it's maintainable.
\end_layout

\begin_layout Standard
I hope this is an understandable introduction to Scala's 
\family typewriter
Option
\family default
 class and 'for' comprehension and how Lift makes use of these tools.
\end_layout

\begin_layout Section
S/SHtml
\begin_inset CommandInset label
LatexCommand label
name "sec:S/SHtml"

\end_inset


\end_layout

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

\end_inset


\end_layout

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

\end_inset


\end_layout

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

\end_inset


\end_layout

\begin_layout Standard
A core concept in Lift is GUIDs.
 GUIDs are globally unique identifiers used to associate something in the
 browser with a function on the server.
 GUIDs make Lift more secure because they make replay attacks very difficult
 and GUIDs make it easier to develop complex, stateful, interactive applications
 because the developer spends more time on business logic and less time
 on the plumbing of it.
\end_layout

\begin_layout Subsection
How GUIDs are generated
\end_layout

\begin_layout Subsection
Where they are used 
\end_layout

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

\end_inset


\end_layout

\begin_layout Section
SessionVars and RequestVars
\begin_inset CommandInset label
LatexCommand label
name "sec:SessionVars-and-RequestVars"

\end_inset


\end_layout

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

\end_inset


\end_layout

\begin_layout Standard
\begin_inset CommandInset include
LatexCommand include
filename "chapters/css_selector_transforms.lyx"

\end_inset


\end_layout

\begin_layout Section
Client-side behavior invoking server-side functions
\begin_inset CommandInset label
LatexCommand label
name "sec:Client-side-behavior-invoking"

\end_inset


\end_layout

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

\end_inset


\end_layout

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

\end_inset


\end_layout

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

\end_inset


\end_layout

\begin_layout Section
Pattern Matching
\begin_inset CommandInset label
LatexCommand label
name "sec:Pattern-Matching"

\end_inset


\end_layout

\begin_layout Section
Type safety
\begin_inset CommandInset label
LatexCommand label
name "sec:Type-safety"

\end_inset


\end_layout

\begin_layout Section
Page rewriting
\begin_inset CommandInset label
LatexCommand label
name "sec:Page-rewriting"

\end_inset


\end_layout

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

\end_inset


\end_layout

\begin_layout Chapter
Common Patterns
\end_layout

\begin_layout Standard
\begin_inset CommandInset include
LatexCommand include
filename "localization.lyx"

\end_inset


\end_layout

\begin_layout Standard

\end_layout

\begin_layout Section
Dependency Injection
\begin_inset CommandInset label
LatexCommand label
name "sec:Dependency-Injection"

\end_inset


\end_layout

\begin_layout Standard
Dependency injection is an important topic in the Java world.
 It's important because Java lacks certain basic features (e.g., functions)
 that tend to bind abstract interfaces to concrete implementations.
 Basically, it's so much easier to do 
\family typewriter
MyInterface thing = new MyInterfaceImpl()
\family default
, so most developers do just that.
 
\end_layout

\begin_layout Standard
Scala's 
\begin_inset CommandInset href
LatexCommand href
name "cake pattern"
target "http://scala.sygneca.com/patterns/component-mixins"

\end_inset

 goes a long way to help developers compose complex behaviors by combining
 Scala traits.
 Jonas Bonér wrote an excellent piece on 
\begin_inset CommandInset href
LatexCommand href
name "Dependency Injection"
target "http://jonasboner.com/2008/10/06/real-world-scala-dependency-injection-di.html"

\end_inset

.
\end_layout

\begin_layout Standard
The cake pattern only goes half way to giving a Java developer complete
 dependency injection functionality.
 The cake pattern allows you to compose the complex classes out of Scala
 traits, but the cake pattern is less helpful in terms of allowing you to
 make dynamic choices about which combination of cake to vend in a given
 situation.
 Lift provides extra features that complete the dependency injection puzzle.
 
\end_layout

\begin_layout Subsection
Lift Libraries and Injector
\end_layout

\begin_layout Standard
Lift is both a web framework and a set of Scala libraries.
 Lift's 
\family typewriter
common
\family default
, 
\family typewriter
actor
\family default
, 
\family typewriter
json
\family default
, and 
\family typewriter
util
\family default
 packages provide common libraries for Scala developers to build their applicati
on.
 Lift's libraries are well tested, widely used, well supported, and released
 on a well defined schedule (montly milestones, quarterly releases).
 
\end_layout

\begin_layout Standard
Lift's 
\family typewriter
Injector
\family default
 trait forms the basis of dependency injection: 
\end_layout

\begin_layout Standard
\begin_inset listings
inline false
status open

\begin_layout Plain Layout

/** 
\end_layout

\begin_layout Plain Layout

 * A trait that does basic dependency injection.
\end_layout

\begin_layout Plain Layout

 */
\end_layout

\begin_layout Plain Layout

trait Injector {
\end_layout

\begin_layout Plain Layout

  implicit def inject[T](implicit man: Manifest[T]): Box[T]
\end_layout

\begin_layout Plain Layout

}
\end_layout

\end_inset


\end_layout

\begin_layout Standard
You can use this trait as follows: 
\end_layout

\begin_layout Standard
\begin_inset listings
inline false
status open

\begin_layout Plain Layout

object MyInjector extends Injector {...}
\end_layout

\begin_layout Plain Layout

\end_layout

\begin_layout Plain Layout

val myThing: Box[Thing] = MyInjector.inject
\end_layout

\end_inset


\end_layout

\begin_layout Standard
The reason that the instance of 
\family typewriter
MyThing
\family default
 is in a 
\family typewriter
Box
\family default
 is because we're not guaranteed that 
\family typewriter
MyInjector
\family default
 knows how to create an instance of 
\family typewriter
Thing
\family default
.
 Lift provides an implementation of 
\family typewriter
Injector
\family default
 called 
\family typewriter
SimpleInjector
\family default
 that allows you to register (and re-register) functions for injection:
\end_layout

\begin_layout Standard
\begin_inset listings
inline false
status open

\begin_layout Plain Layout

object MyInjector extends SimpleInjector
\end_layout

\begin_layout Plain Layout

\end_layout

\begin_layout Plain Layout

def buildOne(): Thing = if (testMode) new Thing with TestThingy {} else
 new Thing with RuntimeThingy {}
\end_layout

\begin_layout Plain Layout

\end_layout

\begin_layout Plain Layout

MyInjector.registerInjection(buildOne _) // register the function that builds
 Thing 
\end_layout

\begin_layout Plain Layout

\end_layout

\begin_layout Plain Layout

val myThing: Box[Thing] = MyInjector.inject
\end_layout

\end_inset


\end_layout

\begin_layout Standard
This isn't bad...
 it allows us to define a function that makes the injection-time decision,
 and we can change the function out during runtime (or test-time.) However,
 there are two problems: getting Boxes for each injection is less than optimal.
 Further, globally scoped functions mean you have to put a whole bunch of
 logic (test vs.
 production vs.
 xxx) into the function.
 
\family typewriter
SimpleInjector
\family default
 has lots of ways to help out.
\end_layout

\begin_layout Standard
\begin_inset listings
inline false
status open

\begin_layout Plain Layout

object MyInjector extends SimpleInjector {
\end_layout

\begin_layout Plain Layout

  val thing = new Inject(buildOne _) {} // define a thing, has to be a val
 so it's eagerly evaluated and registered
\end_layout

\begin_layout Plain Layout

}
\end_layout

\begin_layout Plain Layout

\end_layout

\begin_layout Plain Layout

def buildOne(): Thing = if (testMode) new Thing with TestThingy {} else
 new Thing with RuntimeThingy {} 
\end_layout

\begin_layout Plain Layout

\end_layout

\begin_layout Plain Layout

val myThingBox: Box[Thing] = MyInjector.injectval 
\end_layout

\begin_layout Plain Layout

\end_layout

\begin_layout Plain Layout

myThing = MyInjector.thing.vend // vend an instance of Thing 
\end_layout

\end_inset


\end_layout

\begin_layout Standard

\family typewriter
Inject
\family default
 has a futher trick up its sleave...
 with 
\family typewriter
Inject
\family default
, you can scope the function...
 this is helpful for testing and if you need to change behavior for a particular
 call scope:
\end_layout

\begin_layout Standard
\begin_inset listings
inline false
status open

\begin_layout Plain Layout

MyInjector.thing.doWith(new Thing with SpecialThing {}) { 
\end_layout

\begin_layout Plain Layout

  val t = MyInjector.thing.vend // an instance of SpecialThing 
\end_layout

\begin_layout Plain Layout

  val bt: Box[Thing] = MyInjector.inject // Full(SpecialThing) 
\end_layout

\begin_layout Plain Layout

}
\end_layout

\begin_layout Plain Layout

\end_layout

\begin_layout Plain Layout

MyInjector.thing.default.set(() => new Thing with YetAnotherThing {}) // set
 the global scope 
\end_layout

\end_inset


\end_layout

\begin_layout Standard
Within the scope of the 
\family typewriter
doWith
\family default
 call, 
\family typewriter
MyInjector.thing
\family default
 will vend instances of 
\family typewriter
SpecialThing
\family default
.
 This is useful for testing as well as changing behavior within the scope
 of the call or globally.
 This gives us much of the functionality we get with dependency injection
 packages for Java.
 But within Lift WebKit, it gets better.
\end_layout

\begin_layout Subsection
Lift WebKit and enhanced injection scoping 
\end_layout

\begin_layout Standard
Lift's WebKit offers broad ranging tools for handling HTTP requests as well
 as HTML manipulation.
\end_layout

\begin_layout Standard
Lift WebKit's 
\family typewriter
Factory
\family default
 extends 
\family typewriter
SimpleInjector
\family default
, but adds the ability to scope the function based on current HTTP request
 or the current container session:
\end_layout

\begin_layout Standard
\begin_inset listings
inline false
status open

\begin_layout Plain Layout

object MyInjector extends Factory { 
\end_layout

\begin_layout Plain Layout

  val thing = new FactoryMaker(buildOne _) {} // define a thing, has to
 be a val so it's eagerly 
\end_layout

\begin_layout Plain Layout

                                              // evaluated and registered
\end_layout

\begin_layout Plain Layout

} 
\end_layout

\begin_layout Plain Layout

\end_layout

\begin_layout Plain Layout

MyInjector.thing.session.set(new Thing with ThingForSession {}) // set the
 instance that will be vended 
\end_layout

\begin_layout Plain Layout

                                                                // for the
 duration of the session 
\end_layout

\begin_layout Plain Layout

\end_layout

\begin_layout Plain Layout

MyInjector.thing.request.set(new Thing with ThingForRequest {}) // set the
 instance that will be vended 
\end_layout

\begin_layout Plain Layout

                                                                // for the
 duration of the request
\end_layout

\end_inset

 
\end_layout

\begin_layout Standard
WebKit's 
\family typewriter
LiftRules
\family default
 is a 
\family typewriter
Factory
\family default
 and many of the properties that 
\family typewriter
LiftRules
\family default
 contains are 
\family typewriter
FactoryMakers
\family default
.
 This means that you can change behavior during call scope (useful for testing):
\end_layout

\begin_layout Standard
\begin_inset listings
inline false
status open

\begin_layout Plain Layout

LiftRules.convertToEntity.doWith(true) { ...
 test that we convert certain characters to entities} 
\end_layout

\end_inset


\end_layout

\begin_layout Standard
Or based on the current request (for example you can change the rules for
 calculating the docType during the current request):
\end_layout

\begin_layout Standard
\begin_inset listings
inline false
status open

\begin_layout Plain Layout

if (isMobileReqest) LiftRules.docType.request.set((r: Req) => Full(DocType.xhtmlMobi
le))
\end_layout

\end_inset


\end_layout

\begin_layout Standard
Or based on the current session (for example, changing maxConcurrentRequests
 based on some rules when a session is created):
\end_layout

\begin_layout Standard
\begin_inset listings
inline false
status open

\begin_layout Plain Layout

if (browserIsSomethingElse) LiftRules.maxConcurrentRequests.session.set((r:
 Req) => 32) 
\end_layout

\begin_layout Plain Layout

              // for this session, we allow 32 concurrent requests 
\end_layout

\end_inset


\end_layout

\begin_layout Subsection
Conclusion 
\end_layout

\begin_layout Standard
Lift's 
\family typewriter
SimpleInjector
\family default
/
\family typewriter
Factory
\family default
 facilities provide a powerful and flexible mechanism for vending instances
 based on a global function, call stack scoping, request and session scoping
 and provides more flexible features than most Java-based dependency injection
 frameworks without resorting to XML for configuration or byte-code rewriting
 magic.
\end_layout

\begin_layout Section
Modules
\end_layout

\begin_layout Standard
Lift has supported modules from the first version of the project in 2007.
 Lift's entire handling of the HTTP request/response cycle is open to hooks.
 Further, Lift's templating mechanism where resulting HTML pages are composed
 by transforming page content via snippets (See 
\begin_inset CommandInset ref
LatexCommand prettyref
reference "sec:Snippets"

\end_inset

) which are simply functions that take HTML and return HTML: 
\family typewriter
NodeSeq => NodeSeq
\family default
.
 Because Lift's snippet resolution mechanism is open and any code referenced
 in Boot (See 
\begin_inset CommandInset ref
LatexCommand prettyref
reference "sec:Boot"

\end_inset

), any code can be a Lift 
\begin_inset Quotes eld
\end_inset

module
\begin_inset Quotes erd
\end_inset

 by virtue of registering its snippets and other resources in 
\family typewriter
LiftRules
\family default
.
 Many Lift modules already exist including PayPal, OAuth, OpenID, LDAP,
 and even a module containing many jQuery widgets.
\end_layout

\begin_layout Standard
The most difficult issue relating to integration of external modules into
 Lift is how to properly insert the module's menu items into a SiteMap (See
 
\begin_inset CommandInset ref
LatexCommand prettyref
reference "sec:SiteMap-1"

\end_inset

) menu hierarchy.
 Lift 2.2 introduces a more flexible mechanism for mutating the 
\family typewriter
SiteMap
\family default
: 
\family typewriter
SiteMap
\family default
 mutators.
 
\family typewriter
SiteMap
\family default
 mutators are functions that rewrite the SiteMap based on rules for where
 to insert the module's menus in the menu hierarchy.
 Each module may publish markers.
 For example, here are the markers for ProtoUser:
\end_layout

\begin_layout Standard
\begin_inset listings
inline false
status open

\begin_layout Plain Layout

/**
\end_layout

\begin_layout Plain Layout

* Insert this LocParam into your menu if you want the
\end_layout

\begin_layout Plain Layout

* User's menu items to be inserted at the same level
\end_layout

\begin_layout Plain Layout

* and after the item
\end_layout

\begin_layout Plain Layout

*/
\end_layout

\begin_layout Plain Layout

final case object AddUserMenusAfter extends Loc.LocParam[Any]
\end_layout

\begin_layout Plain Layout

/**
\end_layout

\begin_layout Plain Layout

* replace the menu that has this LocParam with the User's menu
\end_layout

\begin_layout Plain Layout

* items
\end_layout

\begin_layout Plain Layout

*/
\end_layout

\begin_layout Plain Layout

final case object AddUserMenusHere extends Loc.LocParam[Any]
\end_layout

\begin_layout Plain Layout

/**
\end_layout

\begin_layout Plain Layout

* Insert this LocParam into your menu if you want the
\end_layout

\begin_layout Plain Layout

* User's menu items to be children of that menu
\end_layout

\begin_layout Plain Layout

*/
\end_layout

\begin_layout Plain Layout

final case object AddUserMenusUnder extends Loc.LocParam[Any]
\end_layout

\end_inset


\end_layout

\begin_layout Standard
The module also makes a 
\family typewriter
SiteMap
\family default
 mutator available, this can either be returned from the module's 
\family typewriter
init
\family default
 method or via some other method on the module.
 ProtoUser makes the 
\family typewriter
sitemapMutator
\family default
 method available which returns a 
\family typewriter
SiteMap => SiteMap
\family default
.
\end_layout

\begin_layout Standard
The application can add the marker to the appropriate menu item:
\end_layout

\begin_layout Standard
\begin_inset listings
inline false
status open

\begin_layout Plain Layout

Menu("Home") / "index" >> User.AddUserMenusAfter
\end_layout

\end_inset


\end_layout

\begin_layout Standard
And when the application registers the 
\family typewriter
SiteMap
\family default
 with 
\family typewriter
LiftRules
\family default
, it applies the mutator:
\end_layout

\begin_layout Standard
\begin_inset listings
inline false
status open

\begin_layout Plain Layout

LiftRules.setSiteMapFunc(() => User.sitemapMutator(sitemap()))
\end_layout

\end_inset


\end_layout

\begin_layout Standard
Because the mutators are composable:
\end_layout

\begin_layout Standard
\begin_inset listings
inline false
status open

\begin_layout Plain Layout

val allMutators = User.sitemapMutator andThen FruitBat.sitemapMutator
\end_layout

\begin_layout Plain Layout

LiftRules.setSiteMapFunc(() => allMutators(sitemap()))
\end_layout

\end_inset


\end_layout

\begin_layout Standard
For each module, the implementation of the mutators is pretty simple:
\end_layout

\begin_layout Standard
\begin_inset listings
inline false
status open

\begin_layout Plain Layout

  private lazy val AfterUnapply = SiteMap.buildMenuMatcher(_ == AddUserMenusAfter
)
\end_layout

\begin_layout Plain Layout

  private lazy val HereUnapply = SiteMap.buildMenuMatcher(_ == AddUserMenusHere)
\end_layout

\begin_layout Plain Layout

  private lazy val UnderUnapply = SiteMap.buildMenuMatcher(_ == AddUserMenusUnder
)
\end_layout

\begin_layout Plain Layout

\end_layout

\begin_layout Plain Layout

  /**
\end_layout

\begin_layout Plain Layout

   * The SiteMap mutator function
\end_layout

\begin_layout Plain Layout

   */
\end_layout

\begin_layout Plain Layout

  def sitemapMutator: SiteMap => SiteMap = SiteMap.sitemapMutator {
\end_layout

\begin_layout Plain Layout

    case AfterUnapply(menu) => menu :: sitemap
\end_layout

\begin_layout Plain Layout

    case HereUnapply(_) => sitemap
\end_layout

\begin_layout Plain Layout

    case UnderUnapply(menu) => List(menu.rebuild(_ ::: sitemap))
\end_layout

\begin_layout Plain Layout

  }(SiteMap.addMenusAtEndMutator(sitemap))
\end_layout

\end_inset


\end_layout

\begin_layout Standard
We've defined some extractors that help with pattern matching.
 
\family typewriter
SiteMap.buildMenuMatcher
\family default
 is a helper method to make building the extractors super-simple.
 Then we supply a 
\family typewriter
PartialFunction[Menu, List[Menu]]
\family default
 which looks for the marker 
\family typewriter
LocParam
\family default
 and re-writes the menu based on the marker.
 If there are no matches, the additional rule is fired, in this case, we
 append the menus at the end of the 
\family typewriter
SiteMap
\family default
.
\end_layout

\begin_layout Standard
\begin_inset CommandInset include
LatexCommand include
filename "htmlproperties.lyx"

\end_inset


\end_layout

\begin_layout Chapter
Built-in Snippets
\end_layout

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

\end_inset


\end_layout

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

\end_inset

Msgs
\end_layout

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

\end_inset

Msg
\end_layout

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

\end_inset

Menu
\end_layout

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

\end_inset

A
\end_layout

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

\end_inset

Children
\end_layout

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

\end_inset

Comet
\end_layout

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

\end_inset

Form
\end_layout

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

\end_inset

Ignore
\end_layout

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

\end_inset

Loc
\end_layout

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

\end_inset

Surround
\end_layout

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

\end_inset

TestCond
\end_layout

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

\end_inset

Embed
\end_layout

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

\end_inset

Tail
\end_layout

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

\end_inset

WithParam
\end_layout

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

\end_inset

VersionInfo
\end_layout

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

\end_inset

SkipDocType
\end_layout

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

\end_inset

XmlGroup
\end_layout

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

\end_inset

LazyLoad
\end_layout

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

\end_inset

WithResourceId
\end_layout

\begin_layout Chapter
SiteMap
\end_layout

\begin_layout Chapter
\begin_inset CommandInset label
LatexCommand label
name "cha:REST"

\end_inset

REST
\end_layout

\begin_layout Standard
Lift makes providing REST-style web services very simple.
\end_layout

\begin_layout Standard
First, create an object that extends 
\family typewriter
RestHelper
\family default
:
\end_layout

\begin_layout Standard
\begin_inset listings
inline false
status open

\begin_layout Plain Layout

import net.liftweb.http._
\end_layout

\begin_layout Plain Layout

import net.liftweb.http.rest._
\end_layout

\begin_layout Plain Layout

\end_layout

\begin_layout Plain Layout

object MyRest extends RestHelper {
\end_layout

\begin_layout Plain Layout

  
\end_layout

\begin_layout Plain Layout

}
\end_layout

\end_inset


\end_layout

\begin_layout Standard
And hook your changes up to Lift in 
\family typewriter
Boot.scala
\family default
:
\end_layout

\begin_layout Standard
\begin_inset listings
inline false
status open

\begin_layout Plain Layout

LiftRules.dispatch.append(MyRest) // stateful -- associated with a servlet
 container session
\end_layout

\begin_layout Plain Layout

LiftRules.statelessDispatchTable.append(MyRest) // stateless -- no session
 created
\end_layout

\end_inset


\end_layout

\begin_layout Standard
Within your MyRest object, you can define which URLs to serve:
\end_layout

\begin_layout Standard
\begin_inset listings
inline false
status open

\begin_layout Plain Layout

serve { 
\end_layout

\begin_layout Plain Layout

  case Req("api" :: "static" :: _, "xml", GetRequest) => <b>Static</b> 
\end_layout

\begin_layout Plain Layout

  case Req("api" :: "static" :: _, "json", GetRequest) => JString("Static")
 
\end_layout

\begin_layout Plain Layout

}
\end_layout

\end_inset

 
\end_layout

\begin_layout Standard
The above code uses the suffix of the request to determine the response
 type.
 Lift supports testing the 
\family typewriter
Accept
\family default
 header for a response type:
\end_layout

\begin_layout Standard
\begin_inset listings
inline false
status open

\begin_layout Plain Layout

serve { 
\end_layout

\begin_layout Plain Layout

  case XmlGet("api" :: "static" :: _, _) => <b>Static</b> 
\end_layout

\begin_layout Plain Layout

  case JsonGet("api" :: "static" :: _, _) => JString("Static") 
\end_layout

\begin_layout Plain Layout

}
\end_layout

\end_inset

 
\end_layout

\begin_layout Standard
The above can also be written:
\end_layout

\begin_layout Standard
\begin_inset listings
inline false
status open

\begin_layout Plain Layout

serve { 
\end_layout

\begin_layout Plain Layout

  case "api" :: "static" :: _ XmlGet _=> <b>Static</b> 
\end_layout

\begin_layout Plain Layout

  case "api" :: "static" :: _ JsonGet _ => JString("Static") 
\end_layout

\begin_layout Plain Layout

} 
\end_layout

\end_inset


\end_layout

\begin_layout Standard
Note: If you want to navigate your Web Service, you must remember to add
 a 
\family typewriter
*.xml
\family default
 or 
\family typewriter
*.json
\family default
 (depending in what you have implemented) at the end of the URL: 
\family typewriter
http://localhost:8080/XXX/api/static/call.json
\family default
 
\family typewriter
http://localhost:8080/XXX/api/static/call.xml
\family default
 
\end_layout

\begin_layout Standard
Because the REST dispatch code is based on Scala’s pattern matching, we
 can extract elements from the request (in this case the third element will
 be extracted into the id variable which is a String:
\end_layout

\begin_layout Standard
\begin_inset listings
inline false
status open

\begin_layout Plain Layout

serve { 
\end_layout

\begin_layout Plain Layout

  case "api" :: "user" :: id :: _ XmlGet _ => <b>ID: {id}</b>
\end_layout

\begin_layout Plain Layout

  case "api" :: "user" :: id :: _ JsonGet _ => JString(id) 
\end_layout

\begin_layout Plain Layout

} 
\end_layout

\end_inset

And with extractors, we convert an element to a particular type and only
 succeed with the pattern match (and the dispatch) if the parameter can
 be converted.
 For example:
\end_layout

\begin_layout Standard
\begin_inset listings
inline false
status open

\begin_layout Plain Layout

serve { 
\end_layout

\begin_layout Plain Layout

  case "api" :: "user" :: AsLong(id) :: _ XmlGet _ => <b>ID: {id}</b>
\end_layout

\begin_layout Plain Layout

  case "api" :: "user" :: AsLong(id) :: _ JsonGet _ => JInt(id) 
\end_layout

\begin_layout Plain Layout

} 
\end_layout

\end_inset


\end_layout

\begin_layout Standard
In the above example, id is extracted if it can be converted to a Long.
\end_layout

\begin_layout Standard
Lift’s REST helper can also extract 
\family typewriter
XML
\family default
 or 
\family typewriter
JSON
\family default
 from a 
\family typewriter
POST
\family default
 or 
\family typewriter
PUT
\family default
 request and only dispatch the request if the XML or JSON is valid:
\end_layout

\begin_layout Standard
\begin_inset listings
inline false
status open

\begin_layout Plain Layout

serve { 
\end_layout

\begin_layout Plain Layout

  case "api" :: "user" :: _ XmlPut xml -> _ => // xml is a scala.xml.Node
 
\end_layout

\begin_layout Plain Layout

    User.createFromXml(xml).map { u => u.save; u.toXml}
\end_layout

\begin_layout Plain Layout

\end_layout

\begin_layout Plain Layout

  case "api" :: "user" :: _ JsonPut json -> _ => // json is a net.liftweb.json.Json
AST.JValue
\end_layout

\begin_layout Plain Layout

    User.createFromJson(json).map { u => u.save; u.toJson} 
\end_layout

\begin_layout Plain Layout

} 
\end_layout

\end_inset


\end_layout

\begin_layout Standard
There may be cases when you want to have a single piece of business logic
 to calculate a value, but then convert the value to a result based on the
 request type.
 That’s where 
\family typewriter
serveJx
\family default
 comes in … it’ll serve a response for 
\family typewriter
JSON
\family default
 and 
\family typewriter
XML
\family default
 requests.
 If you define a trait called 
\family typewriter
Convertable
\family default
:
\end_layout

\begin_layout Standard
\begin_inset listings
inline false
status open

\begin_layout Plain Layout

trait Convertable {
\end_layout

\begin_layout Plain Layout

  def toXml: Elem 
\end_layout

\begin_layout Plain Layout

  def toJson: JValue 
\end_layout

\begin_layout Plain Layout

}
\end_layout

\end_inset


\end_layout

\begin_layout Standard
Then define a pattern that will convert from a 
\family typewriter
Convertable
\family default
 to a 
\family typewriter
JSON
\family default
 or 
\family typewriter
XML
\family default
:
\end_layout

\begin_layout Standard
implicit def cvt: JxCvtPF[Convertable] = { case (JsonSelect, c, _) => c.toJson
 case (XmlSelect, c, _) => c.toXml } 
\end_layout

\begin_layout Standard
And anywhere you use 
\family typewriter
serveJx
\family default
 and your pattern results in a 
\family typewriter
Box[Convertable]
\family default
, the 
\family typewriter
cvt
\family default
 pattern is used to generate the appropriate response:
\end_layout

\begin_layout Standard
\begin_inset listings
inline false
status open

\begin_layout Plain Layout

serveJx { 
\end_layout

\begin_layout Plain Layout

  case Get("api" :: "info" :: Info(info) :: _, _) => Full(info) 
\end_layout

\begin_layout Plain Layout

}
\end_layout

\end_inset


\end_layout

\begin_layout Standard
Or:
\end_layout

\begin_layout Standard
\begin_inset listings
inline false
status open

\begin_layout Plain Layout

// extract the parameters, create a user 
\end_layout

\begin_layout Plain Layout

// return the appropriate response 
\end_layout

\begin_layout Plain Layout

\end_layout

\begin_layout Plain Layout

def addUser(): Box[UserInfo] = 
\end_layout

\begin_layout Plain Layout

  for { 
\end_layout

\begin_layout Plain Layout

    firstname <- S.param("firstname") ?~ "firstname parameter missing" ~>
 400 
\end_layout

\begin_layout Plain Layout

    lastname <- S.param("lastname") ?~ "lastname parameter missing" 
\end_layout

\begin_layout Plain Layout

    email <- S.param("email") ?~ "email parameter missing" 
\end_layout

\begin_layout Plain Layout

  } yield { 
\end_layout

\begin_layout Plain Layout

    val u = User.create.firstName(firstname).
 
\end_layout

\begin_layout Plain Layout

      lastName(lastname).email(email)
\end_layout

\begin_layout Plain Layout

\end_layout

\begin_layout Plain Layout

    S.param("password") foreach u.password.set
\end_layout

\begin_layout Plain Layout

    u.saveMe 
\end_layout

\begin_layout Plain Layout

  }
\end_layout

\begin_layout Plain Layout

\end_layout

\begin_layout Plain Layout

serveJx {
\end_layout

\begin_layout Plain Layout

  case Post("api" :: "add_user" :: _, _) => addUser() 
\end_layout

\begin_layout Plain Layout

}
\end_layout

\end_inset


\end_layout

\begin_layout Standard
In the above example, if the 
\family typewriter
firstname
\family default
 parameter is missing, the response will be a 400 with the response body
 “firstname parameter missing”.
 If the 
\family typewriter
lastname
\family default
 parameter is missing, the response will be a 404 with the response body
 “lastname parameter missing”.
\end_layout

\begin_layout Chapter
MVC (If you really want it)
\end_layout

\begin_layout Standard
\begin_inset CommandInset include
LatexCommand include
filename "samples/from_mvc/from_mvc.lyx"

\end_inset


\end_layout

\begin_layout Part
Recipes
\end_layout

\begin_layout Standard
\begin_inset CommandInset include
LatexCommand include
filename "chapters/Recipes.lyx"

\end_inset


\end_layout

\begin_layout Standard
\begin_inset CommandInset include
LatexCommand include
filename "chapters/Recipes2.lyx"

\end_inset


\end_layout

\begin_layout Chapter
Embedding JavaScript in an HTML page
\end_layout

\begin_layout Section
Problem
\end_layout

\begin_layout Standard
What am I doing wrong? I'm trying to output a javascript object into the
 page (so my front end guy can do some stuff with the data without parsing
 it out of elements by id) but it's replacing all the double quotes with
 
\family typewriter
&quot;
\family default
 (only in view source - if I inspect it then firebug converts them to double
 quotes again)
\end_layout

\begin_layout Standard
I've copied the example from 
\noun on
Exploring Lift
\noun default
, but it still does the same:
\end_layout

\begin_layout Standard
\begin_inset listings
inline false
status open

\begin_layout Plain Layout

& ".data_as_object *" #> {
\end_layout

\begin_layout Plain Layout

   JsCrVar("myObject", JsObj(("persons", JsArray(
\end_layout

\begin_layout Plain Layout

       JsObj(("name", "Thor"), ("race", "Asgard")),
\end_layout

\begin_layout Plain Layout

       JsObj(("name", "Todd"), ("race", "Wraith")),
\end_layout

\begin_layout Plain Layout

       JsObj(("name", "Rodney"), ("race", "Human"))
\end_layout

\begin_layout Plain Layout

   ))))
\end_layout

\end_inset


\end_layout

\begin_layout Standard
Becomes:
\end_layout

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

\begin_layout Plain Layout

<div class="data_as_object" style="display: none;">var myObject =
\end_layout

\begin_layout Plain Layout

{&quot;persons&quot;: [{&quot;name&quot;: &quot;Thor&quot;,
\end_layout

\begin_layout Plain Layout

&quot;race&quot;: &quot;Asgard&quot;}, {&quot;name&quot;:
\end_layout

\begin_layout Plain Layout

&quot;Todd&quot;, &quot;race&quot;: &quot;Wraith&quot;},
\end_layout

\begin_layout Plain Layout

{&quot;name&quot;: &quot;Rodney&quot;, &quot;race&quot;:
\end_layout

\begin_layout Plain Layout

&quot;Human&quot;}]
\end_layout

\begin_layout Plain Layout

};</div>
\end_layout

\end_inset


\end_layout

\begin_layout Standard
I've noticed that if what I'm outputting is a number rather than a string
 then it's fine.
\end_layout

\begin_layout Section
Solution
\end_layout

\begin_layout Standard
Try:
\end_layout

\begin_layout Standard
\begin_inset listings
inline false
status open

\begin_layout Plain Layout

& ".data_as_object *" #> {
\end_layout

\begin_layout Plain Layout

   Script(JsCrVar("myObject", JsObj(("persons", JsArray(
\end_layout

\begin_layout Plain Layout

\end_layout

\begin_layout Plain Layout

       JsObj(("name", "Thor"), ("race", "Asgard")),
\end_layout

\begin_layout Plain Layout

       JsObj(("name", "Todd"), ("race", "Wraith")),
\end_layout

\begin_layout Plain Layout

       JsObj(("name", "Rodney"), ("race", "Human"))
\end_layout

\begin_layout Plain Layout

   )))))
\end_layout

\end_inset


\end_layout

\begin_layout Standard

\family typewriter
JsExp
\family default
 are also 
\family typewriter
Node
\family default
s, so they render out, but they render out escaped.
 Putting 
\family typewriter
Script()
\family default
 around them turns them into:
\end_layout

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

\begin_layout Plain Layout

<script>
\end_layout

\begin_layout Plain Layout

// <![CDATA[
\end_layout

\begin_layout Plain Layout

....
\end_layout

\begin_layout Plain Layout

]]>
\end_layout

\begin_layout Plain Layout

</script>
\end_layout

\end_inset


\end_layout

\begin_layout Part
Questions and Answers
\end_layout

\begin_layout Chapter
\begin_inset CommandInset label
LatexCommand label
name "cha:Scaling"

\end_inset

Scaling
\end_layout

\begin_layout Standard
Lift is a web framework built on the Scala programming language.
 Lift takes advantage of many of Scala's features that allow developers
 to very concisely code secure, scalable, highly interactive web applications.
 Lift provides a full set of layered abstractions on top of HTTP and HTML
 from "close to the metal" REST abstractions up to transportation agnostic
 server push (Comet) support.
 Scala compiles to JVM byte-code and is compatible with Java libraries and
 the Java object model.
 Lift applications are typically deployed as WAR files in J/EE web containers...
 Lift apps run in Tomcat, Jetty, Glassfish, etc.
 just like any other J/EE web application.
 Lift apps can generally be monitored and managed just like any Java web
 app.
 Web Applications, Sessions, and State.
 All web applications are stateful in one way or another.
 Even a "static" web site is made up of the files that are served...
 the application's state is defined in those files.
 The site content may be served out of a database, but the content served
 does not depend on identity of the user or anything about the HTTP request
 except the contents of the HTTP request.
 These contents can include the URI, parameters, and headers.
 The complete value of the response can be calculated from the request without
 referencing any resources except the content resources.
 For the purpose of this discussion, I will refer to these as session-less
 requests.
 News sites like the UK Guardian, MSNBC, and others are prototypical examples
 of this kind of site.
 Sessions.
 Some applications are customized on a user-by-user basis.
 These applications include the likes of Foursquare and others where many
 HTTP requests make up a "session" in which the results of previous HTTP
 requests change the behavior of future HTTP requests.
 Put in concrete terms, a user can log into a site and for some duration,
 the responses are specific to that user.
 There are many mechanisms for managing sessions, but the most common and
 secure method is creating a cryptographically unique token (a session id),
 and putting that token in the Set-Cookie response header such that the
 browser will present that Cookie in subsequent HTTP requests for a certain
 period of time.
 The server-side state is referenced by the Cookie and the state is made
 available to the web application during the scope of servicing the request
 and any mutations the web app makes to session state during the request
 are kept on the server and are available to the application in subsequent
 requests.
 Another available technique for managing state is to serialize application
 state in the Cookie and deliver it to the browser such that the server
 is not responsible for managing state across requests.
 As we've recently discovered, this is a tremendously insecure way to manage
 application state.
 Further, for any moderately complex application, the amount of data the
 needs to be transferred as part of each request and response is huge.
 Migratory Sessions.
 Many web application managers allow for server-managed sessions to migrate
 across a cluster of web application servers.
 In some environments such as Ruby on Rails, this is a hard requirement
 because only one request at a time can be served per process, thus for
 any moderate traffic site, there must be multiple processes serving pages.
 There are many strategies for migrating state across processes: storing
 state on disk, in memcached, in a database (relational or NoSQL), or having
 some proprietary cluster communications protocol.
 In any of these scenarios sessions can migrate across the grid of processes
 serving requests for a given web application.
 Web applications that support migratory state are often referred to as
 "stateless" because the session state does not reside in the same process
 as the web application.
 Session Affinity.
 Some applications require that all requests related to a particular session
 are routed to the same process and that process keeps session-related content
 in local memory.
 In a cluster, there are multiple mechanisms for achieving session affinity...
 the two most popular being HAProxy and Nginx.
 Availability, Scalability, Security, Performance, and User Experience.
 There are many vectors on which to measure the overall-quality of a web
 application.
 Let's take a quick peek at each one.
 Availability.
 Availability of an application is the amount of time it gives a meaningful
 response to a request.
 Highly available applications generally span multiple pieces of hardware
 and often multiple data centers.
 Highly available applications are also typically available during upgrades
 of part of the system that makes up the application.
 Highly available applications have very few single points of failure and
 those single points of failure are usually deployed on very reliable hardware.
 Scalability.
 A scalable application can, within certain bounds, respond with similar
 performance to increased load by adding hardware to process more load.
 No system is infinitely or linearly scalable.
 However, many systems have grossly disproportionate load demands such that,
 for example, you can add a lot of web application front-ends to a Rails
 application before there's enough load on the back-end RDBMS such that
 scaling is impaired.
\end_layout

\begin_layout Standard
Security.
 The Internet is a dangerous place and no request that is received from
 the Internet can be trusted.
 Applications, frameworks, systems and everything else must be designed
 to be secure and resist attacks.
 The most common attacks on web application are listed in the OWASP Top
 Ten.
 Performance.
 Web application performance can be measured on two vectors: response time
 to a request and system resources required to service the request.
 These two vectors are inter-dependent.
 User Experience.
 The user experience of a web app is an important measure of its quality.
 User experience can be measured on many different vectors including perceived
 responsiveness, visual design, interactivity, lack of "hicups", etc.
 Ultimately, because we're building applications for users, the user experience
 is very important.
 Lift's trade-offs.
 Given the number and complexity related to the quality of a web application,
 there are a lot of trade-offs, implicit and explicit, to building a framework
 that allows developers and business people to deliver a great user experience.
 Let's talk for a minute about what Lift is and what it isn't.
 Lift is a web framework.
 It provides a set of abstractions over HTTP and HTML such that developers
 can write excellent web applications.
 Lift is persistence agnostic.
 You can use Lift with relational databases, file systems, NoSQL data stores,
 mule carts, etc.
 As long as you can materialize an object into the JVM where Lift is running,
 Lift can make use of that object.
 Lift sits on top of the JVM.
 Lift applications execute in the Java Virtual Machine.
 The JVM is a very high performance computing system.
 There are raging debates as to the relative performance of JVM code and
 native machine code.
 No matter which benchmarks you look at, the JVM is a very fast performer.
 Lift apps take advantage of the JVM's performance characteristics.
 Moderately complex Lift apps that access the database can serve 1,000+
 requests per second on quad-core Intel hardware.
 Even very complex Lift apps that make many back-end calls per request can
 serve hundreds of requests per second on EC2 large instances.
 Lift as proxy.
 Many web applications, typically REST applications, provide a very thin
 layer on top of a backing data store.
 The web application serves a few basic functions to broker between the
 HTTP request and the backing store.
 These functions include: request and parameter validation, authentication,
 parameter unpacking, back-end service request, and translation of response
 data to wire format (typically XML or JSON).
 Lift can service these kinds of requests within the scope of a session
 or without any session at all, depending on application design.
 For more information on Lift's REST features, see Lift RestHelper.
 When running these kinds of services, Lift apps can be treated without
 regard for session affinity.
 Lift as HTML generator.
 Lift has a powerful and secure templating mechanism.
 All Lift templates are expressed as valid XML and during the rendering
 process, Lift keeps the page in XML format.
 Pages rendered via Lift's templating mechanism are generally resistant
 to cross site scripting attacks and other attacks that insert malicious
 content in rendered pages.
 Lift's templating mechanism is designer friendly yet supports complex and
 powerful substitution rules.
 Further, the rendered page can be evaluated and transformed during the
 final rendering phase to ensure that all script tags are at the bottom
 of the page, all CSS tags are at the top, etc.
 Lift's templating mechanism can be used to serve sessionless requests or
 serve requests within the context of a session.
 Further, pages can be marked as not requiring a session, yet will make
 session state available if the request was made in the context of a container
 session.
 Lift page rendering can even be done in parallel such that if there are
 long off-process components on the page (e.g., advertising servers), those
 components can be Sessionless Lift, forms and Ajax Lift applications can
 process HTML forms and process Ajax requests even if there's no session
 associated with the request.
 Such forms and Ajax requests have to have stable field names and stable
 URLs, but this is the same requirement as most web frameworks including
 Struts, Rails, and Django impose on their applications.
 In such a mode, Lift apps have the similar characteristics to web apps
 written on tops of Struts, Play, JSF and other popular Java web frameworks.
 Lift as Secure, Interactive App Platform Lift features require session
 affinity: GUID to function mapping, type-safe SessionVars and Comet.
 Applications that take advantage of these features need to have requests
 associated with the JVM that stores the session.
 I'll discuss the reason for this limitation, the down-side to the limitation,
 the downside to migratory session, and the benefits of these features.
 Application servers that support migratory sessions (sessions that are
 available to application servers running in multiple address spaces/processes)
 require a mechanism for transferring the state information between processes.
 This is typically (with the exception of Terracotta) done by serializing
 the stored data.
 Serialization is the process of converting rich data structures into a
 stream of bytes.
 Some of Scala's constructs are hard or impossible to serialize.
 For example, local variables that are mutated within a closure are promoted
 from stack variables to heap variables.
 When those variables are serialized at different times, the application
 winds up with two references even though the references are logically the
 same.
 Lift makes use of many of these constructs (I'll explain why next) and
 Lift's use of these constructs makes session serialization and migration
 impossible.
 It also means that Lift's type-safe SessionVars are not guaranteed to be
 serialized.
 One of the key Lift constructs is to map a cryptographically unique identifier
 in the browser to a function on the server.
 Lift uses Scala functions which close over scope, including all of the
 variables referenced by the function.
 This means that it's not necessary to expose primary keys to the client
 when editing a record in the database because the primary key of the record
 or the record itself is known to the function on the server.
 This guards against OWASP Vulnerability A4, Insecure Object References
 as well as Replay Attacks.
 From the developer's standpoint, writing Lift applications is like writing
 a VisualBasic application...
 the developer associates the user action with a function.
 Lift supplies the plumbing to bridge between the two.
 Lift's GUID to function mapping extends to Lift's Ajax support.
 Associating a button, checkbox, or other HTML element with an Ajax call
 is literally a single line: SHtml.ajaxButton(<b>PressMe</b>, () => Alert("You
 pressed a button at "+Helpers.currentTimeFormatted) Lift's Ajax support
 is simple, maintainable, and secure.
 There's no need to build and maintain routing.
 Lift has the most advanced server-push/Comet support of any web framework
 or any other system currently available.
 Lift's comet support relies on session affinity.
 Lift's comet support associates an Actor with a section of screen real
 estate.
 A single browser window may have many pieces of screen real estate associated
 with many of Lift's CometActors.
 When state changes in the Actor, the state change is pushed to the browser.
 Lift takes care of multiplexing a single HTTP connection to handle all
 the comet items on a given page, the versioning of the change deltas (if
 the HTTP connection is dropped while 3 changes become available, all 3
 of those changes are pushed when the next HTTP request is made.) Further,
 Lift's comet support will work the same way once web sockets are available
 to the client and server...
 there will be no application code changes necessary for web sockets support.
 Lift's comet support requires that the connect is made from the browser
 back to the same JVM in which the CometActors are resident...
 the same JVM where the session is located.
\end_layout

\begin_layout Standard
The downside to Lift's session affinity requirement mainly falls on the
 operations team.
 They must use a session aware load balancer or other mechanism to route
 incoming requests to the server that the session is associated with.
 This is easily accomplished with HAProxy and Nginx.
 Further, if the server running a given session goes down, the information
 associated with that session is lost (note that any information distributed
 off-session [into a database, into a cluster of Akka actors, etc.] is preserved.)
 But, Lift has extended session facilities that support re-creation of session
 information in the event of session lost.
 Lift also has heart-beat functionality so that sessions are kept alive
 as long as a browser page is open to the application, so user inactivity
 will not result in session timeouts.
\end_layout

\begin_layout Standard
Compared to the operational cost of a session aware load balancer, there
 are many costs associated with migratory sessions.
 First, there must be a persistence mechanism for those sessions.
 Memcached is an unreliable mechanism as memcached instances have no more
 stability than the JVM which hosts the application and being a cache, some
 sessions may get expired.
 Putting session data in backing store such as MySQL or Cassandra increases
 the latency of requests.
 Further, the costs of serializing state, transmitting the state across
 the network, storing it, retrieving it, transmitting it across the network,
 and deserializing it all costs a lot of cycles and bandwidth.
 When your Lift application scales beyond a single server, beyond 100 requests
 per second, the costs of migrating state on every request becomes a significant
 operational issue.
\end_layout

\begin_layout Standard
Session serialization can cause session information loss in the case of
 multiple requests being executed in multiple processes.
 It's common to have multiple tabs/windows open to the same application.
 If session data is serialized as a blob and two different requests from
 the same server are being executed at the same time, the last request to
 write session data into the store will over-write the prior session data.
 This is a concurrency problem and can lead to hard to debug issues in productio
n because reproducing this kind of problem is non-trivial and this kind
 of problem is not expected by developers.
\end_layout

\begin_layout Standard
The third issue with migratory sessions and session serialization is that
 the inability to store complex information in the session (e.g., a function
 that closes over scope) means that the developer has to write imperative
 code to serialize session state to implement complex user interactions
 like multi-screen wizards (which is a 400 line implementation in Lift).
 These complex, hand written serializations are error prone, can introduce
 security problems and are non-trivial to maintain.
\end_layout

\begin_layout Standard
The operational costs of supporting session affinity are not materially
 different from the operational costs of providing backing store for migratory
 sessions.
 On the other hand, there are many significant downsides to migratory sessions.
 Let's explore the advantages of Lift's design.
\end_layout

\begin_layout Standard
Lift's use of GUIDs associated with functions on the server: Increase the
 security of the application by guarding against cross site request forgeries,
 replay attacks, and insecure object references Decrease application development
 and maintenance time and costs Increase application interactivity, thus
 a much better user experience Increase in application richness because
 of simpler Ajax, multi-page Wizards, and Comet Improved application performance
 because fewer cycles are spent serializing and transmitting session information
 No difference in scalability...
 just add more servers to the front end to scale the front end of your applicati
on The positive attributes of Lift's design decisions are evident at Foursquare
 which handles thousands of requests per second all served by Lift.
 There are very few sites that have more traffic than Foursquare.
 They have scaled their web front end successfully and securely with Lift.
 Other high volume sites including Novell are successfully scaling with
 Lift.
 If you are scaling your site, there are also commercial Lift Cloud manager
 tools that can help manage clusters of Lift's session requirements.
 Conclusion Lift provides a lot of choices for developing and deploying
 complex web applications.
 Lift can operate in a web container like any other Java web framework.
 If you choose to use certain Lift features and you are deploying across
 multiple servers, you need to have a session aware load balancer.
 Even when using Lift's session-affinity dependent features, Lift applications
 have higher performance, identical availability, identical scalability,
 better security, and better user experience than applications written with
 web frameworks such as Ruby on Rails, Struts, and GWT.
\end_layout

\begin_layout Chapter
How Lift does function/GUID mapping
\end_layout

\begin_layout Chapter
How Lift does Comet
\end_layout

\begin_layout Standard
I can speak to Lift's Comet Architecture which was selected by Novell to
 power their Pulse product after they evaluated a number of different technologi
es.
\end_layout

\begin_layout Standard
Lift's Comet implementation uses a single HTTP connection to poll for changes
 to an arbitrary number of components on the page.
 Each component has a version number.
 The long poll includes the version number and the component GUID.
 On the server side, a listener is attached to all of the GUIDs listed in
 the long poll requests.
 If any of the components has a higher version number (or the version number
 increases during the period of the long poll), the deltas (a set of JavaScript
 describing the change from each version) is sent to the client.
 The deltas are applied and the version number on the client is set to the
 highest version number for the change set.
\end_layout

\begin_layout Standard
Lift integrates long polling with session management so that if a second
 request comes into the same URL during a long poll, the long poll is terminated
 to avoid connection starvation (most browsers have a maximum of 2 HTTP
 connections per named server).
 Lift also supports DNS wild-carded servers for long poll requests such
 that each tab in the browser can do long polling against a different DNS
 wildcarded server.
 This avoids the connection starvation issues.
\end_layout

\begin_layout Standard
Lift dynamically detects the container the Servlet is running in and on
 Jetty 6 & 7 and (soon) Glassfish, Lift will use the platform's "continuations"
 implementation to avoid using a thread during the long poll.
\end_layout

\begin_layout Standard
Lift's JavaScript can sit on top of jQuery and YUI (and could sit on top
 of Prototype/Scriptaculous as well.) The actual polling code includes back-off
 on connection failures and other "graceful" ways of dealing with transient
 connection failures.
\end_layout

\begin_layout Standard
I've looked at Atmosphere and CometD (both JVM-oriented Comet technologies).
 Neither had (at the time I evaluated them) support for multiple components
 per page or connection starvation avoidance.
\end_layout

\begin_layout Standard
\begin_inset CommandInset include
LatexCommand include
filename "chapters/advanced_concepts.lyx"

\end_inset


\end_layout

\begin_layout Part
Misc
\end_layout

\begin_layout Chapter
Releases
\end_layout

\begin_layout Standard
\begin_inset CommandInset include
LatexCommand include
filename "chapters/2_2-RC1.lyx"

\end_inset


\end_layout

\begin_layout Standard
\begin_inset CommandInset include
LatexCommand include
filename "chapters/2_2-final.lyx"

\end_inset


\end_layout

\begin_layout Standard
\begin_inset CommandInset index_print
LatexCommand printindex

\end_inset


\end_layout

\end_body
\end_document