Skip to end of metadata
Go to start of metadata

In this topic:

This page explains what are the new features available in Coveo for Sitecore 4.1. This version is the currently developed solution with a new version coming out approximately every six weeks. 

 

Coveo for Sitecore Comparisonv4.1 1v4.0 1v3.0
Active Development(tick)(error)(error)
Coveo for Sitecore Hive Framework(tick)(error)(error)
Machine Learning (tick)(tick)(error)
Cloud Index (tick)(tick)(error)
On-premises Index(tick)(tick)(tick)
Coveo Usage Analytics (tick)(tick)(tick)
JavaScript Search Framework

2.0+ (for Coveo for Sitecore Hive)

1.0+ (for the legacy Coveo for Sitecore components)

1.0+0.9
Release cycle~6 weeks~3 months

On request only

1See Editions & Pricing for all the features.

All the Sames Advantages as Coveo for Sitecore 4.0

Coveo for Sitecore 4.1 is fully compatible with Coveo for Sitecore 4.0, and supports all of its features (see What's New In Coveo for Sitecore 4.0).

Coveo for Sitecore Hive

The Coveo for Sitecore Hive components allow you to create search pages by adding the components you want directly form the Sitecore Experience Editor (see Integrating Coveo for Sitecore Hive in a Website).

Modularity

Instead of using a single component that strives to do everything, the search page is now split in many smaller pieces, each one representing a Coveo for Sitecore Hive component. Each component has a single responsibility and exposes its specific options.

You can thus move components around much more easily from the Experience Editor.

Easier Website Integration

In previous Coveo for Sitecore releases, the website styling was tightly coupled to the search component view. A developer had to duplicate the search components to create their own, mostly because of styling needs.

Now that the search page is composed of smaller components, you can much more easily move them around from placeholder to placeholder. The Coveo for Sitecore Hive components rely on placeholder settings to determine which components can go where.

You can either use the default settings provided by Coveo or use your own to gain complete control over the component placement.

Reusability of Search-Enabled Components and Pages

In the past, the Coveo for Sitecore components were parameterized through Rendering Parameters. This approach had many drawbacks, such as the inability to merge individual field values. The Coveo for Sitecore Hive components rely solely on Data Source items to get their parameters.

Leveraging Data Sources brings many benefits:

  • Decouples the component settings from the component itself, making it easier to share a common set of parameter values between many components.
  • Merges field values through standard item inheritance. In other words, you can have a Data Source that only sets a field value and inherits values for all the other fields.
  • Supports local and shared Data Sources. When the Data Source item is defined as a child of the page, it is considered a local Data Source. The other alternative is to store the Data Store item elsewhere in the content tree. In such case, it is considered a shared Data Source.
    As the name states, many components can reference the same Data Source item.
  • Supports Sitecore branches to create pre-configured search-driven pages.

Efficient HTML Caching

HTML caching is an important feature in Sitecore. It can make the difference between a website that feels fast and snappy and one that feels slow and heavy. On the other hand, enabling caching when it is inefficient might not bring the expected performance gain and can use a lot of memory.

The Coveo Hive components are designed with HTML caching in mind. Most of the components are "cached by Data Source," which is ideal. In order to achieve that, the rendered HTML depends solely on the Data Source parameter values. With a given set of parameters, the HTML is always the same regardless of the page it is bound to, or the current visitor.

There is one special component that makes HTML caching work for the others: the context component. Its purpose is to render all the non-cacheable information for the other components. The context HTML markup cannot be cached because it varies on many contextual factors such as the current item, the visitor, etc. Once the page is served, all the cached components can then access the context on the client-side and do their work.

Tighter Integration with the Coveo JavaScript Search Framework

Most of the Coveo for Sitecore Hive components are genuine Coveo JavaScript Search Framework components.

The only difference is that Coveo for Sitecore Hive adds a layer, allowing you to visually edit the component properties through standard Sitecore user interfaces. Many components specific to Coveo for Sitecore were added as well. They are also pure JavaScript Search components that could be used as standalone components, outside of Sitecore.

JavaScript Search Framework V2

Coveo for Sitecore now uses the JavaScript Search Framework V2 for its Coveo for Sitecore Hive components instead of V1 (see July 2017 Release (v2.2900.23)). The Coveo JavaScript Search Framework V1 is still used for the legacy Coveo for Sitecore components.

The Coveo JavaScript Search Framework V2 comes with the following new features:

  • Lazy loading means only the code of the components you are using is loaded on the page.
  • Individual placeholder animations for components ensures that, as soon as the component is loaded, it is ready to be interacted with.
  • SVG icons ensure your icons scale no matter the screen size or device.
  • An evolving open-source framework currently under active development (see Coveo JavaScript Search Framework on GitHub).

Upgrading from Coveo for Sitecore 4.0

Upgrading from 4.0 to 4.1 should not be harder than upgrading from one 4.0 release to another. However, you are still encouraged to follow the upgrade steps carefully to ensure the smoothest upgrade possible (see Upgrading from Coveo for Sitecore 4.0 to Coveo for Sitecore 4.1).

  • No labels