Programmation appliquée en Scala

Lab

Scary looking lab

What? The lab first???
You've got to experience this; otherwise talking about it makes no sense

Part 1: Getting Started with Play

Download the “Typesafe Activator” from this site
Unzip into your home directory
Make sure java is on the PATH. Open a command shell. Type
```
javac -version
```
You should be getting something like javac 1.8.0_31. If not, follow these directions.

In a command shell, type

activator-1.3.2/activator new

play-scala

unit15

Type
```
cd unit15
activator-1.3.2/activator
```
(without new)! You are now getting a prompt in the Activator shell. Type
```
~run
```
Point your browser to localhost:9000. What happens?

Part 2: The App Layout

In the Activator shell window, hit Ctrl+D to get back to the prompt. Type
```
eclipse
```
Start the Scala IDE. Select File → Import → Existing Projects into Workspace, and navigate to the unit15 directory. Select Finish.
In the Activator shell window, type
```
~run
```
(note the ~).
If you get an error in Application.scala, select Project -> Properties -> Java Build Path -> Source and add the directories unit15/target/scala-2.11/src_managed/main and unit15/target/scala-2.11/twirl/main to the source folders (see this post)
In index.scala.html, replace the code inside { } with
```
Hello @message
```
Save and reload the localhost:9000 page. What happened?
Go to Application.scala and change "Your application is ready" to "Unit 15". Save and reload the localhost:9000 page. What happened?
Point your browser to http://localhost:9000/assets/images/favicon.png. What happens? Why? (Hint: conf/routes)
Ok, now we are ready for the lecture.

Web Applications

Client-server architecture
Client sends request to web server
Uses HTTP protocol
- GET url
- POST url
  data
- Also PUT, DELETE
Server returns HTML
Inversion of control

Web Application Frameworks

Rendering HTML
- Components (e.g. JSF, GWT, ASP.NET)
- Templates, mixing HTML and code that generates HTML (e.g. PHP)
Routing requests to actions (server-side code)
Database persistence
Factoring out common/repetitive code
Internationalization
Security

Web Application Framework Trends

Classic framework: JSF, ASP.NET
- Components and events (somewhat like Swing)
- Separation of markup and code
- (Almost) everything is a POST
REST
- Use GET for non-mutating actions (can be cached)
- Optionally, use PUT and DELETE
- Use meaningful URLs, not session state
Convention over Configuration
- Avoiding XML hell
- Poster child: Ruby on Rails
AJAX
- Client in JavaScript (can be "single page")
- Communicates with server over AJAX channel

Play Framework

Scala or Java
Typesafe
Stateless, REST-friendly
Non-blocking, highly scalable
Convention over configuration
Build system with hot deployment
Datastore-agnostic

Controllers

Action turns HTTP request into HTTP response

val hello = Action { request =>
  Ok(s"Hello $request")
}

Controllers have methods that yield actions

object Application extends Controller {
  def hello(name: String) = Action { Ok(s"Hello $name") }
  def goodbye(name: String) = Action { NotFound(<h1>Page not found</h1>) }
  def index(name: String) = TODO
}

Futures

Play is designed for asynchronous request processing
Not one thread per request

For all computationally intensive work, return a Future

val futurePiValue: Future[Double] = computePiAsync()
val futureResult: Future[Result] = futurePiValue.map(res =>
  Ok(res))

Use Action.async instead of Action.apply:

def pi = Action.async { computePiAsync().map(res => Ok(res)) }

Routes

In conf/routes

Static path:

GET   /tasks/all          controllers.Tasks.list()
GET   /tasks/find         controllers.Tasks.list(id: Long)
  // id must be in query string /tasks/find?id=...

Dynamic parts:

GET   /task/:id   controllers.Tasks.find(id: Long)

Multipart match:

GET   /assets/*file           controllers.Assets.at(path="/public", file)

Routes are compiled—you see route errors at compile time

Templates

“Twirl” template engine for HTML, CSS, other text files (e.g. CSV)
Template compiled into Scala function

Use @ to inject Scala expressions

<ul>@for (task <- tasks) { <li>@task.label</li> }</ul>

First line has parameters:
```
@(title: String, tasks: List[Task])
```

Forms

Play has aForms API to minimize the tedium of building HTML forms
Form[T] object converts between form contents and objects of type T
```
val loginForm = Form(
  tuple(
    "name" -> text,
    "age" -> number
  )
)
```
Result object has type (String, Int)

Can supply functions to convert to and from objects

case class User(name: String, age: Int)

val userForm = Form(
  mapping(
    "name" -> text,
    "age" -> number
  )(User.apply)(User.unapply)
)

Can add constraints, handle errors—see the docs

Form Helpers

In HTML template,
```
@import helper._
```

@form generates HTML form tag

 @form(routes.Application.deleteTask(task.id)) {
  <input type="submit" value="Delete">
}

action attribute taken from route argument (“reverse routing”)

Convenience functions for generating input elements

@form(routes.Application.newTask) {        
  @inputText(taskForm("label"))         
  ...
}

Form object must be passed to page:

@(tasks: List[Task], taskForm: Form[String])

Persistence

Play can support different database persistence layers
Today, we use Anorm
Not an ORM, just JDBC and SQL
```
SQL("INSERT INTO Task (label) VALUES ({label})").on(
      "label" -> label).executeUpdate()
```
Here, label is
1. The database column
2. a variable part of the SQL statement
3. a map key
4. a Scala variable (holding the value for the column)

Need Connection object—best passed “implicitly” (see lab)

 DB.withConnection { implicit c => SQL(...).on(...).executeUpdate() }

Anorm Result Set Parsing

Consider query "SELECT * FROM Task"
Returns sequence of rows
Want to turn each row into an object
Can parse column as get[Type]("name")
Combine parsers with ~, *, like in Unit 12

Parser for row:

val task = {
  get[Long]("id") ~ get[String]("label") map {
    case id ~ label => Task(id, label)
  }
}

Apply to all rows:

val result: List[Task] = SQL("SELECT * FROM Task").as(task *)

Lab

We'll set up a very simple to do list, following this tutorial. Play has changed a little since then, so the first part no longer applies. Instead, we continue with the lab, as set up in the first part, and join the tutorial at the section "Preparing the application"
Go ahead and edit conf/routes and described, and check the compile-time error that tells you the routes error.
Add the definitions to Application and verify the TODO behavior.

Forms

Make a package models inside app and define the Task class as specified.
Set up the index.scala.html page, task form, and the tasks action as described. Make sure that http://localhost:9000/tasks looks like in the tutorial in the section "Rendering the first page".
Then look at the index.scala.html page. What parameters does the page have? Where do they come from? (That is, who supplies them?) What happens with the first parameter? With the second?
What happens when you submit the form? Why? Which method do you need to implement to fix this?
Follow the step "Handling the form submission". Check out Form in the Play API. What is the significance of bindFromRequest? Explain the syntax of the stuff inside fold(...).

Queries

Now follow “Persist the tasks in a database”. Uncomment the four lines in conf/application.conf that start with db.default. Make the file conf/evolutions/default/1.sql (and be careful that you use exactly that path—otherwise, it won't work). Verify that you get the evolution screen, and click Apply.
Now start implementing the SQL queries. First, provide the task parser. Which class does it go into?
You've seen something just like that in Unit 12, except for map. What was it called there?

Implicits

Paste in the all method. That's a lot of strange syntax. We haven't covered implicit yet, except for implicitly in Unit 9. The idea is that a parameter labeled implicit is set to the unique object of the appropriate type that has been defined as implicit. Let's start figuring this out. What is DB? (Look it up in the Play API.)
There are two methods called withConnection. Which one are we calling?
Now click on the link DB.scala on the top of the API. Find the source code of that method. Note it refers to a function db. What type does that function return?
That type has a function database. What type does it return?
And that type has a perfectly normal function
```
 def withConnection[A](block: (Connection) ⇒ A): A
```
Click on Database.scala and read the implementation (it's in DefaultDatabase). If you've ever done JDBC programming, this is straightforward:
1. Get a connection
2. In a try/finally block, run code that uses it
3. In the finally clause, close the connection
We did all that because we wanted to follow the implicit. Start again with DB.withTransaction. Notice the last (curried) parameter. It is declared as implicit. That means, an object is silently passed to this function whenever it is called. What is the type of that object?
Now follow the call to db. What happens to that special object?
How did the Application object get in there in the first place? We can't (easily) answer that, but we can look at how another object is passed as an implicit object. Let's go back to
```
def all(): List[Task] = DB.withConnection { implicit c =>
  SQL("select * from task").as(task *)
}
```
Ignoring the implicit for a minute, recall what happens here. A connection was found, and block(connection) was called. That's just a normal function call. To see why c is implicit, we need to look further. Mouse over the as method in Eclipse. What do you get?
Note the second, implicit parameter. When as gets called, it wants some connection. Which one is it going to get?

Finishing Up

Enough of implicit objects. Let's solve a different mystery. What is the * behind task? Hint: Mouse over it.
Finally, add the create and delete methods. Run the app and create a few tasks.
What happens when you try to delete one?
Fix that and try out that everything works now. Stop before "Deploying to Heroku"
Finally, have another look at create and delete. Notice the curious 'label and 'id. Those are Scala symbols—kind of like strings, but different. Replace them with "label" and "id", and verify that you can still create and delete tasks.

Homework

Sadly, we have reached the end of the rope with Codecheck. In this homework assignment, you will write a simple Play application. Zip up the entire directory and email it to Prof. Borran when you are done. Also, be prepared to demo your solution during the next class meeting.

Write a web app that can be used for online “clickers”, rather than the paper index cards that we have used in class. Here is the workflow.

The professor visits quiz/new and enters the question and four answer choices [Extra credit for variable numbers of choices]. When the professor hits submit, a number is displayed (just show the ID number in the database)
The professor announces the ID number to the students.
The students visit quiz/reply/id (with that ID) and select an answer
Afterwards, the professor visits quiz/results/id, and the number of responses for each choice is displayed.

Tip: If you want to make the app look prettier (and also for general hints), run activator new computer-database-scala and have a look at the resulting app.