Why Synapticloop Panl?

Panl was designed to convert rather long and unfriendly (both in human readable and SEO terms) to shorter, nicer, and friendlier URL paths throughout the entire search journey.

Working with a Solr schema, the Panl configuration files translate unwieldy URL parameters into concise and precise URL paths.

In addition to the Panl Niceties detailed in the previous section, Panl was designed to

1. Have SEO friendlier URL paths with much shorter URLs than traditional query parameters.
   
   (This was the primary driver of the Panl project, especially from a human-readable perspective.)
2. Abstract away the complexities of the Solr query string - being able to have a simple interface through the URL which then generates complex queries.
   
   Not having to fully understand how Solr works in the back-end abstracts away the complexity of a front-end integrator and reduces the need to have the back-end and front-end understand each-other.
3. Be quick to start up and easy to configure.
   
   During development of a solution, being able to quickly iterate over a solution, or change the way that Panl is configured is a must have.  Additionally, having all configuration as text files means that upgrades to the Panl server is straight-forward and hassle free.
4. Protect Solr from errant queries .
   
   Hiding the Solr implementation details from the end user and parsing, decoding, and validating the URL before passing the query through to Solr.  Additionally, Solr has a tendency to return an internal server error when the query string is not as it expected, and this should not disturb the return of the results.
5. Be able to present the same Solr collection in multiple different ways.
   
   A single Solr collection should be able to serve up different fields and facets from the result documents without any back-end logic.
6. Have a configuration file drive the generation of the UI as much as possible.
   
   Rather than hard-coding facets and then determining how to display them, being able to have a returned JSON response which can be interrogated to determine how the facets should be displayed.

What is a LPSE (pronounced 'lapse') code?

The LPSE acronym stands for Last Path Segment Encoding, deriving its name from using the last part of the URL path as a code.

In effect the (29 characters) Panl LPSE query of

/Caran d'Ache/true/Black/bDW/

For the above Panl URL path, the LPSE code is bDW, with the query of /Caran d'Ache/true/Black/, this gets translated to

• The brand Solr facet field is set to Caran d'Ache (using LPSE code o f b), and
• The disassemble Solr facet field is set to true (using LPSE code of D), and
• The colours Solr facet field is set to Black (using the LPSE code of W)

Contrast this with the equivalent^[9] Solr query (828 characters) of

q=*:*&facet.mincount=1&rows=10&facet.field=lead_size_indicator&facet.field=grip_mat
erial&facet.field=colours&facet.field=nib_shape&facet.field=diameter&facet.field=ca
p_shape&facet.field=brand&facet.field=mechanism_type&facet.field=length&facet.field
=hardness_indicator&facet.field=grip_type&facet.field=cap_material&facet.field=lead
_grade_indicator&facet.field=tubing_material&facet.field=in_built_sharpener&facet.f
ield=disassemble&facet.field=category&facet.field=body_shape&facet.field=clip_mater
ial&facet.field=mechanism_material&facet.field=lead_length&facet.field=body_materia

l&facet.field=in_built_eraser&facet.field=grip_shape&facet.field=relative_weight&fa
cet.field=name&facet.field=nib_material&facet.field=weight&facet.field=variants&fac
et=true&fq=brand:"Caran+d'Ache"&fq=disassemble:"true"&fq=colours:"Black"&q.op=AND

The effect of the two queries are identical, returning the same results, just with a much shorter URL.

As an example of a search performed on the Walmart site, the search URL of  (281 characters)

https://www.walmart.com/search?q=mechanical+pancils&min_price=4&catId=1229749_9412206&facet=subscription_eligible%3ASubscription+item%7C%7Cexclude_oos%3AShow+available+items+only%7C%7Cpencil_lead_size_pencils%3A2.0+mm+to+3.0+mm%7C%7Ccount_per_pack_facet%3A1+-+4%7C%7Ccolor%3ABlack 

If implemented with the Panl server could be the following URL of (196 characters):

https://www.walmart.com/search/mechanical-pencils/from-4$-to-15$/pencils-and-pencil-sharpeners/subscription-eligible/in-stock/lead-size-from-2.0mm-to-3.0mm/4-items-per-pack/black/qp+pdsil+lrc/

Which is shorter, far more readable, and much more SEO friendly.

The three types of LPSE codes

1. Filters - codes that filter (and generally narrow^[10]) the results - these are either the search term or a facet (REGULAR, BOOLEAN, OR, DATE Range, or RANGE)
2. Parameters - codes that create a subset of the results to be returned - these are the number of results per page, and page numbering.  These do not filter what results are returned, just select which of the queried results are returned.
3. Operands - codes that change the way in which the filters work and DO NOT have a URL path value, for Panl the only operands available are the Solr query operand, and the Sort orders

URL Path Nomenclature

As the design considerations were made mainly around URLs and the niceties that could be afforded to them, here is the nomenclature used throughout this book. For any URL path:

1. The the Web Server URL path, e.g.
          /pencils-by-brands/Caran d'Ache/b/
2. Could then proxied through to the desired Panl CaFUP
          /mechanical-pencils/brand-fields/Caran d'Ache/b/
3. Which will return the results from the mechanical-pencils Solr collections, only returning the fields in each document that are contained in the configuration of the brand-fields.

The Panl URL path is made up of the following parts

When references to the URL path are made throughout this book, they refer to the Collection, FieldSet, LPSE value(s), and LPSE code(s).

Is Synapticloop Panl For Me?

The tagline for Panl is "a rather pleasing companion to the Apache Solr Faceted Search Engine", and that is how it was designed and coded.  Pleasing, as it is designed to be developer implementation friendly, makes Solr nicer to work with, and the URL paths much more friendly to read (both for humans and search engines).

However, you may have a different point of view, so, before diving into it, you should evaluate whether this project is suitable for your needs. Panl is constrained by the following:

• You MUST be using a managed schema for Solr, Panl will NOT work with non-managed, or derived schemas (in fact Solr requires a managed schema for production deployments, so this will only affect the initial testing phase of your project).
• You MUST be using a Java version of at least 11.^[11]
• Panl DOES NOT include all options that are available to the Solr query parser, however it does cover a lot of functionality required for a pleasant and powerful interface into the Solr search features.
• Panl WILL NOT ALLOW complex Solr query parameters (the Solr query parameter is passed through enclosed in double-quotes "), so if you need to do complex hand-crafted queries, these are not available, for example "jakarta apache"^4 "Apache Lucene"^[12], or a query that relies on using any of the characters with a special meaning (+ - && || ! ( ) { } [ ] ^ " ~ * ? : /).
• Panl IS NOT REALLY designed to be publicly accessible, instead it is designed to sit behind a proxy or service forwarder, so there is a requirement to be able to configure a proxy or service forwarder.
• Panl IS PERMISSIVE - there is no authentication, or access control lists.  If you don't want a user to be able to query the Panl server, or restrict access to a certain subset of results, then you will need to implement your own authentication, authorisation, and security layer (which comes with its own challenges).

~ ~ ~ * ~ ~ ~