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.

Panl allows

1. Multiple ways to slice and dice the underlying Solr collection and present them with different URLs
2. Prefixes and Suffixes for all facets, additionally, infixes can be configured for RANGE facets
3. Value replacements for Boolean data types
4. Field value validation to help avoid Solr exceptions
5. Hierarchical facets, only showing specific facets if another facet has already been selected
6. Sorting of facet values by either count (the default) or index.
7. Sorting by any of the fields or facets
8. Pagination - in built with all information available to implement your specific pagination user interface
9. Static site generation - for small datasets with few options.  Alternatively they can be seen as easily cacheable and canonical sources for the returned results.
10. Text configuration files - All configuration for Panl is based on text files so they can be stored in a source code management system.

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^[6] Solr query (828 characters) of

q=*:*&facet.mincount=1&rows=10&facet.field=lead_size_indicator&facet.field=grip_material&f
acet.field=colours&facet.field=nib_shape&facet.field=diameter&facet.field=cap_shape&facet.
field=brand&facet.field=mechanism_type&facet.field=length&facet.field=hardness_indicator&f
acet.field=grip_type&facet.field=cap_material&facet.field=lead_grade_indicator&facet.field
=tubing_material&facet.field=in_built_sharpener&facet.field=disassemble&facet.field=catego
ry&facet.field=body_shape&facet.field=clip_material&facet.field=mechanism_material&facet.f
ield=lead_length&facet.field=body_material&facet.field=in_built_eraser&facet.field=grip_sh
ape&facet.field=relative_weight&facet.field=name&facet.field=nib_material&facet.field=weig
ht&facet.field=variants&facet=true&fq=brand:"Caran+d'Ache"&fq=disassemble:"true"&fq=colour
s:"Black"&q.op=AND

The three types of LPSE codes

1. Filters - codes that filter (and generally narrow^[7]) the results - these are either the search term or a facet (Regular, Boolean, OR, DATE Range, or RANGE)
2. Parameters - codes that change the way the returned results are displayed - these are the sorting orders, number of results per page, and page numbering.  These do not filter what results are returned.
3. Operands - codes that change the way in which the filters work, for Panl the only operand available is the Solr query operand.

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.
          /products-by-brands/Caran+d'Ache/b/
2. Is then proxied through to the desired Panl CaFUPs URL path
          /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, and LPSE code.

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.
• Panl DOES NOT include all of the options that are available to the Solr query parser, however it does cover all 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", 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).

~ ~ ~ * ~ ~ ~