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 allows you to 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

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

The catalog option is exclusive to CloudCraze and Salesforce B2B (see Add the Coveo Searchbox in Your Salesforce B2B Commerce Storefront Search Page.

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 (e.g., @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).

If you read the documentation about the Analytics Component), you will realize that it’s also possible to set the searchHub using the option on the component itself. However, we recommend that you set the searchHub on the SearchInterface Visualforce component.

  • If you use the data-search-hub property on the Analytics Component, then the search hub attribute will be passed in the content of the request, as the originLevel1 property.

  • If you use the searchHub option in the Apex component, then the search hub attribute is passed in the header of the request, in the JWT search token.

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:

You are not authorized to insert events in search hub X since your token restricts you to Y.

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 is Email Security Provider.

  • type is user or group. The default value is User.

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 (e.g., 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).

What's next for me?