In the previous chapter, we were introduced to the templating system that enables us to create amazing views or to render data coming from the server.
In this chapter, we'll focus on this last point: server data. Until now, it was hardcoded in our actions and given directly to the views.
Of course, it's never that simple; data is regularly coming from a database, or at least has been provided (at some time) by a user. So, we'll see how Play! 2 deals with these use cases. The following is an overview of what will be achieved in this chapter:
- Create an HTML form to represent data
- Send data to the server
- Retrieve data from the server
- Add constraints to the data
- Persist data in a relational database
- Provide and render back the data to the client
In this section, we'll cover the basis of dealing with data, both on the client side within HTML views and the server side by manipulating a domain model.
Actually, Play! 2 provides helpers and commodities for these two sides and eases their integration, even if a wire transfer occurs in between them.
We'll start by allowing the user of our application to provide some data, and the most common way to do that is by using HTML forms. Hence Play! 2 brings a shared concept for forms on the client and server sides.
The Play! 2 data API is based on the notion of a form to declare a structure. For that, the framework contains a fully-fledged API that resides under the package play.api.libs.data, wherein we'll find the Form class. In order to learn how to use it, we'll see how to create a user of our application.
We'll start with the simplest User structure ever:
Ok, for now our User class is just a wrapper around a name; of course, it will be enhanced further to demonstrate the power of Play! 2's data API.
Note
Now that the server knows what a user can be, we'll tell it how it can be represented from the outside (that is, strings) by creating a server-side form. The Java version requires less work than the Scala one; that's because of the Scala "youth". In Java, people have already tackled the trickiness of reflection, but with Scala, it's still evolving. For your information, Play! 2's reflection library is the Spring data binder.
For that, we'll create a new controller, Data, where we'll define a new form for our User class, which will be marked as static to allow us to use it in future actions:
The Java data binding is so easy when the structure to be represented is a data container. Thanks to reflection, via the Spring data binder, what Play! 2 has defined for us is a way to bind a user to any map of data that matches the User structure—that is a dictionary.
Let's try to interact with the outside world using such a simple map. For that, we'll create an action, a template, and the related routing.
The template will look like the code shown in the following screenshot:
The routing is simply the code shown in the following screenshot:
And finally, the controller is shown as follows:
Before executing the code, let's review it a bit. The template and the routing are fairly simple, so let's stick with the action only.
The test action is doing the following tasks:
- It creates a container of data representing the structure: a simple dictionary.
- It adds one piece of data that is keyed by name and a dummy value. The key is well chosen in order to match the user's
namefield name. - It uses the
bindmethod on the form using the data container. This will feed the data to the underlying binder. - It calls
geton the resulting (filled) form to retrieve the structure expected. - It calls our template with the result to show what has been bound.
The following screenshot shows the result when we go to the URL http://localhost:9000/data on our browser:
Splendid! Our User instance has been created and it contains the correct data. We're now able to create a user using a dictionary and ready to use the wire to receive our data!