Search for ASP.NET Documentation: Central Event System (Plug-ins)

Central Event System (Plug-ins)

Overview

The behavior of the search engine components can be customized and/or extended through standard sub-classing, or through the Central Event System. By specifying your own custom logic in an assembly you can, for example, filter documents, override file contents, assign documents to location or content categories (see Example) etc. The Central Event System is relatively simple, and consists of 2 parts; events fired from the search engine code and code that will handle some or all of the events (usually a custom built DLL). Essentially, a simple custom DLL can be created and pointed to in the search configuration - it will then be loaded and initialized by the search engine.

The events are typically

Notification that an object is being created
Notification that something is being processed (eg. the result list was made, or a document was read)
Notification that a decision is being made (eg. whether to index a document, or crawl a page)

The event argument objects are mutable, so they can be changed - eg. the result list can be resorted, or word can be taken out of a newly read document.

The pro's & con's of customization via the Central Event System or through sub-classing are;

Central Event System

Custom code is run during any operation regardless of process (Windows Service, Admin app., programmatic, Visual Studio design time, etc.)

Customizations are attached to an Index Directory, rather than an application, so the customizations are more portable

Accessing deep parts of the system can be simpler than sub-classing

Event based customizations are less granular than sub-classing

Sub-classing

Custom code is run only when the current process has instantiated the sub-class, but since provided tools will not be able to do this the indexing operations must always be performed programmatically

Customizations are attached to the programmatic code that runs the operations, and are therefore less portable (they won't be used if the Windows Service runs for example)

Accessing deep parts of the system can be complicated if the intended target class is not directly used by a top layer class (eg. DocumentIndex)

Sub-classing can override most members and therefore provides a greater level of granularity