Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wishlist: field datatype compatibility #167

Open
ShawnWon opened this issue Feb 2, 2021 · 3 comments
Open

Wishlist: field datatype compatibility #167

ShawnWon opened this issue Feb 2, 2021 · 3 comments

Comments

@ShawnWon
Copy link

ShawnWon commented Feb 2, 2021

Dears:
I'm a rookie developer, I installed a blacklight instance, and this brilliant plugin works smoothly. Only our project may want a field with a datatype of "date range", I managed to customized the solar schema, indexed some documents, and configured the controller to have the facet of my "date range" field.
Then I met difficulty to build a slider selector as in this plugin to work on a field with the data type of "date range". Can this project only apply to those fields with the data type of Integer? Any idea how can I do it? With many thanks!

@mejackreed
Copy link
Contributor

Thanks for raising the issue @ShawnWon . We have looked into it, and unfortunately without the Solr statistics being able to be calculated on a DateRangeField like it does for an Int field, we cannot port this functionality into this plugin.

@ShawnWon
Copy link
Author

ShawnWon commented Feb 3, 2021

Thanks for raising the issue @ShawnWon . We have looked into it, and unfortunately without the Solr statistics being able to be calculated on a DateRangeField like it does for an Int field, we cannot port this functionality into this plugin.

Thanks for your prompt reply, Jack. It makes sense that a field with a "date range" is difficult to be statistically calculated. Then I came up with this idea to mute the statistic feature, hoping to have a simple range filter as in the below screenshot, which I customized the view file "_range_limit_panel.html.erb" to have it. I even did some tests to modify the "/app/helpers/range_limit_helper.rb" to passed some customized queries. But it's always the "InvalidRequest" error once I config my "date range field" as the "facet field". from the error info, I seriously doubt the error was due to "stats=true&stats.field=dc_createdate_dtr" in the request. Then I discovered the only snippet that passes a value to "stats.field" is at "lib/blacklight_range_limit/range_limit_builder.rb", then I tried to comment it out, but the error of invalid request was still there. So I guess there must be somewhere else that telling the RoR we need this field to be a stats.field. Any idea how can I mute it?
image

image

image

@jrochkind
Copy link
Member

jrochkind commented Feb 3, 2021

I think the bulk of the code in this gem is about the statistics/histogram feature.

If all you want is a 'from' and 'to' box... and I guess it showing up correctly in the search limits...

It might make sense to develop a different gem. I think it could be much much simpler than the code in this gem, probably just two or three files with 10-20 lines of code each. Especially starting from scratch without the legacy of stuff built for years-ago versions of Blacklight and trying to support multiple versions of Blacklight etc. (This gem is currently triggering deprecation warnings in latest Blacklight for instance).

So personally I'd encourage you to look into that, perhaps copying code from this gem if useful. Whether as a gem or just in your local app, simply supporting "from" and "to" boxes should be pretty simple, much simpler than what this gem needs to support. I think it would probably be just as easy -- and more maintainable over the long term -- to write some code that just did what you want, then to try to fight with this 12-plus-year-old (!) code -- that needs to support much more complicated logic -- to get it to do it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants