README

• Purpose
• Delivery
• Installation
• Feature support
• Getting started
  • Simple usage
  • Detailed result handling
  • Detailed querying
• Available service integration modules

Purpose

To provide you (a Silverstripe developer) with interfaces for search querying that do not change, even when you switch between different search service providers (EG: Elastic, Algolia, Silverstripe Search).

Delivery

To deliver on our purpose, the way that you perform filtering, faceting, and certainly the way that you display results, is very likely going to change. We hope that the learning curve is reasonable, and that the majority of developer interactions with this code is intuative (once you understand the mentality behind it).

You will not be able to perform any sort of "raw filtering" or "raw querying" with service specific formats, as that would not meet the purpose of this module - which is to use a common interface that will allow you to easily switch between services.

Installation

Note: this module does not function without an integration module

If you want to install this module for developing your own integration module, then you can install it with:

composer require "silverstripe/silverstripe-discoverer"

If you are planning to search through a page and controller, then you might also want to consider using Silverstripe Discoverer > Search UI

Feature support

Whether or not certain features are supported by this module. Noting that different search providers often do things in different ways, and often have different levels of support for features. This module attempts to provide a level of functionality that is commonly supported by many different services.

Getting started

• Querying, filtering, faceting, etc, will now all be performed through interfaces that are provided by this module. There is no ability to perform (eg) "raw filtering", or "raw faceting", where you pass data that is in a specific format for a specific search service provider. This would break the purpose of this module, since if your search service provided changed, then your "raw filtering" would also likely break.
• This module does not assume that your search Documents relate to a DataObject, as such, it is recommended that your search Documents contain all of the data required for you to build out search results without needing to query the application for any additional information.
• When you perform a search, you will receive a Result object that includes a PaginatedList of Record objects. The Record objects will contain any/all information that you requested during your query, and this is how you will output info into your template.
• Fields within your Record objects will match the fields in your search index, but be converted to PascalCase, with abbreviations presented as (eg) Id, Url, etc. You can read more about this under Field convensions.

Additional documentation can also be found below:

• Simple usage
  • Provides some basic code samples.
  • Includes a bit more detail on how Results and Records work.
• Detailed result handling
  • Lots more information about Results, Records, pagination, analytics.
• Detailed querying
  • Lots more information about filters, facets, sorts, and (hopefully) everything else you need to know to perform whatever sort of search you require.

Protected field names

You're mostly free to use any field names you would like when configuring your data sources, however, there are 2 methods provided in our Record class that will effectively override any field that is made available under:

• AnalyticsData
• DecoratedLink

Available service integration modules

• Silverstripe Discoverer > Elastic Enterprise Search
• Silverstripe Discoverer > Silverstripe Search