jrochkind/bento_search

An abstraction/normalization layer for querying and displaying results for external search engines, in Ruby on Rails.

bento_search's Issues

address confstruct dependency, and indirect hashie 3.x-only dependency

Ideally we'd stop using confstruct entirely. Which might require some backwards incompat in the configuration stuff, so a major release?

Or else, get a confrstruct release to support hashie 4.x. As it is, since latest confstrut requires hashie 3.x, bento_search in an app means you can't use hashie 4.x, which another dependency might.... we need to fix this one way or another before bento-search 2.0 release.

Get CI running on github actions

Oops, it's still set up to run on travis... but isn't actually running on travis. We have to get CI working again.

Getting CI green on current codebase is a pre-req/blocker to exploring officially supporting Rails 6 #39

Searching non-Primo Central scope fails

Hi!

We chatted very briefly at Code4Lib and I've finally made time to take a look at bento_search. We love the idea, and are hoping it'll make sense for us to use it as the basis of our search.

If I use the default :loc or pass in Primo Central explicitly like :loc=>"adaptor,primo_central_multiple_fe" it works fine, but if I pass in one of our local scopes, such as :loc=>"local,scope:(NWU)" I get <BentoSearch::Results [] FAILED>.

I sort of suspect it's a XML parse issue as Primo local annoying returns different namespaces than Primo Central. I'd be happy to verify that and even look into fixing the bug, but I'm not really sure where to start debugging the problem. Is there a debug mode to find out why the search failed, or should I just fork the repo and start from source instead of the gem to dig in at this level?

If you want to see the XML returned by Primo Local I can send some along.

Thanks!
Jeremy (at Northwestern)

rewrite JS to not depend on JQuery

JQuery is unpopular these days. The JS isn't actually super complicated, it's only a few lines.

Could maybe feasibly be rewritten as pure js with no dependencies? Relevant to #39

I personally (@jrochkind) am probably not up for this, since I don't currently use bento_search. But I'd be happy to advise/consult with someone else interested in working on it, I have some ideas.

Facets Timeline?

Hi Jonathan,
BentoSearch looks great. We're excited to start playing around with it. Any timeline on display facet support? Theoretically we could help with some of that development, esp. w.r.t. summon.

Thanks,
Scot

ConcurrentSearcher, if you call results without having searched, get a reasonable error

Rails 6 support

We could probably get tests passing on Rails 6 with very few changes, but tests passing can hide some actual difficulties.

Rails 6 by default does not use sprockets asset pipeline for Javascript (it does use it for CSS), but we provide JS in such a way for asset pipeline. The JS for ajax loading of search results is a pretty key part of this gem.

We can get tests passing anyway by modifying our in-repo dummy app to have sprockets compile JS, and have the layout use a sprockets-compiled application.js. But what do we expect users to do? They're going to be lost.

We could provide instructions for how to get JS asset pipepline working in Rails 6, and say, sorry, that's the way this gem supports using it's JS, it's all we support at present.

That probably does make sense as at least an initial step, that could be released without even a major version bump. I don't think we should change gemspec to allow Rails 6 without those instructions in README.

Ultimately we "should" provide our JS as npm package instead for use with webpacker... but I am still not really happy with the developer ergonomics of this for a Rails engine, at least not with what i've figured out so far. (One idea is using yarn's ability to point to an npm package from a git repo to point it directly to bentosearch repo with a version tag?) Probably for the future.

Wait alternately though -- our JS is actually only 20 lines in one file! It's not necessarily crazy to just copy it into the local app... our JS also depends on JQuery, would be nice to have a pure javascript version.