It is possible to keep drilling down to finer and finer granularity on date facets even when there is only 1 item left to display.
If there is only 1 item for the month of may 2012 it makes no sense that I can keep drilling down to day, hour, minute and second of the result.
Perhaps the module should stop adding more depth when the result count is at 1?
| Comment | File | Size | Author |
|---|---|---|---|
| #11 | search_api-date_granularity-1702604-11.patch | 3.8 KB | JvE |
| #10 | search_api-date_granularity-1702604-10.patch | 3.77 KB | JvE |
| #6 | search_api-date_granularity-1702604-6.patch | 4.71 KB | slucero |
| #4 | search_api-date_granularity-1702604-4.patch | 4.07 KB | slucero |
| #3 | search_api-date_granularity-1702604-3.patch | 3.73 KB | JvE |
Comments
Comment #1
JvE commentedAttached patch works nicely on my site.
Comment #2
JvE commentedHm, never mind. With two or more items with the same date you still get the maximum drill-down without getting better results.
New patch introduces a new setting in the display options of the facet to adjust the finest "gap" the builder should go down to.
Comment #3
JvE commentedDoh, uploaded wrong file :(
Here's the correct one (I hope).
Comment #4
sluceroThe previous patch worked well for me except for the case when there is only one search result. I've rerolled it with the adjustment to take care of that.
Comment #5
JvE commentedComment #6
sluceroFound an additional check that needed to take place where the gap calculated and returned from facetapi needed to be checked and changed to the maximum granularity if it's more specific.
Rerolled the patch to include this check.
Comment #7
drunken monkeyThanks for the great suggestion and your work!
In principle, I would agree with both additions, removing useless facet filters (although you should keep in mind to check whether the filter is AND or OR) and adding an option to restrict the depth. However, in its current form I've got several issues with your patch:
First off, it simply doesn't work for me. It seems that
SearchApiFacetapiDate::build()is called before the adapter'sbuildRealm()method. Therefore, the query type cannot access the realm stored in the adapter, and therefore won't find the setting.Also, both of the additions to the adapter class seem very hack-ish to me. Please ask Chris Pliakas in the Facet API issue queue on how to best add such settings.
And even if the
$realmproperty stays, you should at least properly define and document it in the class, not just use it. Better still, define it asprotectedand also add a getter.But, as said, only if Chris agrees this would be the best/only way to do this.
Comment #8
JvE commentedI guess the SearchApiFacetapiDate settings form items can be moved from the query type to the adapter with a check on $this->queryTypes[$facet['name']]. Then the adapter is no longer decoupled from the query types though. Any future query-types with settings shall entail changes to the adapter.
It may be possible to get the granularity setting in SearchApiFacetapiDate->build() with $facet->getSettings()->settings. Then the realm is no longer needed. It depends on the form you can build in SearchApiFacetapiAdapter->settingsForm().
Haven't encountered a case where build() was called before buildRealm() but I imaginge it could easily happen.
Since the patch from #3 is working fine for my customer's site I'm afraid I'm not going to be able to get any time to work on this.
Comment #9
gaëlg#6 works for me but
FACETAPI_DATE_YEAR => t('years'),is missing in the options array.Comment #10
JvE commentedBy adding the "current search" module and block I also encountered the case where build() is called before buildrealm(), thus making it impossible to determine the realm in the query-type.
Attached patch has the settings "global" rather than per-realm which makes things a lot simpler.
I also adressed the "hackish" way the settings form was modified and let the adapter add the setting to the form rather than the query-type..
Comment #11
JvE commentedfixed Notice for facets that have no query type.
Comment #12
bago commented#11 works fine for me!
Comment #13
bago commentedComment #14
drunken monkeyWorks fine, thanks a lot for re-working the patch! I think it's acceptable here to just put the settings form inside the adapter. It would be cleaner to have it in the query type plugin, but this way it's acceptable, too.
So, committed. Thanks again!