After some time off from officially (unofficially?) teaching myself more about the Play framework, I have resumed covering new material. Specifically, I worked on adding Fluentlenium testing and Scala templates to the Digits application that I have been working on in recent weeks. In general, the programming itself was not too difficult (I now fully expect to run into problems whenever I try to use these skills and tools in other projects), just time-consuming. The main problems were with the performance of IntelliJ IDEA and trying to get HTML and CSS to display elements properly; the specific issues I ran into are covered later in this posting.
First, I added a couple of integration tests to the project. Since Fluentlenium is already packaged with Play, there were no external dependencies to download, which made this much more convenient. As mentioned previously, the Digits project consists of an Edit view where the user types in contact information and an Index view where all contacts are displayed. As a result, adding tests turns out to be rather simple: aside from the basic tests to ensure that the views load correctly, I wrote a test to verify that form submission worked correctly – essentially, checking if values provided as input to the form on the Edit view are then displayed on the Index view. I used the Page Object Pattern when writing these tests, so each view has a corresponding class in the tests package. This took 34:42.07 on my first attempt, though much of this was due to having to make a few modifications to the original code base to support testing (mostly changing the labels in the Edit view to actually match their respective fields and adding the page name into the
Next, I incorporated some Scala templates into the application. Since all of the input fields for the form were text fields at the time and all of these text fields were more or less identical aside from the values being displayed and stored, having a template made perfect sense. Conveniently, templates for most HTML inputs are available at https://github.com/ics-software-engineering/play-example-form/tree/master/app/views/bootstrap3, which saved me a great deal of time in trying to make the templates myself. As such, it took only 12:46.19 to replace the input form with Scala templates on my first attempt; after familiarizing myself with how the templates worked, this time decreased to 8:08.66. The branch showing the state of the project at this point is at https://github.com/bsogata/digits/tree/template-2.
Of course, many forms will have inputs other than text fields, and so I set out to add a drop-down menu for users to input their telephone type (such as “Home”, “Mobile”, or “Work”). The set of templates from the previous section includes a template for the select input in HTML, so in terms of programming this was really just adding another field. However, this is where IntelliJ IDEA became very problematic as it became unresponsive for over eight minutes in total while I was working on this. The first incident froze the IDE for roughly five minutes, and as I am quite used to IntelliJ lagging by now I took this as an opportunity to look through the documentation for the Scala templates, examine how form submission would work with a select tag, and plan out how I would write my code. Of course, five minutes is much longer than the usual delay from IntelliJ, but once functionality was restored I treated it as an isolated event, made a mental note to grumble about it in this post, and continued on. A few minutes later, IntelliJ froze again. This time, I was considerably less patient and manually ended the IntelliJ process after around three minutes of unresponsiveness. Upon restart, IntelliJ was still very slow, and as a result my first attempt to complete this took nearly an hour at 53:27.94.
A few hours later, both IntelliJ and I were apparently done throwing our respective temper tantrums and I repeated the same process in only 26:22.49 without any problems from IntelliJ. Although it is entirely reasonable to suppose that I would have finished faster even without the freezes on my first attempt, I typically finish about 25% faster on my second attempt of all the exercises or branches that I have mentioned on this blog, leaving another 25% that I blame on IntelliJ. I concede that there was apparently a denial-of-service attack on GitHub at the time that I was writing code for this and that could have been a factor in the poor performance of IntelliJ since many of the resources I use are hosted on GitHub, but all of my code was on my local machine, the Scala templates I used were all downloaded on my machine, and while the Checkstyle rules for the Digits project are hosted on GitHub one would expect there to be a cached copy on the local machine too and in any event I was not even using the Checkstyle plugin at the time.
After a couple of days (and working on some of the other features discussed below), I discovered a bug in the way that the select template had been incorporated into the project. Essentially, the error message for having an invalid telephone type was being placed under the Address input field rather than the Telephone Type field. Redoing this task properly took 17:51.53, producing the code available at https://github.com/bsogata/digits/tree/selection-3.
After implementing the drop-down menu in the previous section, it became obvious that there were two fields dealing with telephones (particularly since they were right next to each other), and so I essentially combined the two templates together to create a Telephone template. This only took 13:56.95 to complete the first time. However, there were some problems with formatting (possibly related to the aforementioned bug where the errors for the Telephone Type field were being placed below the Address field), and of course now that I am actually writing this up I am unable to replicate the problem to take a screenshot of it. Actually trying to find a fix for this issue proved to be problematic: if there was an error for the telephone type, everything worked properly, but if only the telephone number field was invalid then the address field and submit button below would jump up a row. Having to take more time to fix this meant that my second attempt took longer with 21:49.24 needed to get everything working. Once this was resolved and I knew how to handle this issue, I repeated this once more and finished in 8:38.46; this branch is available at https://github.com/bsogata/digits/tree/custom-3.
There are a couple of minor bugs in the handling of the custom template. First, if the select tag for the telephone template has a valid value while the text input does not, the entire field is treated as erroneous and thus is highlighted in red even though only one of the inputs is invalid. Second, if form submission fails due to invalid input, the value of the select tag is not preserved like the other inputs. Fixing the first bug should not be too difficult with the proper use of conditional statements to add classes that control the color of the inputs and text; resolving the second issue turned out to be beyond my abilities.
Finally, I added some seed data to the application to make sure that the Index page was properly populated. This was not difficult at all and only took 5:19.43 to complete, so of course this first attempt missed an obvious bug where any contacts the user added would overwrite the seed data due to having the same ID number. The proper working solution was finished in 7:03.19, and the code for that is at https://github.com/bsogata/digits/tree/init-2.
Overall, working with Fluentlenium tests and Scala templates was not that difficult in and of itself. I am still somewhat concerned about the fact that this all feels like I am copying and modifying existing code rather than writing code myself, though not to the severity of previous posts involving Play. Writing tests and using templates is certainly easier than writing all of the code by hand though. The bulk of the problems this time had to do with IntelliJ, and although I will continue using it as my IDE for the time being just to give it a proper chance, the fact that I probably could have added templates into the Digits project faster with Notepad++ than in IntelliJ does not inspire a great deal of confidence in IntelliJ. The branching for the Digits project on GitHub is rather complex even though all I did was make a branch for each new feature and immediately merge the branch into master if I was satisfied with my performance.