Configuring SiteSeeker Search Integration Module
2012-05-07The SiteSeeker API is developed with flexibility and configuraiton as a first class citizen. In this article the the architecture and the usage scenarios will be discussed.
Introduction
Developing a product that suits everybody's need can be challenging as most companies operate in unique ways. We architected the module with this in mind. By opening up our Search API for extention and allowing the customer to replace / override the default implementations which are provided by SiteSeeker.
When developing the EPiServer Search Integration plugin, we built that on top of the API, which allowed us to bootstrap the system specifically tailered to EPiServer.
Architecture.
The Architecture can be described following these design principles.
Open-Closed Principle
"Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification [Martin, p.99]"
this means that we no longer provide the source code (which would be open for modification), but rather provide you with our SiteSeeker assembly (which is closed for modification), but contains extension points which will ensure that you can achieve the result that you require even if the default implementation does not suit you. We will touch on the extension point in the Extended configuration section.
Inversion of Control
The architecture revolves around the principles of Inversion of Control (IOC), which allows for our architecture to contain less coupling but higher cohesion, and will allow us to adapt the code quicker to implement new requirements and features built upon this solid foundation. We chose the Windsor IoC framework to built our system upon.
Its through this implementation that the system opens up the ability for you as a consumer of the API to supply the system with your own implementation of e.g the authorizationFilter.
The BootStrapper
The bootstrapper is the heart of the configuration of the system. Through the BootStrapper you can do the following:
- Initialize()
- Initialize(SystemConfiguration configuration)
- Initialize(params SiteSeekerServiceOverride[] globalServiceOverrides)
You can initialize the system, and pass in the System configuration or an array of components that you want to override on a system level.In below example we are replacing the default localization and authorization components with our own.
BootStrapper.Initialize( new SiteSeekerServiceOverride(typeof(ILocalizable)
,typeof(MyCustomTextLocalizer)), new SiteSeekerServiceOverride(typeof(IAuthorizationFilter)
,typeof(MyCustomFilter)));
- RegisterHtmlHelper<>()
Allows users to regiser their own HTML helpers or register some of the default helpers provided by SiteSeeker.
BootStrapper.RegisterHtmlHelper<Html5Helpers>(); BootStrapper.RegisterHtmlHelper<XHtmlHelpers>(); BootStrapper.RegisterHtmlHelper<CustomHtmlHelper>();
RegisterSearchIndex(SiteSeekerSearchIndexConfiguration configuration, params SiteSeekerServiceOverride[] serviceOverrides)
The Search Index is the heart of the system which allows you to do searches and received search results. You might want each SearchIndex to work different from each other. One needs to filter for employees only, while the other will use the default filtering module. Below is an example of that.
BootStrapper.RegisterSearchIndex(searchConfiguration("index1", ""
, "http://test1.com", "", ""),
new SiteSeekerServiceOverride(typeof(IAuthenticationFilter),
typeof(EmployeeFilter)),
BootStrapper.RegisterSearchIndex(searchConfiguration("index2", ""
, "http://test2.com", "", "")
