projectblacklight / blacklight

Blacklight provides a discovery interface for any Solr (http://lucene.apache.org/solr) index.

Blacklight

Blacklight is an open source Solr user interface discovery platform. You can use Blacklight to enable searching and browsing of your collections. Blacklight uses the Apache Solr search engine to search full text and/or metadata. Blacklight has a highly configurable Ruby on Rails front-end. Blacklight was originally developed at the University of Virginia Library and is made public under an Apache 2.0 license.

Installation

Add Blacklight to your Gemfile:

gem "blacklight"

Run the install generator which will copy over some initial templates, migrations, routes, and configuration:

rails generate blacklight:install

Documentation, Information and Support

• Project Homepage
• Developer Documentation
• Quickstart Guide
• Testing and Developing Blacklight
• Issue Tracker
• Support

Browser Compatibility

Blacklight assumes a modern browser with support for ES6. This means we explicitly do not support Internet Explorer 11.

Dependencies

• Ruby 2.7+
• Ruby on Rails 6.1+

Blacklight aims to support the currently supported versions of Ruby and the supported versions of Ruby on Rails. We aim to keep our test configuration up to date with these supported versions.

Contributing Code

Code contributions are always welcome, instructions for contributing can be found at CONTRIBUTING.md.

Configuring Apache Solr

You'll also want some information about how Blacklight expects Apache Solr to run, which you can find in Solr Configuration

Building the javascript

The javascript is built by npm from sources in app/javascript into a bundle in app/assets/javascripts/blacklight/blacklight.js. This file should not be edited by hand as any changes would be overwritten. When any of the javascript components in the gem are changed, this bundle should be rebuild with the following steps:

1. Install npm
2. run npm install to download dependencies
3. run npm run prepare to build the bundle
4. run npm publish to push the javascript package to https://npmjs.org/package/blacklight-frontend

Using the javascript

Blacklight ships with Javascript that can be compiled either by Webpacker or by Sprockets. To use Webpacker see the directions at https://github.com/projectblacklight/blacklight/wiki/Using-Webpacker-to-compile-javascript-assets

If you prefer to use Sprockets, simply run the install generator, which will run the assets generator. For details see https://github.com/projectblacklight/blacklight/wiki/Using-Sprockets-to-compile-javascript-assets

blacklight's Issues

expand RSS holdings and look at an atom feed as well.

CODEBASE-28:

fielded search enabled

CODEBASE-16: basically, want pull down to do "author" "title" "subject" sorts of searches.

This is already available in at least of the UVa implementations ...

Probably with separate dismax handlers and code to hook them in properly (unless there's a better way to implement this just with the query itself)

2009-03-17: Naomi already has stanford solrconfig.xml for this ... but that's pretty simple.

For example, see search box here:
http://virgobeta.lib.virginia.edu/

refactoring: solr.yml file to include abstract field names

CODEBASE-24: abstract out the solr fields used for required display pieces so they're not splattered through out the code.

E.g. title_t becomes show_view.html_title and show_view.display_type

exporting to EndNote

CODEBASE-5: Blacklight needs to export to EndNote at least as well as Jessie got it working for Stanford VuFind Searchworks.

(or better: Stanford's currently just text to be imported into EndNote, rather than a direct import ...)

Book Cover fetching

CODEBASE-11: Blacklight needs to get Book Covers at least as well as Jessie got it working for Stanford's VuFind Searchworks.

The covers need to be fetched from the blacklight user's box (or cached locally) so we don't request all covers from one IP.

Blacklight currently looks in a lot of places, sequentially, for the cover. This meant new fetches were very very slow.

Cover provider(s) needs to be configurable for installations, too.

Stanford has been doing this with javascript (AJAX) for their VuFind installation. Jessie is the knowledge fount.

Test issue

Testing out the API

create home page as it's own rails 'view'

CODEBASE-14: the home landing page (that which you get from the top level url and/or from "start over") should be it's own view.

Virginia is currently using "recently added items" as a home page. But it's not in the code as a distinct view, and it should be.

"more like this"

CODEBASE-39: It would probably be useful to have a "more like this" feature in blacklight, once a document is selected. Presumably it could be implemented relatively simply using the "more like this" solr request handler that is includd in solr.

it's not clear how this feature would relate to "nearby on shelf" -- the goal of both is to direct the users to additional items likely to be of interest. At Stanford, the call number browse is the one specifically asked for.

(Possibly do something with statistically improbable phrases?)

RSS feeds of search results

CODEBASE-20: RSS feeds of search results: this feature needs to be migrated into the plugin (from the uva site code).

Sort order for non-latin text

CODEBASE-46: Do search results sorted by title, author, whatever sort in the appropriate alphanumeric order for non-latin scripts and for diacritics, interfiled however they should be? There may be language by language issue --in Chinese, I believe sort order is determined by number of strokes in the first pictographic character, not by the alphabet ?

Stanford has a title_sort and an author_sort field ... that doesn't sort correctly. We have a way to map Latin diacritics to plain chars (borrowed from Bob's code), but I'm not sure that's working ... and not sure what to do about non-latin chars.

Stanford "recently" converted Symphony to Unicode and partnered with Sirsi to get iLink to display and sort results appropriately. So someone here has a solid set of test cases and internal expertise to help get BL up to snuff on these.

Lauren Scott would be the key resource in coordinating this testing and feedback from the appropriate language experts.

ATOM feeds of search results

CODEBASE-21: Future development: add Atom feeds of search results (keeping RSS)

SolrDocument refactor to accommodate more than marcxml

CODEBASE-58: The 2.0.0 implementation of this class has a few things ripe for refactoring:

1. use solr.yml / DisplayFields rather than hardcoded field names (raw metadata field, solr doc id field)
2. allow for marc21, marcxml, and other types of raw metadata.
   One idea is to have either a solr.yml value OR a field in the solr document that indicates what sort of raw data is present. Then you have a case statement in SolrDocument that parses that raw data appropriately. We have the marc gem to do that for marcxml and for marc21; other formats will need to be added in with some other gem help or some code we write.

If we specify raw metadata format with a field in the solr document, it allows for heterogeneous metadata in a single index.

This expands the utility of the to_xml method, sets up SolrDocument to be more versatile for the citation, RSS, and other export metadata formats.

It does not address what to do when a single solr document has multiple types of raw metadata. But we can tackle that if and when the situation arises.

Vernacular scripts (utf8) must display properly

CODEBASE-2: concerned about display of UTF8 due to Ruby being less UTF8 friendly.

Latest Ruby is supposed to make this easier in some way ...

We know Bob got the searching working (yay bob!) with solrmarc.

It's a deal breaker for us if we don't get the non-latin stuff displaying well. Our librarians have already tested our vufind searchworks for at least the following:

chinese
hebrew
arabic
russian
cyrillic
all sorts of diacritics

right to left issues for hebrew arabic (and whatever else)

• we have "display" fields in our index and can hammer this stuff into submission, but does ruby have any cool built in stuff to do it (or gems or something)

There is already some example data in the solrmarc svn project. It's currently in the 2.0 branch, under test/data

unicornWHoldings
hebrew
diacriticTests
non-latin <-- I didn't put that there, so I don't know what's in it.

If we need more examples, I can certainly get them. I'm only confident there's already hebrew and chinese in there, and lots of diacritics. I was trying to write tests for the diacritics, but I couldn't get them to pass and fail at the right times.

• Naomi

allow boolean syntax in queries

CODEBASE-32: Make "boolean syntax" one of the pulldown values for demo?

We need a request handler in solrconfig.xml that does the following:

user queries should have different results (and different numbers of results):

cat and dog
cat or dog
cat not dog

upcase required ok:
cat AND dog
cat OR dog
cat NOT dog

not sure if we must have "not" in addition to the hyphen that already works for dismax handler

I think this may be as simple as:

{!lucene}

or something like that.

See Erik Hatcher's posting to blacklight-dev list (week of 3/9/2009). This is underdocumented, but he does talk about how to improve the get document requests, and the !field and !raw syntax. A post to solr-user may be indicated, if not a conversation with Erik.

See
http://wiki.apache.org/solr/SolrPlugins (QParserPlugin)
http://lucene.apache.org/solr/api/org/apache/solr/search/QParserPlugin.html

tests for valid xhtml

CODEBASE-34: We probably want to ensure blacklight serves up valid xhtml

SMS records and search results

CODEBASE-8: Blacklight needs to SMS records and searches at least as well as Jessie got it working for Stanford's VuFind Searchworks.

Would like to be able to cherry pick search results (not all or nothing) - that may be a separate issue (and separate JIRA issue may be needed)

objects should respond with xml to .xml requests

CODEBASE-23: Objects should respond with xml to .xml requests. This is already true in the UVA version of BL, but this functionality needs to be ported to the engine plugin. At the very least this should work with marc records. We'll need a config file where people can specifiy what solr field stores their marc_xml.

This is dependent on the config files re-factoring that Naomi is doing. It's going to require that an institution:
a. store marc-xml in their solr indexed record
b. specifies in the config file the field name where that marc-xml is stored
c. has a view for nicely printing the MaRC so librarians can troubleshoot

simpler URLs for single documents

CODEBASE-42: http://(blacklight.baseurl)/(id)

i.e. do NOT include query/facet/other information

big discussion on blacklight-dev list. Ruby sessions seem to be the solution of choice.

Use case: when end user bookmarks a URL, they shouldn't have to change their bookmark, and it should be clean.

At the same time, we need to allow Next/Prev in the context of paging through search results

demo app graphic design improved

CODEBASE-15: Not sure about this. May want to wait until we have Jessie's work on CODEBASE-14 which is to flesh out more of a "your look and feel here" sort of default look.

Want images for header, footer ... anywhere there is a basic need for an image.

Image should not obscure anything, and should have a link to the place in the code to replace them.

bl-demo solr index fields - should be in bl-demo project?

CODEBASE-29: Bob and Naomi need to put their heads together and see if there are tweaks to demo indexing that make sense.

For example:

use marc21 instead of marcxml?
use indexed catchall field and don't index marc21

exporting to Zotero

CODEBASE-3: Blacklight needs to export to Zotero as least as well as Jessie got it working for Stanford's VuFind Searchworks.

Show number of results

CODEBASE-19: Showing the number of results for a search sequence (may include some facet selection) is desired at Stanford. I think it might make sense to put it in the plugin, and it should be easy, no?

OAI for blacklight

CODEBASE-30: Desired:

easy harvestability of full records.
by date modified

OAI way to ask for a single record (analogous to (id).xml view)

index updates via Jangle

CODEBASE-22: Actually, this might be a solrmarc thing more than a blacklight thing?? Idea is to get automatic updates from ILS when records change (bib or availability or what have you) at interval you specify.

Newbie question: JSON/JSON-LD

Does Blacklight take JSON/JSON-LD as a data source?

Design a basic advanced search UI

CODEBASE-51: An advanced search page, even a simple one, is likely to be desired by many sites. If for no other reason than librarians are used to having one.

As discussed in 3/13 conference call: Blacklight demo app needs an advanced search feature that allows for combining specific fields and boolean AND OR NOT.

exporting to RefWorks

CODEBASE-4: Blacklight needs to export to RefWorks at least as well as Jessie got it working for Stanford VuFind Searchworks.

Search History

CODEBASE-7: Blacklight needs to have search history at least as well as Jessie got it working for Stanford's VuFind Searchworks.

Note that the NLA VuFind guys did some clever stuff with Search History ... maybe we can steal some of it. Possibly others did this too - worth doing searches on the list archives.

to vendorize or not vendorize our gems

CODEBASE-12: Naomi was thinking that the installation of blacklight might be simplified if we had require statements for the required gems (with particular versions, when that matters), and ?? used capistrano ?? to cope with the plugins ...

Maybe some QA built into code to ensure all the necessary pieces are there.

maybe including system gems and so on?

No instructions for installing as a plugin

In the README there are two links, one for installing Blacklight's demo app, and one for installing it as a plugin. However, both of them link to the same page, which only contains instructions for installing the demo app. Trying to install it into an existing Rails app seems to be a complete mystery, unfortunately.

Advanced Search has an incompatible character encoding issue under ruby 1.9

CODEBASE-369: Advanced Search throws an "incompatible character encodings: UTF-8 and ASCII-8BIT" if the /advanced route recieves the parameter "utf8=✓"

Full stack trace is below.

I'm not certain how you like to set "Fix Version/s" for this sort of add-on code, so please override if set inappropriately.

-Tod

[Update 10/28: the problem seem to be that in AdvancedController, the call to Blacklight.solr.find() returns an object that contains some ASCII-8BIT strings, but the strings in the object need to be encoded as UTF-8. Blacklight::SolrHelper has a find() method which does this.]

Extracted source (around line #25):

22:

AND have these attributes:

23:
24:

25: <%= render 'advanced_search_facets' %>
26:

27:
28:

activesupport (3.1.0) lib/active_support/core_ext/string/output_safety.rb:106:in concat' activesupport (3.1.0) lib/active_support/core_ext/string/output_safety.rb:106:inconcat'
actionpack (3.1.0) lib/action_view/buffers.rb:11:in <<' blacklight_advanced_search (1.1.1) app/views/advanced/_advanced_search_form.html.erb:25:inblock in __usr_local_rvm_gems_ruby_______p____gems_blacklight_advanced_search_______app_views_advanced__advanced_search_form_html_erb__3088976311162475832_45541740'
actionpack (3.1.0) lib/action_view/helpers/capture_helper.rb:40:in block in capture' actionpack (3.1.0) lib/action_view/helpers/capture_helper.rb:187:inwith_output_buffer'
actionpack (3.1.0) lib/action_view/helpers/capture_helper.rb:40:in capture' actionpack (3.1.0) lib/action_view/helpers/form_tag_helper.rb:642:inform_tag_in_block'
actionpack (3.1.0) lib/action_view/helpers/form_tag_helper.rb:62:in form_tag' blacklight_advanced_search (1.1.1) app/views/advanced/_advanced_search_form.html.erb:1:in__usr_local_rvm_gems_ruby_______p____gems_blacklight_advanced_search_______app_views_advanced__advanced_search_form_html_erb__3088976311162475832_45541740'
actionpack (3.1.0) lib/action_view/template.rb:144:in block in render' activesupport (3.1.0) lib/active_support/notifications.rb:55:ininstrument'
actionpack (3.1.0) lib/action_view/template.rb:142:in render' actionpack (3.1.0) lib/action_view/renderer/partial_renderer.rb:256:inrender_partial'
actionpack (3.1.0) lib/action_view/renderer/partial_renderer.rb:228:in block (2 levels) in render' actionpack (3.1.0) lib/action_view/renderer/abstract_renderer.rb:33:inblock in instrument'
activesupport (3.1.0) lib/active_support/notifications.rb:53:in block in instrument' activesupport (3.1.0) lib/active_support/notifications/instrumenter.rb:21:ininstrument'
activesupport (3.1.0) lib/active_support/notifications.rb:53:in instrument' actionpack (3.1.0) lib/action_view/renderer/abstract_renderer.rb:33:ininstrument'
actionpack (3.1.0) lib/action_view/renderer/partial_renderer.rb:227:in block in render' actionpack (3.1.0) lib/action_view/renderer/abstract_renderer.rb:22:inwrap_formats'
actionpack (3.1.0) lib/action_view/renderer/partial_renderer.rb:219:in render' actionpack (3.1.0) lib/action_view/renderer/renderer.rb:41:inrender_partial'
actionpack (3.1.0) lib/action_view/helpers/rendering_helper.rb:27:in render' blacklight_advanced_search (1.1.1) app/views/advanced/index.html.erb:7:in__usr_local_rvm_gems_ruby_______p____gems_blacklight_advanced_search_______app_views_advanced_index_html_erb___289234950479201829_45859820'
actionpack (3.1.0) lib/action_view/template.rb:144:in block in render' activesupport (3.1.0) lib/active_support/notifications.rb:55:ininstrument'
actionpack (3.1.0) lib/action_view/template.rb:142:in render' actionpack (3.1.0) lib/action_view/renderer/template_renderer.rb:40:inblock (2 levels) in render_template'
actionpack (3.1.0) lib/action_view/renderer/abstract_renderer.rb:33:in block in instrument' activesupport (3.1.0) lib/active_support/notifications.rb:53:inblock in instrument'
activesupport (3.1.0) lib/active_support/notifications/instrumenter.rb:21:in instrument' activesupport (3.1.0) lib/active_support/notifications.rb:53:ininstrument'
actionpack (3.1.0) lib/action_view/renderer/abstract_renderer.rb:33:in instrument' actionpack (3.1.0) lib/action_view/renderer/template_renderer.rb:39:inblock in render_template'
actionpack (3.1.0) lib/action_view/renderer/template_renderer.rb:47:in render_with_layout' actionpack (3.1.0) lib/action_view/renderer/template_renderer.rb:38:inrender_template'
actionpack (3.1.0) lib/action_view/renderer/template_renderer.rb:12:in block in render' actionpack (3.1.0) lib/action_view/renderer/abstract_renderer.rb:22:inwrap_formats'
actionpack (3.1.0) lib/action_view/renderer/template_renderer.rb:9:in render' actionpack (3.1.0) lib/action_view/renderer/renderer.rb:36:inrender_template'
actionpack (3.1.0) lib/action_view/renderer/renderer.rb:17:in render' actionpack (3.1.0) lib/abstract_controller/rendering.rb:120:in_render_template'
actionpack (3.1.0) lib/action_controller/metal/streaming.rb:250:in _render_template' actionpack (3.1.0) lib/abstract_controller/rendering.rb:114:inrender_to_body'
actionpack (3.1.0) lib/action_controller/metal/renderers.rb:30:in render_to_body' actionpack (3.1.0) lib/action_controller/metal/compatibility.rb:43:inrender_to_body'
actionpack (3.1.0) lib/abstract_controller/rendering.rb:99:in render' actionpack (3.1.0) lib/action_controller/metal/rendering.rb:16:inrender'
actionpack (3.1.0) lib/action_controller/metal/instrumentation.rb:40:in block (2 levels) in render' activesupport (3.1.0) lib/active_support/core_ext/benchmark.rb:5:inblock in ms'
/usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/1.9.1/benchmark.rb:309:in realtime' activesupport (3.1.0) lib/active_support/core_ext/benchmark.rb:5:inms'
actionpack (3.1.0) lib/action_controller/metal/instrumentation.rb:40:in block in render' actionpack (3.1.0) lib/action_controller/metal/instrumentation.rb:78:incleanup_view_runtime'
activerecord (3.1.0) lib/active_record/railties/controller_runtime.rb:24:in cleanup_view_runtime' actionpack (3.1.0) lib/action_controller/metal/instrumentation.rb:39:inrender'
actionpack (3.1.0) lib/action_controller/metal/implicit_render.rb:10:in default_render' actionpack (3.1.0) lib/action_controller/metal/implicit_render.rb:5:insend_action'
actionpack (3.1.0) lib/abstract_controller/base.rb:167:in process_action' actionpack (3.1.0) lib/action_controller/metal/rendering.rb:10:inprocess_action'
actionpack (3.1.0) lib/abstract_controller/callbacks.rb:18:in block in process_action' activesupport (3.1.0) lib/active_support/callbacks.rb:461:in_run__894301885984338237__process_action__2093790841794511241__callbacks'
activesupport (3.1.0) lib/active_support/callbacks.rb:386:in _run_process_action_callbacks' activesupport (3.1.0) lib/active_support/callbacks.rb:81:inrun_callbacks'
actionpack (3.1.0) lib/abstract_controller/callbacks.rb:17:in process_action' actionpack (3.1.0) lib/action_controller/metal/rescue.rb:17:inprocess_action'
actionpack (3.1.0) lib/action_controller/metal/instrumentation.rb:30:in block in process_action' activesupport (3.1.0) lib/active_support/notifications.rb:53:inblock in instrument'
activesupport (3.1.0) lib/active_support/notifications/instrumenter.rb:21:in instrument' activesupport (3.1.0) lib/active_support/notifications.rb:53:ininstrument'
actionpack (3.1.0) lib/action_controller/metal/instrumentation.rb:29:in process_action' actionpack (3.1.0) lib/action_controller/metal/params_wrapper.rb:201:inprocess_action'
activerecord (3.1.0) lib/active_record/railties/controller_runtime.rb:18:in process_action' actionpack (3.1.0) lib/abstract_controller/base.rb:121:inprocess'
actionpack (3.1.0) lib/abstract_controller/rendering.rb:45:in process' actionpack (3.1.0) lib/action_controller/metal.rb:193:indispatch'
actionpack (3.1.0) lib/action_controller/metal/rack_delegation.rb:14:in dispatch' actionpack (3.1.0) lib/action_controller/metal.rb:236:inblock in action'
actionpack (3.1.0) lib/action_dispatch/routing/route_set.rb:65:in call' actionpack (3.1.0) lib/action_dispatch/routing/route_set.rb:65:indispatch'
actionpack (3.1.0) lib/action_dispatch/routing/route_set.rb:29:in call' rack-mount (0.8.3) lib/rack/mount/route_set.rb:152:inblock in call'
rack-mount (0.8.3) lib/rack/mount/code_generation.rb:96:in block in recognize' rack-mount (0.8.3) lib/rack/mount/code_generation.rb:75:inoptimized_each'
rack-mount (0.8.3) lib/rack/mount/code_generation.rb:95:in recognize' rack-mount (0.8.3) lib/rack/mount/route_set.rb:141:incall'
actionpack (3.1.0) lib/action_dispatch/routing/route_set.rb:531:in call' warden (1.0.4) lib/warden/manager.rb:35:inblock in call'
warden (1.0.4) lib/warden/manager.rb:34:in catch' warden (1.0.4) lib/warden/manager.rb:34:incall'
actionpack (3.1.0) lib/action_dispatch/middleware/best_standards_support.rb:17:in call' rack (1.3.5) lib/rack/etag.rb:23:incall'
rack (1.3.5) lib/rack/conditionalget.rb:25:in call' actionpack (3.1.0) lib/action_dispatch/middleware/head.rb:14:incall'
actionpack (3.1.0) lib/action_dispatch/middleware/params_parser.rb:21:in call' actionpack (3.1.0) lib/action_dispatch/middleware/flash.rb:243:incall'
rack (1.3.5) lib/rack/session/abstract/id.rb:195:in context' rack (1.3.5) lib/rack/session/abstract/id.rb:190:incall'
actionpack (3.1.0) lib/action_dispatch/middleware/cookies.rb:326:in call' activerecord (3.1.0) lib/active_record/query_cache.rb:62:incall'
activerecord (3.1.0) lib/active_record/connection_adapters/abstract/connection_pool.rb:477:in call' actionpack (3.1.0) lib/action_dispatch/middleware/callbacks.rb:29:inblock in call'
activesupport (3.1.0) lib/active_support/callbacks.rb:392:in _run_call_callbacks' activesupport (3.1.0) lib/active_support/callbacks.rb:81:inrun_callbacks'
actionpack (3.1.0) lib/action_dispatch/middleware/callbacks.rb:28:in call' actionpack (3.1.0) lib/action_dispatch/middleware/reloader.rb:68:incall'
rack (1.3.5) lib/rack/sendfile.rb:101:in call' actionpack (3.1.0) lib/action_dispatch/middleware/remote_ip.rb:48:incall'
actionpack (3.1.0) lib/action_dispatch/middleware/show_exceptions.rb:47:in call' railties (3.1.0) lib/rails/rack/logger.rb:13:incall'
rack (1.3.5) lib/rack/methodoverride.rb:24:in call' rack (1.3.5) lib/rack/runtime.rb:17:incall'
activesupport (3.1.0) lib/active_support/cache/strategy/local_cache.rb:72:in call' rack (1.3.5) lib/rack/lock.rb:15:incall'
actionpack (3.1.0) lib/action_dispatch/middleware/static.rb:53:in call' railties (3.1.0) lib/rails/engine.rb:455:incall'
railties (3.1.0) lib/rails/rack/content_length.rb:16:in call' rack (1.3.5) lib/rack/handler/webrick.rb:59:inservice'
/usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/1.9.1/webrick/httpserver.rb:111:in service' /usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/1.9.1/webrick/httpserver.rb:70:inrun'
/usr/local/rvm/rubies/ruby-1.9.2-p180/lib/ruby/1.9.1/webrick/server.rb:183:in `block in start_thread'

get a CruiseControl.rb instance up and running on blacklightopac.org

CODEBASE-26: It should run automated tests for the BL plugin and the UVA instance

Accessibility

CODEBASE-6: Blacklight needs to be at least as accessible as Stanford's VuFind

Update to SolrMarc 2.3.1

CODEBASE-368:

show availability value in search results - sirsi only? too institution specific?

CODEBASE-37: Stanford's vufind implementation gets availability information for all the search results in one shot, so this can be displayed to the user in the search results. It would be good to port this over to blacklight.

This probably relates to the Jangle efforts, which could put this information in the index without it being too stale (and the live lookup could either be nixed, or could happen and take precedence in the UI, once values are returned.)

Individual institutions will have to struggle with this issue. Different ILS systems will have different drivers.

Naomi will get this working for Stanford/Sirsi, and then we'll refactor as necessary

create rails level rake (and cruise control?) tasks for acceptance and regression and unit tests

CODEBASE-27: Reguarly run tests should take 10 minutes or less so there is immediate feedback.

We probably need some of these tests for the plugin and some of them for the demo.
We probably need some of these tests to run against a real solr index.

Use rcov to determine what is missing; either write these or open JIRA tickets for them.

Utilize Cucumber - part of RSpec suite. Cucumber is better than Selenium or whatever for browser.
"Regression": want to test if you have broken anything in the browser.

We need examples and documentation for how to run the different tests.

See also: http://wiki.blacklightopac.org/doku.php?id=testing
Perhaps remove this wiki page, or use it as a place to document how to run tests.

refactoring: solr queries in separate class, so which parameters used for solr aren't buried in controller class

CODEBASE-25: currently catalog_controller has the solr query params.

For testing purposes, it will be much easier if there is a solr request class with methods like:

get_single_document

get_search_results

get_facets

OpenSearch support

CODEBASE-9: VuFind has OpenSearch support; does Blacklight? If not, it needs it.

APA/MLA citations

CODEBASE-1: Implemented at least as well as Jessie got it working in Stanford's vufind instance

necessity of changing plugin itself and plugin update issues

CODEBASE-33: In order to add some info to solr.yml, I had to make changes in the blacklight plugin:

I didn't want to add my vars to blacklight.rb, I wanted to make a separate class to load the stuff. (I called it display_fields.rb)

I couldn't do this at the level of my rails app - it didn't work.

I had to change the plugin: add lib/display_fields.rb and change init.rb

When Vernon was trying to make some local mods that involved init.rb, he ran into the same problem. See blacklight-dev list emails from Vernon and me week of 3/9/2009.

Ideally, sites would be able to make these sorts of changes and not have to be in the plugin itself. Why? A1: we at Stanford, for whatever reason, have been unable to run the following:

script/plugin update blacklight
script/plugin update (full svn url to blacklight)

the only thing that has worked is

script/plugin update --force (full svn url to blacklight)

the later would step on local mods to the plugin, no?

caching external metadata at index time

CODEBASE-17: Bob,

Big discussion with Bess on IM about this; basically, good idea to cache what we can at index time.

Issues with throttling of requests so not blocked (configurable)

May want an example that not only stores way to lookup in db or file based cache, but indicates source of the content.

maybe some documentation about which services are currently legal vs. illegal to cache

generic solrmarc project might want this; if so, needs to be done carefully b/c it needs to sync with unknown consumer of index. (unknown to solrmarc project)

careful, clear documentation on how to configure

for later: refreshing of cache

Having trouble passing value from radio button when submit

Hi,

I am using your default blacklight application trying to create radio button instead of a drop down. I am not able to to pass radio button value after I submit the form. Non of the radio button would selected. I was trying to create params as suggested in many forum but have no luck. I put the params in catalog_controller.rb. Please help.

Here is my code:

_search_form.html.erb

<%= radio_button_tag :search_field, 'title' %>
<%= label_tag :title, "Title" %>
<%= radio_button_tag :search_field,'author' %>
<%= label_tag :author, "Author" %>
<%= radio_button_tag :search_field, 'subject' %>
<%= label_tag :subject, "Subject" %>

catalog_controller.rb

class CatalogController < ApplicationController

include Blacklight::Catalog

def _search_form
@SEARCHFIELD = params[:search_field]
end

end

testing testing testing - rSpec-rails code in blacklight plugin?

CODEBASE-13: I've been working with rSpec at the level of our local installation, but it probably makes sense for there to be automatable testing at the blacklight plugin level.

rSpec rails is actually a whole way to develop code in rails in a test-driven fashion, and the sooner it is adopted, the better. It's designed to specify behaviors before you code them. What could be more fitting than specifying how we want blacklight to behave before we code it?

http://rspec.info/documentation/
http://rspec.rubyforge.org/rspec-rails/1.1.12/

freeze and vendor as many gems as possible

CODEBASE-123: The question has been raised as to whether we want to use frozen gems.

rake gems:install does not work

CODEBASE-54: paz:rails eos8d$ rake spec:plugins
(in /usr/local/projects/demo/rails)
Missing these required gems:
mislav-will_paginate = 2.3.8
mwmitchell-rsolr = 0.8.1
mwmitchell-rsolr-ext = 0.5.9

I'm not sure who is the right person to troubleshoot this, so Matt if this is something Jamie should look at instead of you, just assign it to him, okay?

I just upgraded my BL demo app to the latest rev. Then I try to run my rspec tests:

paz:rails eos8d$ rake spec:plugins
(in /usr/local/projects/demo/rails)
Missing these required gems:
mislav-will_paginate = 2.3.8
mwmitchell-rsolr = 0.8.1
mwmitchell-rsolr-ext = 0.5.9

You're running:
ruby 1.8.7.72 at /opt/local/bin/ruby
rubygems 1.3.1 at /Users/eos8d/.gem/ruby/1.8, /opt/local/lib/ruby/gems/1.8

Run rake gems:install to install the missing gems.

Yay! This is what I expect. But then:

paz:rails eos8d$ rake gems:install
(in /usr/local/projects/demo/rails)
rake aborted!
undefined method `[]' for :blacklight:Symbol

(See full trace by running task with --trace)

I tried running it with --trace but it didn't tell me anything I could understand. Is this a problem with the plugin? or with the rake task that installs gems?
Thanks!

Pull in Hydra's jettywrapper to manage jetty

CODEBASE-367:

Email of Records and Search Results

CODEBASE-10: Blacklight needs to email records and searches at least as well as Jessie got it working for Stanford's VuFind Searchworks.

Would like to be able to cherry pick search results (not all or nothing)

that may be a separate issue (and separate JIRA issue may be indicated)

Application files need to be moved to a module

CODEBASE-35: The ApplicationController and the ApplicationHelper in the blacklight plugin need to be moved into modules and be included.

Application files do not mix in with plugin application files, so they cannot be extended or overridden by the top level app.

I am adding an instruction into the plugins README.rdoc explaining to delete the blank generated ApplicationController and ApplicationHelper in the top level app.

"did you mean"

CODEBASE-36: Stanford would like a "did you mean" feature in the plugin. I see it is in the UVa blacklightdev implementation, so presumably it can be moved up to the plugin very easily.

I noticed the solrconfig.xml and the schema.xml files seem to have a spell check field and handlers ... but I'm not sure how to use them. :-P

sortable search results - is this bl-demo project?

CODEBASE-18: We'd like to be able to sort search results by:
relevance
title
author
pub date

and maybe more. This isn't in demo app.

Stanford has this for VuFind. I think it's a matter of passing a sort=fieldname parameter to solr, and having the pulldown box in the view.

(param would be added to solr_helper methods, field names would be added to solr.yml)