Closed (fixed)
Project:
Apache Solr Search
Version:
7.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
21 May 2009 at 22:22 UTC
Updated:
26 May 2011 at 22:45 UTC
Jump to comment: Most recent file
Comments
Comment #1
david lesieur commentedBasically, this is just moving code around and renaming some functions. No changes made to the logic.
One function was moved to apachesolr.module instead of the new apachesolr_facets.module because apachesolr_search.module also needed it.
With this patch, I was able to disable apachesolr_search.module and get facet blocks with an apachesolr_views view.
Comment #2
david lesieur commentedThis would also be a first step to some refactorings that I am planning and that should lead to some cool stuff (I'm still working on my "multiple search environments" thing. :-)).
Comment #3
pwolanin commentedI don't think this really contributes to remving the search module dependency.
Also, I'm not sure it makes sense to require another module to be enabled to jsut get this basic functionality - if there is a real need to re-use the code, then maybe it should be a re-usable .inc file?
Comment #4
david lesieur commentedMy main idea is to move re-usable code out from the apachesolr_search module to allow other modules to use it. If that code is placed in a .inc file, then other modules that might need that code won't be able to leverage Drupal's dependencies system. Ultimately, following this idea means that apachesolr_search would become quite small, only containing code that really depends on search.module.
Although the above patch relates only to facet-related code, perhaps "apachesolr_facets" is not the right name for a module whose general goal would actually be to re-use some integration code that might be too specific for apachesolr.module, but at the same time is too generic to be in a module that depends on core search.
Comment #5
jpmckinney commentedMore of a 6.x-2.x refactoring. Maybe even 7.x.
Comment #6
EvanDonovan commented@David: Do you still think that this would be helpful change to make? I think creating some custom facet blocks might be helpful for me, since I want to use Solr in a Faceted Search-like way, starting with a facet block, rather than a query.
Comment #7
david lesieur commentedI still think that this would be a step in the right direction, that is towards more modularity and a better structured API, but it looks like I have not been able to convince the module's maintainers.
Comment #8
jpmckinney commentedI think we should do it. I just don't have the time, and this patch needs work.
Comment #9
jpmckinney commentedIn 7.x this is maybe solved by facet_api, but keeping the issue alive for someone else to review.
Comment #10
pwolanin commentedYes, the goal is to do it via facet_api,
Comment #11
pwolanin commentedInitial facetapi integration is working.
Comment #13
geerlingguy commentedSo... is this documented somewhere? I noticed the blocks are missing, but had to dig down into this issue to find that the blocks were moved to Facet API. It seems that I can get these facet blocks back by installing Facet API on my D7 site, correct?
[Edit: The facet blocks can be re-enabled using Facet API (fyi for others coming to this issue)...]