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

Blacklight JSON API for search and show #588

Merged
merged 1 commit into from Sep 4, 2013
Merged

Blacklight JSON API for search and show #588

merged 1 commit into from Sep 4, 2013

Conversation

jcoyne
Copy link
Member

@jcoyne jcoyne commented Aug 16, 2013

No description provided.

@MrDys
Copy link
Contributor

MrDys commented Aug 16, 2013

Maybe I'm dense here (it's also 4am and I'm reading this PR on my phone), but wouldn't the more "Blacklight" way to do this utilize the document extension framework?

@jcoyne
Copy link
Member Author

jcoyne commented Aug 16, 2013

@MrDys The document extension framework would work for the show page, but not for the search page, where most of the work in this PR resides. There is only one line of code dedicated to rendering the show page:

    format.json { render json: {response: {document: @document}}}

Mostly it's about crafting the response itself to be a hash with response as the first level key and document as the second level key. The idea here is that the response format is extensible so that it can contain things beyond just the document (e.g. flash message, navigation hints, etc.) in the future.

@@ -32,16 +32,20 @@ def search_action_url
# get search results from the solr index
def index

extra_head_content << view_context.auto_discovery_link_tag(:rss, url_for(params.merge(:format => 'rss')), :title => t('blacklight.search.rss_feed') )
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aren't these links appropriate for all response types?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

extra_head_content is rendered in app/views/catalog/index.html.erb, so I don't think so.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, got it. I think I mixed this up with something as a Link: header

@cbeer
Copy link
Member

cbeer commented Aug 16, 2013

Who's the consumer of this API (and, why should they like ours more than e.g. the native Solr one)?

@erikhatcher
Copy link

Good point about who's the consumer. In our case, it's the "UI" person who's wiring in graphs and other wizbang JSONy componentry. It's nice to have the Blacklight "wrapper" around or flavor of the Solr response.

I also would like a Solr "pass through" for JSON (or even other formats) using the same Blacklight constrainting for the request and/or session, but that's a separate issue for different play ground kinds of use cases.

@jcoyne
Copy link
Member Author

jcoyne commented Aug 16, 2013

@cbeer I'm envisioning a Angular/Ember front end for a hydra application. I want Blacklight to filter access to the objects that the consumer has access to.

@@ -5,28 +5,7 @@ module Blacklight::CatalogHelperBehavior
# it translates to a Kaminari-paginatable
# object, with the keys Kaminari views expect.
def paginate_params(response)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should rebase this patch on top of master in light of #595

cbeer added a commit that referenced this pull request Sep 4, 2013
Blacklight JSON API for search and show
@cbeer cbeer merged commit 960942a into master Sep 4, 2013
@cbeer cbeer deleted the json_api branch September 4, 2013 23:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants