SearchInterface Visualforce component
SearchInterface Visualforce component
The SearchInterface Visualforce component takes care of wrapping the JsSearch Visualforce component and includes the correct script and different resource references, as well as the necessary resources needed to create a full search interface.
Including this component in a Visualforce page lets you create a full search page using the Interface Editor.
Usage
Reference it in your Visualforce page as you would for any other Apex component, using the namespace prefix of the Coveo package.
<apex:page docType="html-5.0">
<CoveoV2:SearchInterface />
</apex:page>
Resources included with this component
This component includes the exact same resources as the JsSearch Visualforce component.
JavaScript code included and executed with this component
-
Since it wraps the JsSearch Visualforce component, all the code described in that page is executed.
This includes the creation of the Search Endpoint, with the search token and its renewal mechanism.
-
The
.coveo('init')
call to initialize the search interface (see jQuery extension).
Options
These options are set directly on the Apex component.
name
This option is empty by default.
This specifies the name of the Visualforce component that should act as your search interface.
When a name
is specified, it becomes the default value of the searchHub
option.
<CoveoV2:SearchInterface name="<NAME>" />
Where you can replace <NAME>
with the name you want to specify for your SearchInterface Visualforce component.
catalog
Note
The |
This option is empty by default.
This specifies the catalog ID that the SearchInterface Visualforce component must use.
<CoveoV2:SearchInterface catalog="<MY_CATALOG_ID>" />
Where you can replace <MY_CATALOG_ID>
with the ID of the catalog that you want your SearchInterface Visualforce component to use.
filter
This option is empty by default.
This adds a query expression (or filter) inside the search token generated for the current page. This filter is executed on every query.
Since it’s included in the cryptographically signed JWT token, client-side code can’t tamper with this.
<CoveoV2:SearchInterface filter="<MY_FILTER>" />
Where you can replace <MY_FILTER>
with the filter you want to add to the search token generated for the current page (for example, @sfkbid
).
searchHub
The name of the search hub to be sent to Coveo Usage Analytics (Coveo UA).
This option should have the same value as name
.
Since it’s included in the cryptographically signed JWT token, client-side code can’t tamper with this.
<CoveoV2:SearchInterface searchHub="<MY_SEARCH_HUB>" />
Where you replace <MY_SEARCH_HUB>
by the name of the search hub when reporting events to Coveo Usage Analytics (Coveo UA).
Note
If you read the documentation about the Analytics component), you will realize that it’s also possible to set the
|
Important
Having a conflicting search hub in the body of the request and the search token results in the analytics event being rejected. The response from the service looks like this:
|
debug
The default value is false
.
Setting this value to true
causes the debug version of the JavaScript libraries to be used.
The debug
versions aren’t minified.
In a production environment, we strongly recommend that you use the minified version for faster download times of the resources as well as marginally faster execution time.
For debugging purpose, you can enable this option to read the source code more easily.
<CoveoV2:SearchInterface debug="false" />
userGroups
This is the list of user groups to append to the current user, separated by semicolons. Each of these user groups is added in the search token.
Since it’s included in the cryptographically signed JWT token, client code can’t tamper with this.
These user groups are used in Coveo UA as additional reporting dimensions.
<CoveoV2:SearchInterface usersGroups="<GROUP1>;<GROUP2>;<GROUP3>" />
Where you can replace <GROUP1>
, <GROUP2>
, and <GROUP3>
by respectively the name of the user groups to append to the current user.
You can add as many user groups as you want.
additionalUserIdentities
List of user identities to append to the current user, separated by semicolons. Each of these identities are added in the search token and allow a given user to add other identities that this user should have.
<CoveoV2:SearchInterface additionalUserIdentities="john@doe.com;jane@doe.com;name=doe\jane,provider=Active Directory,type=User" />
If you need to specify other security providers, you can specify them with param=value
separated by commas where:
-
name
is the identity name -
provider
is the security provider name. The default value isEmail Security Provider
. -
type
is user or group. The default value isUser
.
Since it’s included in the cryptographically signed JWT token, client code can’t tamper with this.
This could allow users not logged into Salesforce to be able to query as if they were another anonymous user and allow them to see public items.
This could also be used to map a Salesforce user to an Active Directory user, or any other system.
anonymousUser
Specifies the identity to use for non-logged in users.
<CoveoV2:SearchInterface anonymousUser="<IDENTITY>" />
Where you replace <IDENTITY>
with the identity you want to use for non-logged in users (for example, anonymous@user.com
).
searchContext
<CoveoV2:SearchInterface searchContext="{!context}" />
This allows you to create an additional context inside your search page (see Send Apex context to a JavaScript search interface).