Making Custom Report Tables Using AngularJS and Django

While working on Olivia We were given a task to create an interactive interface with a widely customized visual look and different filtering to view reports.

One of the main requirements was the ability to customize the visibility of the columns. Beyond this, it was necessary to implement:

• Sorting by specific columns
• Filter as a sidebar
• Filter as tabs
• Column width adjustment
• Search

At the same time, a general look of the table and a large part of the functionality had to remain the same regardless of the displayed type of data.

Of course, we wanted to do it reusing as much code as possible and get a kind of universal tool that could be easily integrated wherever it was needed.

Since the forming of report occurred on a server using Django, the back-end issue was partly resolved. However, different technologies could also be applied to the interface implementation where the quality and speed of accomplished task has been determined by the right choices we made.

One of the options was a server-side rendering of templates and inserting of the resulting html to the desired location on the page. However, this could lead to a serious loss of speed and create a complex and hardly supported template logic.

There are lots of ways to transfer data from client to the server and back. As you might guess from the title, our choice is AngularJS. AngularJS, just as Django, provides excellent opportunities for writing well-structured apps with easily deployed extensions. In both cases, a great many of commonly used mechanisms and possibilities for testing the written code have been implemented.

Let’s simply go through some key aspects of the implementation of a client-server communication and focus on the interface. Generally, in this connection, the settings in operation can be carried out in different ways, and each of them is described in some extent. Some even involve programming layers that allow adjusting the interaction more easy. We will discuss one of such methods here.

Django and REST

Pure Django is not suited to work with the REST API, but there are extensions that allow easily adding the necessary functionality to the project.

We have chosen the Django Rest Framework (DRF). This is a powerful and flexible toolkit for creating and interacting with Web API. Using this framework, endpoints have been described and the server-side work has been made with the proper setup and configuration.

Compared to Tastypie (the Django Rest Framework main competitor), DRF has some advantages:

• Good integration with Django (based on Class-Based Views)
• Greater flexibility and easier customization
• More reliable authentication system

Routing to REST endpoints

To tie it all together, we have used the js-routes extension for Django. On the client side, it allows getting a list of all routes names described in back-end, and accessing to them, same way as it is done on the server. This works with a decorator function for the AngularJS built-in service like $http and generally it allows to make queries, for example, to see the list as:

$http.dget('url-name', params)

Where "url-name" is the name of the pattern in the server config of js-routes, and "params" contains query parameters. The result of the call is a ‘promise’ that will contain data received from the server. Such precise writing has been achieved thanks to the use of our self-written shortcut, expanding the functional $http:

$provide.decorator '$http', ($delegate) ->
  dhttpErr = angular.$$minErr 'djangoHttp'
  reverse = (url) ->
    reverseParams = if angular.isArray url then url else [url]
    url = django_url_reverse reverseParams...
    if typeof url == 'undefined'
      throw dhttpErr 'URL not found'
    return url

  shortcut = (method) ->
    (url, params...) ->
      params = [reverse url].concat params
      $delegate[method] params…


  for method in ['get', 'post', 'put', 'delete', 'patch']
    $delegate['d' + method] = shortcut method

This code gives access to the standard methods like $http by adding the "d" letter to their name, and accepts the name of the route as the first argument.

Architecture of the Report Directive

We decided to split a directive to several separate components. This approach has clear benefits: Depending on the situation, only the particular parts can be used You do not have to clutter up the original code when writing additional plug-ins Code of each directive is clear and simple

As a result, we use a set of the following directives to report a task:

• Table
• Sidebar filter
• Upper panel filter
• Search
• Columns appear configuring

Table

This directive deals with actual data representation. From the outside, the directive receives the following parameters:

• Endpoint name to download data
• Query parameters
• Columns configuration
  • Key – a field in the api
  • Name – a column title in the table
  • SotringKey – a sorting key on the server
  • Show – a visibility flag of the column by default
  • Sortable – a sortable column flag
  • Width – a default width of the column
  • Template – the path to the template, if you need a special type of representation
  • CellClass – the name of the css class columns

Directive code: