Last week, we released Coveo for Sitecore 4.1, and with it the Coveo for Sitecore Hive framework. Obviously, the documentation followed as well as a high level blog post, but I wanted to explain in my own words what this release is all about.
Coveo for Sitecore 4.1 VS Coveo for Sitecore Hive
The first thing to understand about version 4.1 is that it is only a vessel carrying the Coveo for Sitecore Hive framework. You could use 4.1 the same way you used 4.0, which in a sense greatly reduces the upgrade effort. Coveo Hive is optional once you upgrade to 4.1, but it will become the main UI framework for all future versions of Coveo for Sitecore. This means that the legacy Coveo for Sitecore renderings and sublayouts will one day disappear.
Keep in mind that Coveo Hive is MVC only, although if you are still using Web Forms, you are already due for an upgrade.
As you can see in the image above, the two frameworks now coexist, but for this version only!
Experience Editor, code reusability, and easier upgrades
Sitecore is pushing everyone to the Experience (XP) Editor, and this is also where we are heading with Coveo for Sitecore Hive. Although the legacy renderings were editable in the XP Editor, adding and removing features was often controlled by a property on the main Coveo Search item. With Coveo Hive, you build a page block by block, which might feel harder at first, but will offer a lot more flexibility in the long run.
By separating these components, we can tie them to their individual data sources item, which facilitates reusability.
A developer could create a set of data sources ready for their authors, and help them create pages faster and reuse components across the solution.
To keep everything clean, data sources folders are set in branches and ready to be included in your solution when needed.
In brief, it decreases the gap between the development team and authors, allowing the first to build presets for the latter to use them when needed.
Finally, smaller components means rendering files with less code and a unique purpose. If you wish to change the behavior of the pager, then you can simply create a custom pager component instead of overriding the entire Coveo Search component. It makes it easier to keep track of changes and smooths the upgrade process.
I mentioned the data sources earlier. Well the HTML is now bound to these data sources, which allows for a proper HTML caching of all the Coveo Hive renderings. This was not the case with the legacy components and should make a difference when it comes to site performance.
We have quite a list, and I could not fit all in that screen capture.
Now let’s look at the requests and the resources for a page with only the search box and a page view tracker.
Much lighter! And keep in mind that this search box is not limited like what was offered in the legacy components with the Search Box Resources item. The search box in this example will provide machine learning powered query suggestions and other search box features.
And if you don’t know already, the whole framework is open source so help yourself if you want something to change.
So what’s next?
If you are an existing Coveo for Sitecore developer, I hope I convinced you to go ahead, try the new framework, and make it your default solution for future projects. If you have never used Coveo, be aware that we are now not only the most feature full search solution in Sitecore, but we are also (in my opinion) the easiest to use. So please go ahead and download the trial.
See you there!
PS: Massive thanks to the Sitecore Community and especially the MVP who gave a lot of feedback on version 3 and 4. Also a very special thank you to Kamruz Jaman for showing us how to do caching properly.