Facets Timeline?

[jrochkind]

Facets Timeline?

[jrochkind]

Afraid I'm not in a hurry to do display facet support at this point, we've decided it's not a priority for our initial release.

I've got a couple other things to work on first, including re-architecting the way presentational logic is done (and is overrideable), and making it possible to save a uniqueID for a record and later it look it up by uniqueID.

Also, I'm currently working with EBSCOHost adapter, we decided not to license Summon for now. (But I do still have evaluation access to Summon at the moment, making it easier for me to support any idiosyncracies there. But even if I didn't, that's no barrier to me providing support for Summon, as someone can always submit a VCR cassette with a test case demonstrating error or desired feature!).

So... I do have some ideas about how facets should work and look from the API end. I could share them with you.

However, I'll also warn you that I'm not going to take pull requests unless I actually really like the architecture -- so far, bento_search is like the cleanest code I've ever written, and I'm going to experiment with trying to err on the side of code elegance with this one, see how it goes (in constrast to all my other projects that have become royal messes, heh).

But the beauty of git is you can you do your work in your own fork if you like, and whether or not I accept your pull request, you can deploy based off of your fork easily -- and if facets get implemented in core, you can later switch over to core.

[jrochkind]

(I would add, if you start messing with bento_search, the under-documented "item_decorators" thing is what's probably going to change soon, so beware. Hopefully for the better, making it a lot easier to add custom local display logic in an engine-specific way).

[jrochkind]

It's possible i'll have some time to work on this sooner, would you prefer I spend it on this or umlaut ui? :)

But overall, I don't think you'll have too much trouble adding facet support to the Summon adapter yourself, if needed. It probably makes sense to start out adding it in a custom exploratory way just for Summon, if that's what you need, and then we can abstract out from there to a general bento_search api.

When I think through a general bento_search api, there are some parts that are clear to me what it should look like (simply returning the fact results from the search; that's clear to me, and if you get started working on it and I havne't done it yet, I can outline it).

There are other parts that are very unclear to me -- the abstract engine-agnostic api for applying limits, whether based on facets or not. It can get really complicated fast if I try to make it infinitely flexible. Maybe makes sense to pave a cowpath by writing what you actually need for sersol, and then abstracting out. The actual mechanics of the code won't be that complicated, it's just making a good easy to use engine-agnostic api that is.

Either way, if you're interested in bento_search, I'd suggest you start out building out your bento_search UI and supporting functionality without facets, leaving blank spots in the UI for facets. That'll give you a sense of if you actually like bento_search (I hope so!), and give you the background to then add the facet functionality if you want to continue, which I again predict will not be that hard to do, at least to get a prototype that works just for summon just for your actual use cases, to start with.

[scotdalton]

Sorry for the delayed response. This is definitely not a priority for us. I was just wondering about where facets stand in your bento_search roadmap.
Thanks,
Scot