Developing in Drupal and DrupalGap

In this chapter we will detail the development process in Drupal and DrupalGap, and the difficulties we found that led us to switch to AngularJS. The code used in this process can be found in appendix C. Note that the development process was never completed, so some of the functionalities represented as prototypes and presented as requirements of the system described in chapter 4 has not yet been implemented.

96

Nobil (stylized NOBIL) is a service established in 2010 with a mission statement of gathering all the available information on the various charging stations in Norway in one place (Nobil, n.d.). NOBIL API Version 3.0 is a comprehensive database licensed under Creative Commons (https://creativecommons.org/licenses/by/3.0/), which allows for the export of data about most of the charging stations in Norway in addition to some in the other Scandinavian countries.

As we wanted to use Nobil’s database for getting information about different charging points and charging stations we needed to import this data into Drupal’s database. We found a module called Feeds which could be set up by cron to import data on intervals into Drupals system. Cron is a Unix process that executes in the background and can be configured to run programs at specific times (Nemeth, Snyder & Seebass, 1989, p.412).

First we needed to define two content types with the appropriate fields. We defined Charging station and charging Point, where each charging station could be connected to one or more charging points.

At this time in the design process, we did not know what fields would be interesting for our users, but we knew what information we could get from Nobil by printing out and inspecting the JSON file. We decided to simply include all the information that was available from Nobil’s database, and later hide or remove information that would seem too excessive for our users.

After all the appropriate field had been defined we needed to setup the feed importer so the data would be saved to the appropriate fields. Our first challenge here was that the importer did not take into consideration that we wanted to import data into two content types from the same file. The solution we came up with was to set up two different importers, one for charging station and one for charging points, but to then connect the correct point to the correct station needed some customization in a custom module (see section 5.2.1).

We created a custom module which uses a hook to give each of the charging stations a unique id (see function ecar_custom_feeds_presave() in ecar_custom.module).

After successfully importing the charging stations and charging points into Drupals database, we moved onto integrating DrupalGap.

97 To enable this we followed a tutorial from the creator of DrupalGap (Tyler Frankenstein n.d).

By following this tutorial we generated a Drupal view with all our charging stations, and configured this to be displayed as a JSON view and to be sorted by distance from our incoming parameter. We could then request the JSON and send parameters with the method

“views_datasource_get_view_result(path, options)” from the application.

After successfully generating a map over all the charging stations, we could see that there were large differences in loading time and number of charging stations generated based on the location we specified. One kilometer in radius in Oslo center generated hundreds of charging stations, while one kilometer in a more remote location generated none. Since we were in no control over the algorithm other than the range we provided as a parameter to the view, our only solution to this problem was to implement a function that waits for the generated view result, and if the number of results were less than 10, we increased the range by 10 kilometer.

We chose 10 kilometers, as this usually would only require one iteration, making the process faster (see function “populate_map(path, range, counter)”, in my_module.js).

Nobil offers real time information about the availability of some of the charging stations. This information is accessible through the use of websockets (Lie, 2014). In order for our users to immediately see the availability of the charging station we implemented another function that colors the charging station marker based on its availability; green if there were any available connector, red if all connectors are busy, and grey for the charging stations that do not provide real-time information (see function runWebsocketServer() in my_module.js).

Troubles and Difficulties

We found it repeatedly difficult to customize the templates and CSS in DrupalGap. Creating a page in the app to display content required that we defined a set of different content objects that could contain either a jQuery widget (DrupalGap 7 Docs, n.d. b), or a custom markup that would have to be written in its entirety in one line.

The different available widgets are listed on the DrupalGap documentation, and are not particularly customizeable. For instance, if we wanted a list of items with images we could not have the images aligned to the left without doing some extensive Javascript and CSS repositioning.

98

As designers we found it very frustrating to use jQuery Mobile with DrupalGap, as we felt we had very little control over the templates and the CSS (styling). This became increasingly important as our users had more and more specific requirements for the design.

DrupalGap seemed more and more as a framework that would better fit the purpose of transforming an already working Drupal site into an application, without much template and CSS customization.

Another big issue when working with DrupalGap was the lack of documentation. Some tutorials and documentation for DrupalGap exist, but attempting to implement any functionality not covered by these required many hours of guesswork and trying, without much payoff.

We also believe that Drupal shines best when it handles large volumes of content, and is used as a CMS and not an hybrid application back end. For our case, most of our data will be loaded from an already existing database. We found that when the progress halted in late January due to the different issues outlined above, we decided the best solution was to scrap the progress made in DrupalGap and start over from scratch in a different framework.