Afterword

Firstly, my sincerest thanks for getting this far through the book. I found it quite pleasurable (at most of the times) to write, and I hope that you have had the same experience reading it.

Although my most fervent wish is that you find the Panl project to be useful.

On The Tag-Line


A rather pleasing companion to the Apache® Solr® Faceted Search Engine.


I wrote this line as a first draft with a definite understated tone.  Although, as I progressed through writing the book it resonated more with me.  Firstly, I do not like to emphasise my skills or work - believing the work should speak for itself, so it fits nicely with my personal views on life.  Secondly, the Panl project implementation should be understated, something which sits in between a web app and the Solr Search server and just happily does its job, hidden between the layers.

I also like the name Solr Panl, it has a certain ring to it - the original tagline at project inception in 2008 was "Panl - soaking up the Solr goodness".

On Documentation

My view on documentation is that it is something that everyone loves to read, but few people like to write.  And when I write 'documentation', it comes in many sources, from the actual source code and tests of a project, to the generated documentation, the StackOverflow posts, the Search Engine searches, the blog posts, videos, and books.  

The thing about writing documentation of any type, is that it makes you a better engineer/developer/coder and leads back to questioning your design principles and architecture.  I have never had any hard and fast rules around architecture and some of the decisions made in coding the Panl project was to make the implementation and integration easier for the engineer when it came to parsing the JSON results and debugging/testing through the Panl viewer and explainer web apps.  This led to some design decisions which coupled to code far too tightly - which was a deliberate decision.  Ease of understanding over architectural purity.

Documentation can be time consuming and difficult to do - perhaps this is why documentation can be such a low priority for people, and it can be a grind to get through, constantly writing and updating text and formatting, adding in new features and having to revise the entire book to ensure that everything gets updated and referenced properly.

Just by writing this book, by having to explain how it all fits together, new ideas and ways of doing things have come to my mind, which leads to even more edits of the book.

When you have to explain a decision to someone, or how something works, you are given a second chance to review what you have created, and have to put yourself in the shoes of the reader and ask yourself the same questions about what you are doing. Questions such as:

  • Why did you decide to do things this way?
  • Would I be able to change the way it is done?
  • How can I configure it to do this?
  • What about if I want my search results page to work like this?

It also means that you are not as easily able to hide functionality that should be there but isn't, by not including something you are publicly saying that you either

  1. Didn't know about it, or
  2. Couldn't be bothered to implement it, or
  3. Hoped that people wouldn't notice.

From this perspective I have changed the underlying code and features and functionality that is present within the Panl server.  Some of the changes include

  • Not having a configurable /panl-results-viewer/ and /panl-results-explainer/ URL path, instead you may either turn on or off this functionality.  This would have been a straightforward change, but the benefits were slight, new properties would have to be added, and this only occurs if there is a collection named exactly panl-results-viewer, or panl-results-explainer.
  • Implementation of pass-through (or ignored) URL paths - and the additional property for keeping this token in the canonical URL generation.
  • Less verbose 404 and 500 error messages
  • Translation of boolean fields from true or false to something more human readable
  • Added in DATE Range facets
  • Highlighting, although in this instance I deliberately chose a subset of functionality to implement
  • Hierarchical facets, only displaying a facet and its value if another facet has already been selected.
  • Better way of implementing OR facets in the way that they work.
  • Sorting of facets by (to use Solr nomenclature) index or count.

All of this has made the product a better one, and if nothing else, I thoroughly recommend writing a book, or at the very least a HOW-TO on whatever project you are working on.

Additional Functionality in the Pipeline

The codebase for this project started in 2008, now after languishing for a long time, 16 years later, it has come a long way.  Not all features and functionality made it into the code base, some from time and effort of implementation, some from documentation, and finally, something just had to be produced and put out into the wide world.  

In general it came down to drawing a line under the current functionality, after all...


Code is never complete, it is just abandoned.


Not all of the features will make it into the next release and may be de-prioritised.  The list is not in any particular order

  1. Additional support for Solr field types
    Some will be implemented, some will probably be ignored (anything geospatial is probably not going to be included).
  2. Single search page [Released in version 9.1.0]
    Being able to have a search landing page with all options available, with the ability to implement a single search page (the example below is a screenshot of the search page for https://www.realestate.com.au).



Image: A single search page showing all options - from https://www.realestate.com.au

  1. Hierarchical facets based on value
    Being able to only show facets if another facet has been selected with a specific value.  This is probably not the best feature to include as it ties the configuration with the data values, which may change over time.
  2. Facet value replacement
    Being able to replace values for specific values of any facet, although this feature would tie the dataset and the Panl configuration together more tightly than I would like.
  3. 'More Like This' functionality
    The ability to return 'more like this' results on a certain field, or FieldSets.
  4. Dynamic range functionality [Released in version 9.1.0]
    Dynamically generate the minimum and maximum value for a range for a facet value.
  5. Suppress range values [Released in version 9.1.0]
    For a RANGE facet, provide a configuration option to suppress the values that appear in the range as separate values.
  6. Returning more facets for a specific facet field
    By default, the facet limit is set to be 100 facet values per facet, in the instance where the returned number of facets are greater than this value, the facets will be truncated.  The Panl server should be able to return the remaining facets with a simple query, without returning any documents with it.  This should be done on an individual facet and possibly have pagination.
  7. Default empty FieldSet [Released in version 9.1.0]
    In addition to the 'default' FieldSet, add another FieldSet always named 'empty' which will return no fields (this links in with the 'Returning more facets for a specific facet field' and 'Single search page' items).
  8. Internationalisation [Released in version 9.1.0]
    Floating point digits in particular suffer from using a full stop/period as a decimal place i.e. in the UK, a digit would be formatted e.g. 12,345,678.90, whilst most other European countries use a comma for the decimal place e.g. 12.345.678,90.
  9. DATE Range facet update
    As an extension to internationalisation, the DATE Range facet could do with an update to ensure that the SEO URL is better suited to international uses.  For example, this facet will respond to <range_identifier><value><range_type> - e.g. 'previous 30 days' however for other languages this is not the most suitable - e.g. in French it might be '30 jours précédents' as in <value><range_type><range_identifier>.[19]
  10. Integrated typeahead
    An example and implementation of type-ahead in the search results.
  11. Additional text query options
    Add in an LPSE code to be able to search on a specific field, fields, or all fields, rather than the default search field, or search for individual fields.
  12. Panl configuration editor
    A GUI to edit (and validate) the Panl configuration files making it easier for a developer to get the configuration correct.

~ ~ ~ * ~ ~ ~

In any case, I hope that you enjoy - and more importantly, implement and use - the Panl server for your Solr search server implementation.

~ ~ ~ * ~ ~ ~