Drupal's Search Framework: The execution of a search
public
group: Search
robertDouglass - Fri, 2008-04-25 07:26
Drupal’s ambitious search module provides a framework for building searches of all kinds. By isolating the tasks involved in searching, and allowing the actual search implementations to be handled by other modules, the search framework sets the stage for all sorts of creative search applications. This article, which applies to Drupal 6, explores the structure of the search framework by following the steps needed to execute a search.
Full article: http://acquia.com/blog/drupals-search-framework-the-execution-a-search
Nice work
Very valuable to have this process laid out in such clear detail.
One thing this got me thinking about is: our search architecture is fundamentally shaped by the need to be able to reproduce any search through a path. Our specific implementation:
/search/node/keyword1+keyword2+operand1:myvalue
where "node" is the module handling the search, keyword1 and keyword2 are keywords and operand1 is a search operand, e.g., node type.
Keeping search data in the path is a very sound decision. But I question our use of arg(1) (in this case, "node") as the module implementing the search. This use of arg(1) has two major implications:
Awhile back I did up a hackish module, http://drupal.org/project/search_all, that pulls the various search implementations onto a single page, allowing searching for all types of data in one place. That partly addresses the issue that users need to know what they're searching for before searching, but leaves the more fundamental issues untouched.
Should we drop the arg(1) and instead reserve a special operand for designating a specific search implementation? That would leave:
/search/keyword1+keyword2
Search for anything (nodes, users, terms, etc.) matching the requested keywords.
/search/keyword1+keyword2+operand1:myvalue+entity:node,user
Search only nodes and users.
Great points
I don't think arg(1) is evil, but I do think hardcoding it to a module name is restrictive. Solr lets you define any number of request handlers (by stringing together available Java classes in the schema.xml file), and you use the equivalent of arg(1) to address them. I think this is a nice way to do it.
What if naming your own
What if naming your own handler done during the definition of a new "search interface", this would allow the site owner to determine how the url looks for each interface within the context of their own site. I'm not positive if faceted search does this already.
Search Contexts
This is what I had in mind as well. I found that we needed different search UIs at different paths in a recent implementation of a Drupal/Solr site. Depending on the URL, I set different "search contexts," which are really just additional search parameters that get appended to all searches with a given path. You could expose those additional parameters via the URL as nedjo points out and not directly reflect them within the UI, say within a search breadcrumb or a "You Searched on Blah" message.
With this in mind, I do wonder what you all think about pegging "search interfaces," as BlakeLuccgesi suggest, to user-defined paths.