Starting with VuFind 1.0, most of VuFind's search controller behavior (collecting user parameters, handling facets, paging, etc.) was isolated to a family of classes known as Search Objects. This reduces code redundancy when dealing with common problems, and it allows new search modules (using mechanisms other than Solr) to be built more quickly.

Currently, separate Search Objects are used for Solr, Solr Authority, Summon and WorldCat searching. A large amount of basic functionality is able to be shared between all of these modules.

Search Objects are constructed using the SearchObjectFactory class in web/sys/SearchObject/Factory.php. Based on a search engine parameter, this factory class loads the appropriate SearchObject class (named SearchObject_[engine]) from a file in the web/sys/SearchObject directory (named [engine].php). All Search Objects are extensions of an abstract SearchObject_Base class found in web/sys/SearchObject/Base.php.

To implement a new search feature, you need to do a few things:

• Implement a new SearchObject class that extends SearchObject_Base. At the very minimum, be sure to implement all of SearchObject_Base's abstract methods.
• Build a new module to call the new SearchObject class. You may want to use web/services/Summon/Search.php or web/services/WorldCat/Search.php as a template.
• Edit the deminify method of the SearchObjectFactory class to recognize your new SearchObject type. This is necessary in order to restore compressed SearchObjects that have been stored in the database.
• If your SearchObject contains new properties that need to be restored after compressed storage in the database, you may need to modify the minSO class in web/sys/SearchObject/Base.php to account for them. If possible, avoid the creation of new properties in order to keep things simple!
• Test that searches generated by your new SearchObject show up correctly in the history at http://[your_vufind_server]/vufind/Search/History. This is the main area where multiple SearchObjects need to coexist peacefully.

The Search Object architecture is still a work in progress – this is an area of code likely to see further refactoring in the future as more of the interface is standardized and complexity is reduced. If you develop a new Search Object, you should expect to do some work from time to time to keep it in line with the trunk code.

A few enhancements are desirable in the future; these are some of the reasons that future changes are expected:

• Some of the SearchObject classes (particular the Solr one) have some complex special cases that should be simplified.
• For use in more contexts, it may be desirable to make the SearchObject classes less directly tied to particular request parameters.
• The overall VuFind interface needs a better mechanism for allowing access to new search modules. Right now, each module (Search, Summon, WorldCat) stands alone… but it would be better to have a way to guide users between different kinds of searches when appropriate. This may or may not have an impact on the SearchObjects themselves.
• Search actions (the controllers that actually instantiate and call the SearchObject) are very similar across modules – it may be desirable to find a way to share more of this logic.