Jun 3, 2009
visibility 4398
star star star star star
(2 votes)

EasySearch and Turbo Charged FindPagesWithCriteria

We designed EasySearch as both a full text search engine and a structured data search engine. This is to say that EasySearch can be used to search for named property values of EpiServer pages using common query operators. The cool thing is that it can do this very fast over very big data.

This post describes how one project has used this technique to great effect to construct page lists throughout a site. One of the main reasons mentioned for using EasySearch is that the in built EPiServer functionality for page searches based on property values is limited to writing SQL (a bit of a no-no), writing code against the object model (slow and laborious) or using the FindPagesWithCriteria method. This method doesn’t scale well as it needs to load pages to decide if they should be returned.

EasySearch stores the data in a query optimised fashion and therefore doesn’t have any page load overhead when executing the query. It provides a way to create structured queries that go directly against its Lucene index. Now, while the Lucene query language is very powerful, it would be nice to be able invoke a method to execute a query. I chatted with another EasySearch contributor, Mari Jorgensen, about structured search and we agreed that having a simple method call to do 80% of the queries people need would be a good thing to do. So, our current plan is to generalise the approach described by Andreas to provide a new implementation of FindPagesWithCriteria that goes against the EasySearch index.

We are also considering a LINQ provider, but that’s a little more work. However, Andreas already alludes to something similar when he talks about domain models and classes for EpiServer page types.

The comment I really like in Andreas’ post is the following ‘Now we have a site where it’s super easy to fetch data to all sorts of listings with content coming from all over the place, for instance we can easily get news/tips/weather info/track info etc. for any given event (the domain is betting on horse races) which frees the content editors to create the content in the places where it makes sense for them to do so’. This decoupling of content creation and content publishing is the key to a compelling editorial and end user experience.

Jun 03, 2009

Comments

Sep 21, 2010 10:32 AM

Agreed. Using search engines to generate listings and related information is a very compelling alternative due to the fact that they're optimized for these kind of searches. The fact that easy search is event and property based (ie, not crawling the site every n:th hour and using the episerver properties as its data source) makes it a very good alternative for listings based on a structured criteria.

Nice meeting you in Oslo Graham. Now start working on the Linq provider :)

error Please login to comment.
Latest blogs
Exploring Asset Lifecycle Management Approaches for Bynder and Optimizely SaaS CMS

Note: This is Part 3 of our Bynder integration series. For setup and filtering prerequisites, see Part 1  and  Part 2 . Introduction In my previous...

Vipin Banka | Jul 5, 2026

Unlock AI-Ready Experiences with Optimizely

Over the past few months, almost every customer conversation has shifted from SEO to AI readiness. The questions are no longer just: “How do we......

Madhu | Jul 5, 2026 |

Planning Your Bynder DAM and Optimizely SaaS CMS Integration the Right Way: Avoiding Asset Sprawl and Unnecessary Synchronization

Note: This is Part 2 of our Bynder integration series. If you missed the Part 1, check out " Implementing the Bynder DAM Connector with Optimizely...

Vipin Banka | Jul 4, 2026

Implementing the Bynder DAM Connector with Optimizely SaaS CMS: Lessons Learned

What I learned while integrating Bynder DAM with Optimizely SaaS CMS, exploring Optimizely Graph, and building a headless frontend experience....

Vipin Banka | Jul 3, 2026