A dashboard is something that can be configured to present the exact amount of information that a user wants to see. So, in our case, where only chat instances are involved, we're going to provide a way to see several chat instances at once.

For that, we'll have to deal with a dynamic form on the server side. This form will be such that the number of values passed to the server is neither predetermined nor fixed (non-deterministic).

First of all, we'll need a new template for this and its related server-side action. The template will present an HTML form, where the user can select which chat instances he/she wants to add to his/her dashboard. So we'll need all available chat instances as a parameter of this template in order to create the UI that enables such selections.

On the server side, the action should be able to retrieve as many chat instances as the user has configured; hence we're going to have a kind of dynamic list of chat references to be bound to the request content.

The following screenshot shows an example of how we can define our template:

What we see in this example is interesting in several ways. First of all, while defining a dashboard for our chat system, we tried to split the tasks in order to improve readability.

For that, we created an inner template createSelect that takes a form field and a sequence of a tuple of strings. The result of this template is an Html block that shows an HTML select element. It has been defined against a parameter of type Field, which is just a wrapper around all information that is necessary to show an HTML element in an elegant and valuable way—the name, ID, errors, constraints, and so on. These instances can be easily built from the Form instance based on their expected name in the request.

We can also see that in order to define an inner template, we simply have to define a function. This is quite intuitive because we already saw that Scala templates are compiled into a Scala function.

Then we took all the existing chat instances (available as a parameter of the template) in a sequence and mapped them to a representation that is easily usable by a select input field.

As this computation will be done more than once, we can define it as a new variable, preparedChats, through the use of the helper defining. As it's not possible to create new variables within a template, we can use this helper that takes a computation and a block of code that uses it. This is done by providing a function that takes the result of the computation as the only argument. In this case, the function block of defining is creating Html content to be rendered.

Now we're reaching two exciting blocks as we're about to define the dynamic part of the form. Recall that we're trying to have a form that enables the user to select several chat instances to be shown on a single page.

Let's skip the very next block with the class sampleJsBlock, and first look at form one, where we start directly with the action definition that targets a new dedicated action (routes.Dashboard.open), followed by the usage of another helper: repeat. This helper is indeed a very useful one (because it will hide for us all boilerplates necessary to create form elements that must be serialized under the same name) and is followed by an array index.

Furthermore, this helper has a specific argument telling us how many times its body definition has to be generated. In our case, we want at least two chat instances to be shown. This so-called body, in our case, is exactly a call of our inner template createSelect, which will create a select element containing all available chat instances.

We shall go to the action now in order to check how the heck this parameter list will be handled. But before that, it'd be worth looking at the block we kept aside, which is there to enable the user to add more than two chat instances to his/her dashboard, dynamically.

To do that, there is a common trick (a kind of pattern) that will enable us to create, on the client side, a UI that matches exactly what is produced on the server side (using a template and thus helpers). This is achieved by creating a dummy excerpt of HTML, and hiding it outside the form tag. This is what has been done with the div tag having the class sampleJsBlock. In fact, this one just contains a generated select element, but with a dummy field (giving dashboardForm the expected name, but with a fake index).

In order to catch what will be necessary to do with it, it's important to check what is produced:

We can see that there is a hidden div tag defining some elements, which has attributes containing the provided dummy index, namely _x_ and [x].

So you can surmise that we'll have to produce a client-side code (we'll do it in CoffeeScript) that takes this bunch of HTML and replaces all such instances of the dummy index by the current count of selects being shown (starting at 2, though).

Let's keep this in mind and perform a quick hook in the controller to check how this form is bound to an instance of controllers.Dashboard.Data according to the type of template parameter, dashboardForm.

The controller that we're talking about is the one targeted by the form in its action attribute, which is Dashboard:

The Dashboard controller is very straightforward and doesn't include any new stuff that we need to point out. The only thing that is really interesting is the Data inner class, which stands as a container for the received chat instances' IDs.

As done earlier, we use the form method to create the binding by reflection. This binding will take into account the list and will expect several values with the same indexed name. So, we're binding it with the request as usual in the open action.

Something to note from here is that we're going to use the same template for rendering the form and the dashboard itself; that's because we'll not change the dashboard's configuration even if one is already opened. As a consequence, we'll have everything in the same template.

It's now time to dynamize the form using CoffeeScript.

So what we need to do is enable the + button to take the sample HTML block created on the server side to add a new select element after the existing ones. This block must be reworked a bit in order to use the correct index; we'll do that in CoffeeScript.

To be able to code in CoffeeScript using the same techniques as Java or Scala (hot recompile and reload, for instance) we can put our .coffee files in the folder app/assets/javascripts/. Hence, we'll create the file app/assets/javascripts/dashboard.coffee.

As said earlier, CoffeeScript is there to help developers by eliminating a lot of boilerplates, mostly in order to code in a more object-oriented fashion using classes—for those who want this paradigm back.

The code in the following screenshot shows how we can implement our use case:

Even though we're using the basic features of CoffeeScript in this example, it is intuitive enough to get a big picture. However, there are still some concepts that might be worth mentioning.

An important thing to know about CoffeeScript is that its layout is actually driven by the spaces used to indent the lines (Python style). Take a simple example: the body of a function must be indented one time more than the function declaration's indent.

As a consequence, CoffeeScript doesn't require parenthesis for a parameter's block and nor does it require a comma to separate the array's items or properties in an object (if they are separated by well-indented blank lines).

A class can be defined as easily as in an object-oriented language, that is, by simply using the class keyword followed by the class name. Methods and fields can be defined using the Object notation, that is, the name followed by a colon, and then the definition of the field or the function. A commonly used method is the constructor one, which will be used when using the new operator.

A variable declaration is not defined by any special keyword (such as var); actually, all newly used variables will be created locally by default (rather than globally, as in JavaScript).

A function can be declared in two ways: with an arrow (->) or a fat arrow (=>). These arrows will separate the function parameters between parenthesis and the body of the function (the implementation). The only difference between the arrow and the fat arrow is that the latter will keep the actual scope (which is graceful when playing with closures ); the this object can be kept as the original class' object, for instance.

The following screenshot shows two functions for illustration purposes:

To read the example, we must mention that the this variable doesn't exist, but @ can be used to refer it; so @prop is compiled as this.prop.

Now we can understand that the g function, which makes use of the fat arrow, will never lose its initial scope, that is, the object that holds it.

Explaining CoffeeScript in action

Back to our Dashboard class, we can see that it only defines its logic in its constructor, so it doesn't provide any other functionalities besides starting itself with some actions. These actions are twofold (using jQuery that was imported in the main template):

• The first action is retrieving all the elements that have the header class. On them, it will register a click event that will toggle the next DOM element. Another initial parameter is used to tell if it should close these elements on startup.
• The second action registers a click event on the + button that will look for the block of HTML code in the form that wraps all select elements, then keeps count of the already present ones, and finally retrieves the hidden template's excerpt, so it will update the template with the relevant count and then append it to the block.

In brief, this .coffee file defines the Dashboard class and makes it available in the global scope in the very last statement. Having created this file, there are two things to be done – add the compiled JavaScript file to the web page and use it.

Play! 2 will compile our CoffeeScript file in the same folder as our traditional JavaScript files, that is, in the public/javascripts folder. Because of this, adding them to the application is as simple as adding a new JavaScript library in the scope (most of the time, this will be done in the main.scala.html file). This way, Play! 2 will be able to cache it and do some JavaScript minification for the production mode.

The way we're going to use it is not very conventional, but it will do the trick. In our dashboard/index.scala.html file, we'll just add a bootstrap code creating an instance of this Dashboard class:

Note

In a real application, it's worth considering libraries such as Spine.js or Backbone.js with Require.js for organizing your code and loading them.

Rendering the dashboard

Until now, we've been able to tell the server which chat instances are to be shown in the dashboard, but we haven't showed them yet. However, in the action, we saw that we're rendering the same template by providing the updated form with a Data instance, which has a helper method to fetch the chat instances.

Here again, we'll take advantage of the composability of our templates, by re-using the chatroom template for each chat in the chat instances list; the only thing we have to do in it is remove the call to main.

As this template requires two more parameters (the form enabling new messages or uploading of images), we're going to add them to the dashboard/index.scala.html template's signature.

What comes next is fairly obvious. Check out the following screenshot:

Note

The action doesn't need to be changed as it has foreseen them.

That was easy game. We just checked whether the form contains some data; if so, we looped on the embedded list of chat instances and called the relevant template.

The following screenshot shows the result (with a bit of skinning) we have so far:

Note

This is what we get after having selected two chat instances in the form; we can also see that the form is hidden (that came from the bootstrapping JavaScript that told to close it when a Data instance is available).

So far so good—we have an aggregated view on several chat instances, but what hasn't been satisfied yet is the "liveness" of the updates. Actually, this problem has taken on more significance now, as several chat instances are involved. So let's resolve it.

What we're about to do is enable a poller for each chat to fetch its last updates that are available. For that we'll need two kinds of things, as follows:

For the first part, we'll do quite the same as we did in the earlier section, that is, create a .coffee file that will contain the logic, add it to the main template, and initialize it in the relevant template.

First, the .coffee file! We'll create a new one, named chatroom.coffee, which could be as shown in the following screenshot:

So what's the big deal here?

The constructor of ChatRoom takes a configuration object with three properties kept as fields of the class: the chat's ID (id), the element (el) wherein the UI has been added, and the last updated timestamp (since).

At the end of the class definition, there is a poll method, which simply starts an endless loop over the fetchContent method right above it, every 5 seconds. This latter method (thanks to the fat arrow) is always resolved to the actual instance, and its work is actually to call the server-side action that will be tackled next.

For that, we used jQuery's ajax function (get is just a jQuery abstraction over it) by giving it a URL filled with the expected parameters and a success function that will handle the response (a data encoded in JSON).

When the call succeeds we ask the ChatRoom class to update its UI with the new data, and we call poll again.

After including this script in the main page (<script src="..."), we must update the chatroom.scala.html template to initialize an instance of ChatRoom, shown as follows:

One last thing to have the whole polling system in place is to add the action to be routed from URLs such as /chat/content/:id?timestamp=:since. So this action should take two arguments: two Long types (one for the ID and the other for the last update timestamp).

Quite obvious, we just retrieve the Chat instance and filter the items and images based on the given timestamp (wouldn't it be great to have a higher function filter on the lists?). Then we asked the JSON from Play! 2 to encode an object containing both resulting lists (using reflection and thus without our help). And we're done. We can now open several browsers, configure our dashboard, and do cross-chatting with them all. And magically, everything is updated automatically.

Amazing, right? But not enough. Because, at first, we hardcoded URLs, then we polled for each chat instance. We also have the same forms for posting new items or images for each chat instance, but using them will cause us to leave the page and will force us to go back in order to go back to the dashboard.

So annoying! That's why we're about to change that in the next section.