In the first half of April, two major projects I've been involved in during this year's first quarter were officially launched. While the first one, the redesign and re-implementation of the website for the kult.kino - an art-cinema company in Basel - was for me rather a routine Magnolia CMS based project (although there were some interesting details, too), the second one provided me an opportunity to extend my professional knowledge from pure server-side Java into the (for me) new and exciting area of Single-Page Applications (SPA).

Introduction

Our client - Kooperationsinitiative Museen Baselland (further KIM.bl) - is an initiative for better cooperation of the museums and other institutions caring for the cultural heritage in the Swiss canton of Basel-Landschaft. Our goal was to create a Liferay-based portal, so the individual member institutions and their employees can better cooperate, and also the particular institutions can present themselves in the public part of the portal.

My part was to implement two portlets - one to allow to display the events held by particular institutions, the other, which I want to address in this post, to provide a search in the exhibit-catalog of the participating museums.

Backend

The Liferay Portal, which powers the whole portal implementation, is for my two portlets just a bit more than a container. All the data are stored in an Apache Solr instance, and my portlets work as a front-end for these Solr data. As for the Liferay features, I use just the portlet configuration, Friendly-URLs, and a few delegated servlets.

The prototype and the move towards SPA

The initial specification had not mentioned the idea of SPA, so I implemented the prototype as a standard Liferay portlet, using the Solrj library. But when we discussed the prototype with our counterparts from KIM.bl, the need to avoid constant reloads of the page, plus the other enhancement ideas led us to the decision to drop the initial implementation and start from the scratch with an SPA implementation. I embraced this decision quite happily (but with a bit of concern, too), because it had given me a chance to use in a live project something I had been already aiming to for some time.

AJAX-Solr

The dropping of the Solrj library introduced a need to find out a Javascript library for communication with the Solr backend. After a brief evaluation of the available options I decided to use the AJAX-Solr library.

The two key components used in my project are Managers and Widgets. Manager is a component responsible for composition and execution of a query, while the Widgets process the result. Widgets are registered to Managers and there can be more than one widget registered, so the results of each query can be processed multiple times.

I use more independent Manager components in my application - besides the main Manager to process the search form, there are also Managers (and widgets) for facets, for loading a data of a particular exhibit, and for loading a “more like this” objects for the displayed exhibit.

Knockout.js

While the AJAX-Solr was - one could say - just a Javascript replacement for the Solrj Java library, I needed a library (framework?) to help me to add the dynamics to the search form processing and display of the results. I wanted something rather light-weight and easy to learn, what I could easy embed into our Liferay or Magnolia CMS based solutions. Here I need to thank to Wayne Maurer from Lambda IT, because it was him, who pointed me to the Knockout.js library during our conversation after his SPA talk in Bern in November 2014.

Knockout (KO) implements the MVVM pattern and thanks to its declarative bindings and templates is easy to understand even for team members who don’t know it yet, such as the designers that have to “polish” the developer’s outcome. The AJAX-Solr widgets processing the Solr response are simply putting the data into KO’s observable arrays, and KO handles their proper display.

Disclosure

As usual, when man finishes a project, he learns few (or even a lot of) things he should have known before he started it. In my case, I would do a deeper integration between the KO and AJAX-Solr (probably using the Mapping plugin) and defining a few custom KO components (or elements). Not mentioning that the current Javascript code definitely deserves some optimizations and a bit better organization.

Credits

I have to say that I’ve really enjoyed the work on this project. Not just because the new things I had to learn, but also, no - above all! - because of the people from both KIM.bl and our side of the project. The requests and bug reports from the KIM.bl team were always on topic, well formulated, and quite regularly pointing out the cause and/or suggesting the solution. Ralph, Gabriel - it was a pleasure to work with you! And I must not forget my brilliant colleagues, especially Yuri and Frédéric - the first managing the project and allowing me to focus on the technical side of it, the other making the incredibly good job recasting the original graphic design into the actual HTML/CSS/JS form.

Conclusion

So, the shift from the pure Java developer into being a bit more complex one is not so hard. Yes, there is still a lot to learn, but that’s what developers should do permanently, isn't it? And if you have a good team, and an enlightened customer, you can even enjoy it.