Decouple front end from core search implementation

I was just looking for an excuse to play around with my new Omnigraffle Pro license today; the BoF Solr/Search Architecture discussion seemed like a good candidate. I'm attaching a basic map of where I *thought* we ended up. Please feel free to grab the graffle and modify it as necessary.

Just a note: It would be beneficial to abstract not only the search engine, but also the search data (i.e. decoupling from nodes).

A use case: The translation server needs some kind of faceted search for searching strings. Those strings, however, are not stored as nodes.

Early on when developing Faceted Search, I have chosen not to try abstracting it from nodes to simplify matters a little bit. Time may have come to reconsider this choice. ;)

I'm thinking about going down this route for google_appliance integration.

Google doesn't have a node concept but it indexes meta tags and allows searches to be filtered by them. This would, for example, work very well with the existing taxonomy_facets that in turn may be generated by Drupal or another search/content provider.

I'll play around with this a bit and see if I can come up with something.

Before I go ahead with the google_appliance integration, I like to share how I managed to abstract the search engine implementation away from faceted_search "core". See attached patch I rolled against D6 dev. This patch doesn't add any new functionality yet, it's a prove of concept for the Drupal search can be decoupled from faceted search.

I introduced a new hook_faceted_search_engine that can be implemented by third party search engines. These engines are made available in the Faceted search settings on a per environment basis.

It's still early days. Currently you can't mix and match faceted search functionality that relies on the Drupal search with one (or more) third party search engines. The taxonomy facets always get served up from the Drupal search which I'd probably leave in place as I want Drupal and no third party engine to maintain my vocabs.

To hook into a third party search engine implementation, includes/search.inc needs to be extended. includes/search.inc is what remained of the old faceted_search.inc after I moved implementation-specific code into the new includes/faceted_search.inc. includes/faceted_search.inc is the search engine implementation for the standard Drupal search. I also consolidated all the "facet" module's (author_facet, content_type_facet, date_authored_facet, taxonomy_facet) including field_keyword_filter's search implementations into includes/search.inc (and includes/faceted_search.inc).

Wow, decoupling the engine would be a tremendous improvement! You might cause me to reconsider my decision to not bother integrating the Faceted Search module with Apache Solr... :-)

I have not tried your patch yet, but should check it soon.

It might be a good idea to consolidate all those small facet modules. Better yet would be to have each facet class in its own include file, which would only be included by the module when needed. That is probably what I should have done instead of separate modules.

I'm getting there :-)

I re-rolled another patch against D6 beta2, among other things the above patch ignored the faceted_search_ui styles completely so I had to change it. I also provide a base class/search engine class pair for every facet now.

I'm not sure as to what is the best way to take this forward. I understand most Faceted Search users are probably happy with the search not being decoupled from Drupal so I guess committing this patch would confuse quite a few people without providing them much benefit. Even though I'm quite convinced this patch wouldn't break any of the existing FS functionality.

Like I already said, I'm interested in using Faceted Search functionality with Google Search Appliance so what I've done for the time being is this. I created a new module called Faceted Search for Google Search Appliance (http://drupal.org/project/gsa_faceted_search) that allows GSA to use Faceted Search and requires this patch. It's very much based on Faceted Search, all it does really is extending FS base classes. So I still think this patch belongs here though I thought about providing a FS D6 beta2 branch along with gsa_faceted_search which we still might end up doing if this patch doesn't get committed and FS moves on from D6 beta2.

just tried this patch:

Fatal error: require_once() [function.require]: Failed opening required './sites/all/modules/faceted_search/includes/search_ui.inc' (include_path='.:/usr/local/lib/php') in faceted_search_views.module on line 9

checking the patch, it changes some require_once calls to use search_ui.inc but never creates an includes/search_ui.inc.

any ideas? we want to use faceted search with our shiny new google appliance.

Thanks for testing this patch. Yes search_ui.inc doesn't seem to get created by the patch above. I attached the file, it needs to be moved into faceted_search/includes/search_ui.inc.

great, this got us past this issue, thanks! we'll try implementing it again and may come back to you with issues. thanks so much for your help!

I'm really looking forward to test the GSA integration, I've mannualy applied the patch but I keep receiving an error:

Fatal error: Cannot redeclare class faceted_search_faceted_search_ui_extract_style in /home/conversi/public_html/cf/includes/faceted_search_ui.inc on line 54

Attached are the patched files. Anyone any ideas?