Currently, clicking on empty facets simply starts a search and injects keys in the search form. It would be great to be able to execute a faceted search without having to pass search keys. The current solution will fail in instances where word stemmers are installed and the keyword is stemmed.

CommentFileSizeAuthor
#2 luceneapi-628180.patch8.33 KBchaps2

Comments

cpliakas’s picture

cpliakas commented
Assigned: cpliakas » Unassigned
Status: Active » Postponed
Issue tags: +7.x-3.0-dev

Will resolve in 3.0.

chaps2’s picture

chaps2 commented
Status: Postponed » Needs review
StatusFileSize
new luceneapi-628180.patch8.33 KB

Hi,

Thanks for a brilliant module!

Here's a patch that removes the facet key from the search form which is what I believe is being asked for in this issue. However i haven't tested with word stemmers as my requirement was just for a clean search interface when initiated with a facet selection.

Empty search facets i.e. those provided by implementations of hook_luceneapi_facet_empty use a special path to indicate the keyword less search (e.g. search/luceneapi_node/text:empty) with facet values encoded in query parameters.

I've tested with all standard node facet types and realms including sorting and original search and it all seems to work. Any other modules e.g. luceneapi cck would need patching in a similar way to remove their facet key from an empty search.

Andy

cpliakas’s picture

cpliakas commented
Status: Needs review » Needs work

Hi chaps2.

Thanks for the patch! I love contributions, and thanks for taking the time to submit the patch. I tried it out, and it works as expected, but I do have a couple of observations.

Ideally Search Lucene API should be able to handle empty strings and search only on the facets. The big problem is that since Search Lucene API depends on the core Search API, the core search form doesn't validate empty strings (see search_form_submit() and search_view()). I am not sure if I want to go down the route of extending Lucene query syntax and adding flags such as "text:none", because there is a small chance of someone wanting to create a "text" field and search for the word "none". Obviously this is an edge case, but something to take into account. As we move towards Search Lucene API 3.0, it will integrate with various Lucene backends so I want to stick to the Lucene spec as closely as possible.

A couple of issues that relate to this are #812106: Implement search methods that allow for true filters and #664364: Break dependency on the core Search module. Furthermore, Search Lucene API is dropping it's integrated Facet API in the 3.0 API and will use the Facet API. project going forward. Just a couple of things to keep in mind. This is a very complicated issue with a lot of different factors to consider as we move forward with this issue.

Thanks again for the good work,
Chris

chaps2’s picture

chaps2 commented

Hi Chris,

I agree with you that the "text:empty" approach is far from ideal but it provides functionality that I really need! To be honest I'm not sure I intended it as a patch to be committed - more of a "if you really need to do this - here's a way" type patch.

I note your comments regarding sticking with the core Search API but that means we're stuck with this problem for a while to come...

Andy

cpliakas’s picture

cpliakas commented

Hey Andy.

I completely understand, and your solution definitely works for anyone who wants to apply the patch :-). Again, great contribution, and I hope to see more patches from you in the future.

~Chris

real_ate’s picture

real_ate commented

@chaps2 thanks for the patch, this seems to be very close to what I need and I will be making good use of it.

Maybe it might be possible to get this committed to the 2.x branch if you can make the value of LUCENEAPI_EMPTY_SEARCH_TEXT configurable. I know it is still a less than ideal solution and this will all be changing with the move to the 3.x branch but it would allow for users of this version to quickly and easily enable facet only searches. You could also make it so that the EMPTY_SEARCH itself was configurable so that it wouldn't alter the search in any way unless the module was configured to do so.

Just my 2c. I will play around with this approach and let you know how it works out.

cpliakas’s picture

cpliakas commented
Status: Needs work » Closed (won't fix)

Marking this as "won't fix", because this is a pretty big change. I have a strict policy of not adding features to stable versions because they tend to add new bugs to the module. Other fixes to the 3.x API will facilitate fixing this in a more stable manner, so I am going to spend my time working on a fix for that. It is looking more and more like the 3.x API can be backported to 6.x, so hopefully that will provide a viable alternative for current 6.x users.

Thanks,
Chris

real_ate’s picture

real_ate commented

That is a fair point. I would like to help this development/back-porting but, as I mentioned before, I am not the most experienced developer. Do you maintain a list of "junior jobs" or "bite-sized" tasks?

cpliakas’s picture

cpliakas commented

I don't, but that is a great suggestion! I have a presentation on Search Lucene API 3.x this Friday so I have to finish that up, but one development winds down that will be a good thing to start up.

Thanks for the suggestion,
Chris

real_ate’s picture

real_ate commented

Not trying to push you on it (and this is defiantly not the right place to have this discussion) but have you given the junior jobs idea a think about?

cpliakas’s picture

cpliakas commented

Hi real_ate.

I have, and I sent you an email regarding some of the "low hanging fruit". I am traveling for 4 weeks straight, so unfortunately time keeps on slipping away.

Thanks,
Chris