silverstripe / silverstripe-discoverer
Service agnostic abstraction of search querying requirements
Installs: 395
Dependents: 3
Suggesters: 0
Security: 0
Stars: 1
Watchers: 7
Forks: 1
Open Issues: 1
Type:silverstripe-vendormodule
Requires
- php: ^8.1
- silverstripe/framework: ^5.2
Requires (Dev)
- phpunit/phpunit: ^9.5
- slevomat/coding-standard: ^8.8
README
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 aPaginatedList
ofRecord
objects. TheRecord
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
andRecords
work.
- Detailed result handling
- Lots more information about
Results
,Records
, pagination, analytics.
- Lots more information about
- 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