blacklight 3.1.1 → 3.1.2

data/VERSION

@@ -1 +1 @@
-3.1.1
+3.1.2

data/blacklight.gemspec

@@ -24,8 +24,8 @@ Gem::Specification.new do |s|
   s.add_dependency "nokogiri", "~>1.5"   # XML Parser
   s.add_dependency "unicode" # provides C-form normalization of unicode characters, as required by refworks.
   s.add_dependency "marc", "~> 0.4.3"  # Marc record parser
-  s.add_dependency "rsolr",  '~> 1.0' # Library for interacting with rSolr.
-  s.add_dependency "rsolr-ext", '~> 1.0' # extension to the above for some rails-ish behaviors - currently embedded in our solr document ojbect.
+  s.add_dependency "rsolr",  '1.0.2' # Library for interacting with rSolr.
+  s.add_dependency "rsolr-ext", '1.0.3' # extension to the above for some rails-ish behaviors - currently embedded in our solr document ojbect.
   s.add_dependency "kaminari" # the pagination (page 1,2,3, etc..) of our search results
 
 end

data/doc/Atom-Responses.md

@@ -0,0 +1,90 @@
+Blacklight will provide atom responses for all catalog/index results. Just add ".atom" on to the end of your path component, `/catalog.atom`, or `/catalog/index.atom`. 
+```xml
+<?xml version="1.0" encoding="UTF-8"?>
+<feed xmlns:opensearch="http://a9.com/-/spec/opensearch/1.1/" xmlns="http://www.w3.org/2005/Atom">
+  <title>Blacklight Search Results</title>
+  <author>
+    <name>Blacklight</name>
+  </author>
+  <link href="http://demo.projectblacklight.org/?commit=search&amp;amp;format=atom&amp;amp;q=urdu&amp;amp;search_field=all_fields" rel="self"/>
+  <link href="http://demo.projectblacklight.org/?commit=search&amp;amp;format=html&amp;amp;q=urdu&amp;amp;search_field=all_fields" rel="alternate" type="text/html"/>
+  <id>http://demo.projectblacklight.org/?commit=search&amp;amp;format=html&amp;amp;q=urdu&amp;amp;search_field=all_fields&amp;amp;type=text%2Fhtml</id>
+  <link href="http://demo.projectblacklight.org/?commit=search&amp;amp;format=atom&amp;amp;page=2&amp;amp;q=urdu&amp;amp;search_field=all_fields" rel="next"/>
+  <link href="http://demo.projectblacklight.org/?commit=search&amp;amp;format=atom&amp;amp;page=1&amp;amp;q=urdu&amp;amp;search_field=all_fields" rel="first"/>
+  <link href="http://demo.projectblacklight.org/?commit=search&amp;amp;format=atom&amp;amp;page=15&amp;amp;q=urdu&amp;amp;search_field=all_fields" rel="last"/>
+  <link href="http://demo.projectblacklight.org/catalog/opensearch.xml" rel="search" type="application/opensearchdescription+xml"/>
+  <opensearch:totalResults>147</opensearch:totalResults>
+  <opensearch:startIndex>0</opensearch:startIndex>
+  <opensearch:itemsPerPage>10</opensearch:itemsPerPage>
+  <opensearch:Query searchTerms="urdu" startPage="1" role="request"/>
+  <updated>2011-05-11T17:46:58Z</updated>
+  <entry>
+    <title>Urdu&#772; d&#803;ra&#772;ma&#772;</title>
+    <updated>2011-05-11T17:46:58Z</updated>
+    <link href="http://demo.projectblacklight.org/catalog/2008306442" rel="alternate" type="text/html"/>
+<link href="http://demo.projectblacklight.org/catalog/2008306442.dc_xml" rel="alternate" title="dc_xml" type="text/xml" />
+<link href="http://demo.projectblacklight.org/catalog/2008306442.xml" rel="alternate" title="xml" type="application/xml" />
+    <id>http://demo.projectblacklight.org/catalog/2008306442</id>
+    <author>
+      <name>Farg&#818;h&#818;a&#772;nah, 1979-</name>
+    </author>
+    <summary type="html">
+&lt;dl class="defList"&gt;
+  
+      
+        &lt;dt class="blacklight-title_display"&gt;Title:&lt;/dt&gt;
+        &lt;dd class="blacklight-title_display"&gt;Urdu&#772; d&#803;ra&#772;ma&#772;&lt;/dd&gt;
+                
+        &lt;dt class="blacklight-author_display"&gt;Author:&lt;/dt&gt;
+        &lt;dd class="blacklight-author_display"&gt;Farg&#818;h&#818;a&#772;nah, 1979-&lt;/dd&gt;
+                
+        
+<!-- [...] -->
+&lt;/dl&gt;
+    </summary>
+  </entry>
+<!-- [...] -->
+</feed>
+```
+
+
+The same HTML summary included in your HTML results pages are included as an `atom:summary` element -- the atom template uses the `[[#render_document_partial|https://github.com/projectblacklight/blacklight/blob/master/app/helpers/blacklight_helper.rb#L311]]` helper method to generate this HTML summary, so if you've over-ridden that for your app, it will be used as the  `atom:summary` content instead.
+
+## API Usage
+The Atom response is intended to be pretty full of data, so it can fill many traditional API requests.  It makes use of every relevant atom or [[OpenSearch|http://www.opensearch.org/Home]] element that could be conveniently included. 
+
+The Atom response also supports arbitrary format representations in the `atom:content` element.  You can include `&content_format=some_format` in your request URL (e.g. `[[/catalog.atom?content_format=oai_dc_xml|http://demo.projectblacklight.org/catalog.atom?q=urdu&content_format=oai_dc_xml]]`). Any format a given document can be exported as using the [[Blacklight document framework|Extending-blacklight-with-the-document-extension-framework]]  is available. Not every document can export in every format -- if a format is requested one or more of the items in your atom result can not export as, it will not have an `atom:content` element.  Non-XML-based formats are supported, as the content is Base64-encoded (as per Atom spec, unless the format is `text/plain`). 
+```xml
+<?xml version="1.0" encoding="UTF-8"?>
+<feed xmlns:opensearch="http://a9.com/-/spec/opensearch/1.1/" xmlns="http://www.w3.org/2005/Atom">
+  <title>Blacklight Search Results</title>
+  <author>
+    <name>Blacklight</name>
+  </author>
+  <link href="http://demo.projectblacklight.org/?content_format=oai_dc_xml&amp;amp;format=atom&amp;amp;per_page=1" rel="self"/>
+<!-- [...] -->
+  <entry>
+    <title>The book of the dance in the 20th century selections from the Jane Bourne Parton collection of books on the dance</title>
+    <updated>2011-05-11T17:59:32Z</updated>
+    <link href="http://demo.projectblacklight.org/catalog/u1" rel="alternate" type="text/html"/>
+<link href="http://demo.projectblacklight.org/catalog/u1.dc_xml" rel="alternate" title="dc_xml" type="text/xml" />
+<link href="http://demo.projectblacklight.org/catalog/u1.xml" rel="alternate" title="xml" type="application/xml" />
+    <id>http://demo.projectblacklight.org/catalog/u1</id>
+    <author>
+      <name>Roatcap, Adela Spindler</name>
+    </author>
+    <summary type="html">
+<!-- [...] -->
+    </summary>
+<!-- [ Here is the export format as OAI Dublin Core XML ] -->
+    <content type="text/xml">
+<oai_dc:dc xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/oai_dc/ http://www.openarchives.org/OAI/2.0/oai_dc.xsd" xmlns:oai_dc="http://www.openarchives.org/OAI/2.0/oai_dc/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><dc:language>English</dc:language><dc:title>The book of the dance in the 20th century selections from the Jane Bourne Parton collection of books on the dance</dc:title><dc:format>Book</dc:format></oai_dc:dc>    </content>
+  </entry>
+</feed>
+```
+
+This means that if you add on a document extension that provides more export formats for some or all of your documents, that will automatically be available in the atom response. 
+
+If you choose to use the [[Blacklight CQL add-on|https://github.com/projectblacklight/blacklight_cql]], the combination of [[CQL|http://www.loc.gov/standards/sru/specs/cql.html]]  requests and Atom responses provides a pretty good more-or-less standards-based API to search results through Blacklight. 
+
+The Atom response generating template is at `app/views/catalog/index.builder.atom`.

data/doc/CUSTOMIZING.md

@@ -0,0 +1,121 @@
+# Customizing Blacklight
+
+There are lots of way to override specific behaviors and views in Blacklight. Blacklight is distributed as a Ruby gem with a Rails Engine framework built in. All customization of Blacklight behavior should be done within your application (partly as good practice, but also to not lose your changes with every new Blacklight release).
+
+If you find that there is no other way to make your customization, please describe your problem on the [[mailing list|http://groups.google.com/group/blacklight-development]] -- we'll do the best we can to help out, and even make changes to Blacklight as needed. If you are interested in contributing code to Blacklight, see the [[Contributing to Blacklight]] page.
+
+## Layouts 
+
+The built-in Blacklight controllers all by default use a Rails view layout called "blacklight", that lives in the Blacklight source. This ends up being a bit confusing, but is the best way we have at present to have out of the box default using a layout with full functionality, without stepping on a possibly existing local 'application' layout. 
+
+To change what layout the Blacklight controllers use, simply implement a method #layout_name in your local application_controller.rb that returns the name of the layout you'd like them to use. 
+
+```ruby
+    def layout_name
+       "application"
+    end
+```
+
+When implmeenting your own layout instead of using the stock one, you may want to look at the Blacklight app/views/layouts/blacklight.html.erb file to see what helper methods are called there, to maintain full Blacklight functionality you may want to call these same helper methods. An example would be insertion of alternate format auto-discovery link tags in the head section; if you call out to BL helpers, BL will make sure it happens.  Another example would be the sidebar_items helper; if you don't call out to that, your page won't include sidebar content such as facet lists. 
+
+## Overriding Views (templates and partials)
+As a Rails Engine, you can easily override views in your app. You can see what views and partials are provided by looking in `[[./app/views|https://github.com/projectblacklight/blacklight/tree/master/app/views]]` inside the Blacklight source.
+
+Once you find the view you'd like to change, you should create a file with the same name and relative path in your own application (e.g. if you wanted to override [[./app/views/catalog/_show_partials/_default.html.erb|https://github.com/projectblacklight/blacklight/blob/master/app/views/catalog/_show_partials/_default.html.erb]] you would create ./app/views/catalog/_show_partials/_default.html.erb in your local application. Frequently, you will start by copying the existing Blacklight view and modifying it from there.
+
+It is generally recommended that you override as little as possible, in order to maximize your forward compatibility. Look to override either a small, focused partial template, or a helper method of partial template called from a larger template, so your application's version can call out to those same helpers or partial templates within blacklight core code. 
+
+## Overriding the Catalog controller
+Overriding the Blacklight CatalogController implementation is easy, and the skeleton of the `CatalogController` is generated into your application for you when you install Blacklight. 
+
+See the [[Extending or Modifying Blacklight Search Behavior]] for tips and approaches to customizing the catalog.
+
+## Overriding Other Controllers
+
+1. Find the controller you're interested in in blacklight's app/controllers/  . 
+2. Create a file with the same name in your local app/controllers. 
+3. This file requires the original class, and then re-opens it to add more methods.
+ 
+```ruby
+require "#{Blacklight.controllers_dir}/some_controller"
+
+class SomeController < ApplicationController
+   # custom code goes here
+end
+```
+
+In that "custom code goes here", you can redefine certain methods (action methods or otherwise) to do something different.  You can also add new methods (again action methods or otherwise), etc. 
+
+It's kind of hard to call 'super' to call original functionality: 
+
+* the ruby language features here make 'super' unavailable, although you can work around that confusingly with the rails #alias_method_chain method. 
+* but more importantly, action methods in particular don't really suit themselves to being over-ridden and called by super, because the original implementation often does something you'd want to change but there's no easy way to 'undo' -- calling 'render', which can only be called once. 
+
+So basically, if you find yourself wanting to access some functionaltiy in the original implementation of a method that you also want to over-ride -- the best solution is probably to refactor Blacklight core code to put that functionality in a subsidiary method, so you can over-ride the action method entirely but call that logic from core.  Action methods should be short and sweet anyway. 
+
+
+## Custom View Helpers
+
+(This is accurate for Blacklight 3.1.1 and subsequent. Before that, things were messier). 
+
+One of the most common things you might need to do is create a view helper -- especially to override some Blacklight behavior implemented in it's own view helpers. The first step is looking at Blacklight source to determine what view helper method you want to override. 
+
+Blacklight comes packaged with several view helper modules. There is a BlacklightHelper in (blacklight source) app/helpers/blacklight_helper.rb , and several others that correspond to specific controller. (Note, depending on version of Rails and configuration, all helpers may get loaded for every request, even ones that are named to correspond only to a particular other controller). 
+
+If you simply created a local helper with the same name as a helper in Blacklight, that will end up preventing the Blacklight helper from being loaded at all though, which is not what you want to do to override. 
+
+We've structured each Blacklight view helper module into two parts to make it easy to selectively over-ride methods. For instance, here's Blacklight's app/helpers/blacklight_helper.rb:
+
+```ruby
+module BlacklightHelper
+  include Blacklight::BlacklightHelperBehavior
+end
+```
+
+Now, the actual methods will be found in app/helpers/blacklight/blacklight_helper_behavior.rb instead. 
+
+If you want to over-ride a helper method, copy the wrapper blacklight_helper into your local app, with the 'include' line, and now you can individually over-ride methods from BlacklightHelpersBehavior, and the other methods you don't over-ride will still have their default implementation. 
+
+YOUR `app/helpers/blacklight_helper.rb`
+
+```ruby
+module BlacklightHelper
+  include Blacklight::BlacklightHelperBehavior
+
+  def application_name
+    "Bestest University Search"
+  end
+end
+```
+
+One helper you might want to over-ride for customization is #render_document_partial (currently defined in [[blacklight_helper|https://github.com/projectblacklight/blacklight/blob/master/app/helpers/blacklight_helper.rb]]), which you can over-ride to choose differnet local partial views to display a document on search results or detail page, possibly varying depending on type of document according to your own local logic. 
+
+## Adding in your own CSS or Javascript
+
+You probably already have a local `app/controllers/application_controller.rb`. If you've installed the Blacklight plugin already, it probably looks something like this:
+```ruby
+class ApplicationController < ActionController::Base
+  # Adds a few additional behaviors into the application controller 
+  include Blacklight::Controller
+end
+```
+
+Now create a css file called whatever you want in the application's `./public/stylesheets` directory inside the class definition, add like so:
+```ruby
+    class ApplicationController < ActionController::Base
+        before_filter :add_my_own_assets
+
+        protected
+        def add_my_own_assets
+            stylesheet_links << "my_css"
+
+            # You can do something similar with javascript files too:
+            # javascript_includes << "my_js"
+        end
+    end
+```
+
+## See also
+
+* [[Extending or Modifying Blacklight Search Behavior]]
+* [[Pagination]]

data/doc/Extending-blacklight-with-the-document-extension-framework.md

@@ -0,0 +1 @@
+See [[Blacklight::Solr::Document rdoc|http://rdoc.info/github/projectblacklight/blacklight/master/Blacklight/Solr/Document]]

data/doc/Extending-or-Modifying-Blacklight-Search-Behavior.md

@@ -0,0 +1,131 @@
+# Extending or Modifying Blacklight Search Behavior
+
+Solr parameters used by for a given request can come from several different places. 
+
+* Solr request handler: solrconfig.xml in your solr config
+* Application logic: logic in the BL rails app itself
+
+## Solr request handler
+
+The Solr [[Request Handlers|http://wiki.apache.org/solr/SolrRequestHandler]] may be configured in the [[solrconfig.xml|http://wiki.apache.org/solr/SolrConfigXml]] and are baked into the request handler itself. Depending on how you have blacklight configured, your app may be using the same Solr request handler for all searches, or may be using different request handlers for different "search fields".  
+
+The request handler is often set up with default parameters:
+
+```xml
+  <requestHandler name="standard" class="solr.SearchHandler" >
+     <lst name="defaults">
+       <str name="echoParams">explicit</str>
+       <str name="rows">10</str> 
+       <str name="fl">*</str>   
+       <str name="facet">true</str>
+       <str name="facet.mincount">1</str>
+       <str name="facet.limit">30</str> 
+       <str name="facet.field">access_facet</str>
+       <str name="facet.field">author_person_facet</str>
+       <str name="facet.field">author_other_facet</str>
+       <str name="facet.field">building_facet</str>
+       <str name="facet.field">callnum_1_facet</str>
+       <str name="facet.field">era_facet</str>
+       <str name="facet.field">format</str>
+       <str name="facet.field">geographic_facet</str>
+       <str name="facet.field">language</str>
+       <str name="facet.field">pub_date_group_facet</str>
+       <str name="facet.field">topic_facet</str>
+     </lst>
+  </requestHandler>
+```
+## Configuration
+
+The default application logic (explained below) looks in configuration for things like the name of a the solr request handler to use, and default request parameters to send on every solr search request (or with every request from a certain blacklight search type/field). An example getting started configuration is generally installed into your app when you install Blacklight at `[[./config/initializers/blacklight_config.rb|https://github.com/projectblacklight/blacklight/blob/master/lib/generators/blacklight/templates/config/blacklight_config.rb]]`.
+
+Nothing special about the filename 'blacklight_config.rb', anything in a Rails app at `./config/initializers/*.rb` gets run on application startup, what matters it the code.
+
+## Application logic
+
+The logic Blacklight uses to determine how to map user-supplied parameters into Solr request parameters for a given application request is in the [[#solr_search_params method in the SolrHelper module|https://github.com/projectblacklight/blacklight/blob/master/lib/blacklight/solr_helper.rb#L76]]. Note that `[[CatalogController|https://github.com/projectblacklight/blacklight/blob/master/app/controllers/catalog_controller.rb]]` extends `[[SolrHelper|https://github.com/projectblacklight/blacklight/blob/master/lib/blacklight/solr_helper.rb]]`, so the `SolrHelper` methods become available in the `CatalogController` (and other controllers, if they extend `SolrHelper` too). 
+
+Behind the scenes, #solr_search_params uses the `class_inheritable_accessor` method [[solr_search_params_logic|https://github.com/projectblacklight/blacklight/blob/master/lib/blacklight/solr_helper.rb#L30]]. solr_search_params_logic is essentially a class variable that is mixed into the CatalogController and provides an ordered list of methods to call that may inspect the supplied user parameters and add, remove, or modify the Solr request parameters that will be sent to an [[RSolr|https://github.com/mwmitchell/rsolr/]] object, which in turn will convert the hash into query parameters for a Solr request. One confusing thing is that RSolr and  [[RSolr-ext|https://github.com/mwmitchell/rsolr-ext]] provide their own mappings from certain custom terms to Solr-recognized request parameters. For instance, a `:per_page` key in that hash will get mapped to the Solr `&rows` parameter -- but a `:rows` key will also.  We Blacklight developers have found that using these special RSolr "aliases" leads to confusion, as well as confusing bugs (if both `:per_page` and `:rows` are set in the hash, what happens can be hard to predict).  So we try to avoid using the special RSolr aliases, and just use ordinary Solr parameters in our hashes. But you may encounter older code that uses the RSolr aliases. 
+
+There can be similar confusing behavior or bugs if one piece of code adds a key to a `Hash` using a `Symbol`, but another piece of code looks for and/or adds that same key to the `Hash` using a `String` instead. RSolr happens to accepts either one, but if both are present RSolr behavior can be unexpected. And even before it gets to RSolr, you may have code that thinks it replaced a key but did not becuase it was using the wrong form. Blacklight developers have agreed to try and always use `Symbol` based keys in hashes meant for Solr parameters, to try and avoid these problems. Longer term, we could probably make some code changes to make this kind of error less likely. 
+
+The default `#solr_search_params_logic` is meant to handle very common cases and patterns based on simple configuration options, usually set in the `config/blacklight_config.rb` file, and the user-supplied URL parameters.
+
+* `[[Blacklight.config[:default_solr_params]|https://github.com/projectblacklight/blacklight/blob/master/config/initializers/blacklight_config.rb#L44]]`
+    * Default params sent to solr with every search, including the default :qt param, which determines which Solr request handler will be targetted. Some people like to use solrconfig.xml request handler defaults exclusively, and include only a :qt here; others find it more convenient to specify some defaults at the application level here. 
+* `[[Blacklight.config[:search_fields]|https://github.com/projectblacklight/blacklight/blob/master/config/initializers/blacklight_config.rb#L194]]`
+   * An array of hashes, each of which defines a 'search field' which will be presented in a select menu in the BL user interface search box. These 'search fields' don't neccesarily correspond 1-to-1 with Solr fields. What they instead correspond to is Solr parameter over-rides that will be used for this BL UI search field.  Those over-rides are present here. 
+   * You could simply chose a different `:qt` Solr request handler for each search field, which has it's own default parameters in the sorlconfig.xml. This is what we started out doing with Solr, but found it led to much duplication of information in solrconfig.xml. 
+   * You can continue using the same Solr request handler, but simply specify different parameters which will be included in the http query string sent to Solr here, with the `:solr_parameters`  key. This works fine, but some people don't like how it makes your Solr requests much longer/more complex in the Solr logs; and/or they prefer to control this Solr side instead of Application side. 
+   * For the best of both worlds, although it's a bit confusing at first, you can use the `:solr_local_parameters` key to have parameters supplied to Solr using the Solr [[LocalParams|http://wiki.apache.org/solr/LocalParams]] syntax, which means you can use "parameter dereferencing"  with dollar-sign-prefixed references to variables defined in solrconfig.xml request handler. This is what the current example BL setup does. 
+
+So the default implementation of `#solr_search_params` takes these configured parameters, combines them with certain query parameters from the current users HTTP request to the BL app, and prepares a Hash of parameters that will be sent to solr. For common use patterns, this is all you need. 
+
+But sometimes you want to add some custom logic to `#solr_search_params` to come up with the solr params Hash in different ways. Typically to support a new UI feature of some kind, either in your local app or in a Blacklight add-on plugin you are developing. 
+
+
+# Extending Blacklight::SolrHelper#solr_search_params
+
+To add new search behaviors (e.g. authorization controls, pre-parsing query strings, etc), the easiest route is to add additional steps to the `#solr_search_params_logic`, either at the beginning of the list (to set default parameters) or at the end of the list (to force particular parameters). Because `#solr_search_params_logic` is just an ordinary array, you may perform any normal array operation (e.g. push/pop/delete/insert) to customize the parameter generation to meet your needs.
+
+`#solr_search_params_logic` steps take two inputs, the hash of `solr_parameters` and the hash of `user_parameters` (often provided by the URL parameters), and modifies the `solr_parameters` directly, as needed. 
+
+You can add custom solr_search_params_logic steps within the `blacklight_config.rb` (or in many other places) by adding a Symbol with the name of a method (provided by the controller) you wish to use, e.g.:
+
+*./config/initializers/blacklight_config.rb*
+
+```ruby
+CatalogController.solr_search_params_logic << :show_only_public_records
+```
+(note, this method of using an initiailizer has trouble if the local CatalogController is reloaded with Rails development-mode class reloading, it'll miss the mod to solr_search_params_logic on reload. To get around this, either use `to_prepare do`, or just mod the solr_search_params_logic in the local CatalogController class definition, as below)
+
+The controller must provide the method added to `solr_search_params_logic`, in this case `show_only_public_records`. It is often convenient to do this in a separate `Module` and include it into the controller:
+
+*./app/controllers/catalog_controller.rb*
+
+```ruby
+require 'blacklight/catalog'
+class CatalogController < ApplicationController 
+  include Blacklight::Catalog
+  include MyApplication::SolrHelper::Authorization
+  
+  # Instead of defining this within an initializer, you may instead wish to do it on the controller directly:
+  # self.solr_search_params_logic << :show_only_public_records
+
+  # You could also define the actual method here, but this is not recommended.
+  # def show_only_public_records solr_parameters, user_parameters
+  #  [...]
+  # end
+end
+```
+
+The included module then defines the logic method:
+ 
+*./lib/my_application/solr_helper/authorization.rb*
+
+```ruby
+module MyApplication::SolrHelper::Authorization
+#  You could also add the logic here
+#  def self.included base
+#    base.solr_search_params_logic << :show_only_public_records
+#  end
+
+  # solr_search_params_logic methods take two arguments
+  # @param [Hash] solr_parameters a hash of parameters to be sent to Solr (via RSolr)
+  # @param [Hash] user_parameters a hash of user-supplied parameters (often via `params`)
+  def show_only_public_records solr_parameters, user_parameters
+    # add a new solr facet query ('fq') parameter that limits results to those with a 'public_b' field of 1 
+    solr_parameters[:fq] ||= []
+    solr_parameters[:fq] << 'public_b:1'
+  end
+end
+```
+
+## Other examples
+
+In addition to providing this behavior locally, some Blacklight plugins also extend the `#solr_search_params`:
+
+* [[Blacklight Range Limit|https://github.com/projectblacklight/blacklight_range_limit/blob/master/lib/blacklight_range_limit/controller_override.rb]]
+
+* A walk through on adding a checkbox limit at: http://bibwild.wordpress.com/2011/06/13/customing-blacklight-a-limit-checkbox/
+
+* A much more complicated walk-through on adding an 'unstemmed search' checkbox limit: http://bibwild.wordpress.com/2011/06/20/customizing-blacklight-disable-automatic-stemming/

data/doc/Features.md

@@ -0,0 +1,147 @@
+## Discovery
+### Search Features
+Blacklight uses Solr as its "search engine". More information about Solr is available at the [[Solr web site|http://lucene.apache.org/solr/]]
+
+* Search queries can be targeted at configurable fields (or sets of fields) to return precise search results. Advanced search capabilities are provided through the [[Advanced Search Add-On|https://github.com/projectblacklight/blacklight_advanced_search]] 
+[[https://github.com/projectblacklight/projectblacklight.github.com/raw/master/images/search_fields.png|frame|alt=Search fields in action]]
+
+```ruby
+  # Now we see how to over-ride Solr request handler defaults, in this
+  # case for a BL "search field", which is really a dismax aggregate
+  # of Solr search fields. 
+  config[:search_fields] << {
+    :key => 'title',     
+    # solr_parameters hash are sent to Solr as ordinary url query params. 
+    :solr_parameters => {
+      :"spellcheck.dictionary" => "title"
+    },
+    # :solr_local_parameters will be sent using Solr LocalParams
+    # syntax, as eg {! qf=$title_qf }. This is neccesary to use
+    # Solr parameter de-referencing like $title_qf.
+    # See: http://wiki.apache.org/solr/LocalParams
+    :solr_local_parameters => {
+      :qf => "$title_qf",
+      :pf => "$title_pf"
+    }
+  }
+```
+
+>  Source: [[./config/initializers/blacklight_config.rb|https://github.com/projectblacklight/blacklight/blob/master/lib/generators/blacklight/templates/config/blacklight_config.rb#L155]]
+
+
+- Faceted search allows users to constrain searches by controlled vocabulary items
+[[https://github.com/projectblacklight/projectblacklight.github.com/raw/master/images/search_facets.png|frame|alt=Search facets in action]]
+
+```ruby
+  # solr fields that will be treated as facets by the blacklight application
+  #   The ordering of the field names is the order of the display
+  # TODO: Reorganize facet data structures supplied in config to make simpler
+  # for human reading/writing, kind of like search_fields. Eg,
+  # config[:facet] << {:field_name => "format", :label => "Format", :limit => 10}
+  config[:facet] = {
+    :field_names => (facet_fields = [
+      "format",
+      "pub_date",
+      "subject_topic_facet",
+      "language_facet",
+      "lc_1letter_facet",
+      "subject_geo_facet",
+      "subject_era_facet"
+    ]),
+    :labels => {
+      "format"              => "Format",
+      "pub_date"            => "Publication Year",
+      "subject_topic_facet" => "Topic",
+      "language_facet"      => "Language",
+      "lc_1letter_facet"    => "Call Number",
+      "subject_era_facet"   => "Era",
+      "subject_geo_facet"   => "Region"
+    },
+    # Setting a limit will trigger Blacklight's 'more' facet values link.
+    # * If left unset, then all facet values returned by solr will be displayed.
+    # * If set to an integer, then "f.somefield.facet.limit" will be added to
+    # solr request, with actual solr request being +1 your configured limit --
+    # you configure the number of items you actually want _displayed_ in a page.    
+    # * If set to 'true', then no additional parameters will be sent to solr,
+    # but any 'sniffed' request limit parameters will be used for paging, with
+    # paging at requested limit -1. Can sniff from facet.limit or 
+    # f.specific_field.facet.limit solr request params. This 'true' config
+    # can be used if you set limits in :default_solr_params, or as defaults
+    # on the solr side in the request handler itself. Request handler defaults
+    # sniffing requires solr requests to be made with "echoParams=all", for
+    # app code to actually have it echo'd back to see it.     
+    :limits => {
+      "subject_topic_facet" => 20,
+      "language_facet" => true
+    }
+  }
+```
+
+> Source: [[./config/initializers/blacklight_config.rb|https://github.com/projectblacklight/blacklight/blob/master/lib/generators/blacklight/templates/config/blacklight_config.rb#L39]]
+
+* Blacklight provides basic spellcheck suggestions for poor search queries
+[[https://github.com/projectblacklight/projectblacklight.github.com/raw/master/images/search_spellcheck.png|frame|alt=Spellchecking user queries]]
+
+* Blacklight provides flexible mapping from user queries to solr parameters, which are easily overridable in local applications (see [[Extending or Modifying Blacklight Search Behavior]]).
+
+```ruby
+    # Each symbol identifies a _method_ that must be in
+    # this class, taking two parameters (solr_parameters, user_parameters)
+    # Can be changed in local apps or by plugins, eg:
+    # CatalogController.include ModuleDefiningNewMethod
+    # CatalogController.solr_search_params_logic << :new_method
+    # CatalogController.solr_search_params_logic.delete(:we_dont_want)
+    self.solr_search_params_logic = [:default_solr_parameters , :add_query_to_solr, :add_facet_fq_to_solr, :add_facetting_to_solr, :add_sorting_paging_to_solr ]
+```
+
+> Source: [[./lib/blacklight/solr_helper.rb|https://github.com/projectblacklight/blacklight/blob/master/lib/blacklight/solr_helper.rb#L70]]
+
+
+### Other
+- Stable URLs allow users to bookmark, share, and save search queries for later access
+- Recent searches are saved in the Search History for quick access to previous queries
+- Folder + Bookmarks allow users to collect and keep track of items as they browse
+- Every Blacklight search provides RSS and [[Atom Responses]] of search results 
+- Blacklight supports [[OpenSearch|http://www.opensearch.org/Home]], a collection of simple formats for the sharing of search results. The OpenSearch description document format can be used to describe a search engine so that it can be used by search client applications. The OpenSearch response elements can be used to extend existing syndication formats, such as RSS and Atom, with the extra metadata needed to return search results. (From OpenSearch Introduction)
+
+## Access
+### Export
+- Cite
+- Refworks
+- Endnote
+- Email
+- SMS
+- Librarian View
+
+For compatible records, an [[OpenURL/Z39.88 COinS|http://www.zotero.org/support/dev/making_coins]] object is embedded in each document, which allows plugins like Zotero to easily extract data from the page. 
+
+### Semantic Fields
+
+### Document Extension Framework
+
+The main use case for extensions is for transforming a Document to another
+format. Either to another type of Ruby object, or to an exportable string in
+a certain format. 
+
+An Blacklight::Solr::Document extension is simply a ruby module which is mixed
+in to individual Document instances.  The intended use case is for documents
+containing some particular format of source material, such as Marc. An
+extension can be registered with your document class, along with a block
+containing custom logic for which documents to apply the extension to.
+
+```ruby
+    SolrDocument.use_extension(MyExtension) {|document| my_logic_on_document(document}
+```
+
+MyExtension will be mixed-in (using ruby 'extend') only to those documents
+where the block results in true.
+
+Underlying metadata formats, or other alternative document views, are linked to from the HTML page <head>. 
+
+### Data Formats
+MaRC
+
+## Testing
+
+
+Additional features are available through [[Blacklight Add-ons]].

data/doc/Integration-with-Rails-Footnotes.md

@@ -0,0 +1,20 @@
+[[Rails Footnotes|https://github.com/josevalim/rails-footnotes]] is a helpful plugin that displays footnotes in your application for easy debugging, such as sessions, request parameters, cookies, filter chain, routes, queries, etc. Installing Rails Footnotes is very easy, just add this to your Gemfile:
+```ruby
+gem 'rails-footnotes', '>= 3.7', :group => :development
+```
+
+And add something like this to config/initializers/footnotes.rb to run the Footnotes plugin:
+```ruby
+if defined?(Footnotes) && Rails.env.development?
+  Footnotes.run!
+end
+```
+
+To add RSolr debugging information to the footnotes panel, you can use the [[RSolr Footnotes|https://github.com/cbeer/rsolr-footnotes]] gem by adding this to your Gemfile:
+```ruby
+gem "rsolr-footnotes", :group => :development
+```
+
+RSolr footnotes will capture every solr request with basic performance information and provide a link back to the Solr request URL.
+
+[[https://github.com/projectblacklight/projectblacklight.github.com/raw/master/images/rsolr_footnotes_example.png|frame|alt=Example of RSolr Footnotes in the Blacklight Demo App]]

data/doc/Pagination.md

@@ -0,0 +1,38 @@
+Blacklight uses [kaminari](https://github.com/amatsuda/kaminari) for providing pagination of Solr responses. 
+
+One motivation for this is so a pagination view theme can be provided that you can use for your custom code with ordinary ActiveRecord or anything else kaminari can handle, to have consistency between the rest of your app's pagination and Blacklight's Solr response pagination. 
+
+## How it works
+
+The Blacklight #paginate_params helper method takes an RSolr::Response, and converts it to something Kaminari #paginate can handle. (Basically just by translating some attribute names). So you could call:
+
+    paginate( paginate_params(@response) )  # where @response is an RSolr::Response
+
+But there's a shortcut Blacklight helper method which compacts this, #paginate_rsolr_response:
+
+    paginate_solr_response @response, :theme => 'blacklight'
+
+The `theme => 'blacklight'` part will be passed through kaminari, and tell kaminari to use the theme that the Blacklight plugin supplies at [app/views/kaminari/blacklight](https://github.com/projectblacklight/blacklight/tree/master/app/views/kaminari/blacklight)
+
+Any other arguments of ordinary kaminari paginate can also be passed in there. If all client code uses #paginate_solr_response, it also provides a 'hook' for local apps to completely over-ride pagination rendering, perhaps not even using kaminari. 
+
+Additionally, we sometimes want to output a "Showing X through Y of N" message, which kaminari doesnt' have a way to do by default, so we just provide our own way in a Blacklight view helper method, which takes a RSolr::Response too:
+
+    render_pagination_info(@response)
+
+## Changing the kaminari theme
+
+If you want to change how pagination links are rendered, the easiest/cleanest thing to do is to over-ride the 'blacklight' theme that the Blacklight plugin defines. Copy the view templates in Blacklight source at app/views/kaminari/blacklight to your own local app/views/kaminari/blacklight.  You actually only need to copy files you'll want to modify, templates not overridden with a local copy will still be found by kaminari from the Blacklight gem.  You can use any techniques available for creating a kaminari theme when editing these files, including over-riding more kaminari view templates if available. See the kaminari documentation. 
+
+There are other ways you could change how Blacklight pagination renders, but by doing it this way, any code (in core Blacklight or additional plugins you install) that tries to render pagination using kaminari with 'blacklight' theme will get your locally defined theme. 
+
+The "pagination info" (showing X through Y of N) is not part of the kaminari theme, but just a blacklight view helper method, #render_pagination_info.  To change this, just over-ride this method [[over-ride locally|CUSTOMIZING]] like any other Blacklight view helper method. 
+
+## Using kaminari theme for your own pagination
+
+Your local app may show pagination of ActiveRecord objects, that you'd like to appear consistent with other Blacklight pagination. Just use kaminari to show the pagination HTML, with the theme :blacklight.  This technique can be used for anything kaminari can paginate, such as Mongoid et al, in addition to ActiveRecord. Fetch the ActiveRecords using ordinary kaminari techniques (see kaminari docs) and then:
+
+    paginate @my_active_records, :theme => 'blacklight'
+
+That's it. There's currently no great way to display the #render_pagination_info for anything but RSolr::Response. 
+

data/doc/Quickstart.md

@@ -0,0 +1,97 @@
+## Pre-requisites
+ * ruby v 1.8.7 or higher
+ * git
+ * java 1.5 or higher
+ * access to a command prompt on the machine to install
+    (preferably unix based)
+
+In addition, you must have the Bundler and Rails ruby gems installed:
+
+```bash
+$ gem install bundler
+$ gem install rails
+```
+
+## Install and Use
+
+1. Create a new rails 3 application
+
+    ```bash
+    $ rails new my_app      
+    #      create  
+    #      create  README
+    #      create  Rakefile
+    #      create  config.ru
+    #      create  .gitignore
+    #      create  Gemfile
+    #      [...]
+
+    $ cd my_app
+    ```
+
+    Rails automatically created an `index.html` file; Blacklight will provide a default `root` route, so you probably want to remove it:
+
+    ```bash
+    $ rm public/index.html
+    ```
+
+2. Append this line to your application's `Gemfile`
+
+    ```ruby
+    gem 'blacklight'
+    ```
+    and update the bundle
+
+    ```bash
+    $ bundle install
+    ```
+
+3. Install blacklight using Devise for user authentication: 
+
+    ```bash
+    $ gem install devise
+    $ rails generate blacklight --devise
+    ```
+    If you would prefer to integrate with an alternative user authentication provider, see the [[User Authentication]] documentation.
+
+4. Run your database migrations
+
+    ```bash
+    $ rake db:migrate
+    ```
+
+5. You will need to install and configure Solr. You can install
+Blacklight's example Solr configuration (using the jetty servlet container) that is configured to work with
+Blacklight's defaults, like:
+
+    ```bash
+    $ rails generate blacklight:jetty
+    ```
+
+    Alternatively, you can also install your own copy of Solr or point Blacklight at an existing Solr server ( referred to in your `config/solr.yml`). The Blacklight
+configuration must match your Solr configuration. In addition, Blacklight has minor expectations about the Solr configuration and schemas. You can generate the Blacklight demonstration solrconfig and schema files using:
+
+    ```bash
+    $ rails generate blacklight:solr_conf path/to/output/directory/
+    ```
+  
+6.  Make sure your Solr server is running. If you installed the Blacklight demo Solr/Jetty package, you can start the Jetty/Solr server using:
+
+    ```bash
+    $ cd jetty && java -jar start.jar &
+    $ cd ..
+    ```
+
+6. Index some data. You can index test MARC records provided Blacklight running:
+
+    ```bash
+    $ rake solr:marc:index_test_data
+    ```
+
+7. Start up your application
+
+    ```bash
+    $ rails server
+    ```
+
+Visit the catalog at [[http://localhost:3000/catalog]]

data/doc/Upgrading-Guide.md

@@ -0,0 +1,98 @@
+This page outlines the basic steps needed to upgrade your customized installation of Blacklight to work with the new Rails 3 branch available in our repository.  This is very much in beta now - and while we would love feedback, I don't recommend you use this branch in any sort of production environment. 
+
+## Rails 3 Specific Changes:
+Please see [[http://omgbloglol.com/post/353978923/the-path-to-rails-3-approaching-the-upgrade]] - for a good introduction.
+ 
+1. Start by installing Rails3, generate a new app, make sure it works.  doing this not only proves your rails3 installation is working, but it will also get you familiar with the command line tools - which are very different now.
+1. Now, create a new rails app on top of your existing application. This will make all sorts of modifications, creating and updating your Gemfile, Rakefile, application.rb, locals, new javascript, etc...  You should also remove all the files in /script/ except for rails - since these scripts are no longer used.
+```bash
+$ rails new my_existing_app
+```
+
+1. Routes are WAY different in rails 3.  Please see [[http://www.engineyard.com/blog/2010/the-lowdown-on-routes-in-rails-3/]]
+1. Most of your application specific configuration now takes place in a file called config/application.rb  - you will need to move most of what is currently in your config/environment.rb and config/boot.rb into this new file. (see the link at the top of thie section for a good overview of how this works)
+1. The lib directory is no longer auto-loaded - and the general recommendation is not to make it so (though it is possible inside of config/application.rb) - I went through and added requires methods where and when they are needed in the individual files, which is nice - because now it is far more clear what needs what.
+1. Rails3 escapes strings by default.  You will have to add html_safe to any ruby string variables printed within "<%=" tags
+
+## Other Gems that will need upgrading
+1. If you were using the ExceptionNotification gem, things have changed in rails,  There is a good explanation here:
+    http://stackoverflow.com/questions/3524127/exception-notification-gem-and-rails-3
+1.  If your are using Rspec, you will need to upgrade it in your gem file to version 2.  And you will need to re-run the generator
+```ruby
+gem 'rspec', '>2.0.0'
+$rails generate spec:install
+```
+1.  Recapcha, and Prawnto - I was previously using these as plugins, but they have good gems now, so I removed these from the plugin directory, and added them to the gemfile.
+1. If you are using Marc, make sure you are running 0.4.1 - ran into some problems related to changes in the way Rails3 handles json prior to this upgrade.
+
+## Blacklight Specific Changes
+1. There is no application_helper.rb file in blacklight now.  It was moved to blacklight_helper, and its methods are made available automatically. (see blacklight/engine.rb for more information) So if you were attepting to include this file and override it, don't.  Just redefine the methods in your application_helper, and you should be fine.
+1.  Remove the blacklight plugin directory from /vendor - since you will be installing in as a gem.   If you have blacklight checked out somewhere, you can point to it in your gem file as follows:
+```ruby
+   gem 'blacklight', :path => '../some/file/path/to/blacklight' 
+```
+otherwise, just reference the blacklight gem, which we will make available on rubygems shortly.
+```ruby
+   gem 'blacklight' 
+```
+1. Most of the configuration of blacklight is done through monkey patching at present.  In Virgo you would often see lines like:
+```ruby
+  require_dependency 'vendor/plugins/blacklight/....
+```
+at the top of a file that re-opened the class and made modifications to it. 
+You would now need to change this to:
+```ruby
+  require "#{Blacklight.controllers_dir}/bookmarks_controller" For controllers, and ...
+  require "#{Blacklight.models_dir}/bookmark" For models.
+```
+1. Blacklight no longer includes a user model or session controller.  It seems that everyone just rolls their own anyway.  So here you will need to add in whatever you need - in my case, that was just creating a user model.  Which looks like this:
+```ruby
+       class User < ActiveRecord::Base                                    
+         include Blacklight::User
+         acts_as_authentic                               
+       end
+```
+Please also see the notes on the application controller below ...
+
+1. Execute the Blacklight Generator   - This will add all kinds of files to your local application - including stylesheets, images, jar files, database migrations, etc..  It will try it's best to be "idempotent" as Jonathan likes to say - that it is shouldn't mess anything up to run this over and over again.  It will verify that the changes it's making are not already in place.
+```bash
+      $ rails generate blacklight
+```
+1. For the most part, you override a blacklight controller by including the class and then reopening it.  Unfortunately, the catalog controller was unique in the way it number of additional lib files it required and included, and it caused a number of problems attepting to just override it.  So a catalog controller is generated for you on installation (unless you already have one).  You catalog controller should look something like this (which allows you to easily override solrhelper and catalog controller methods)
+```ruby
+class CatalogController < ApplicationController
+    include Blacklight::SolrHelper
+    inlcude Blacklight::Catalog
+     .....
+ end
+```
+If you end up overriding a large number of solrhelper methods, you can also override the solr helpers in your own file, and then include that file.
+```ruby
+module UVA::SolrHelper
+   include Blacklight::SolrHelper
+   .....
+end
+
+class CatalogController < ApplicationController
+   include UVA::SolrHelper
+   include Blacklight::Catalog
+  ....
+end
+```
+1. Application Controller
+     The blacklight generator, will add a line to your application controller if isn't there already which will cause the application controller to include the base controller logic for blacklight:
+```ruby
+     class ApplicationController < ActionController::Base
+         include Blacklight::Controller
+     end     
+```
+    This blacklight controller forces the the blacklight layout, adds the default_html_head before filter and associated helper methods, and creates a few helper methods for users.  Blacklight by no means requires the inclusion of this file.  In the case of Virgo, we do not. 
+
+   You will most likely need to define the following methods in your application controller, paticularly if you have any sort of custom user authentication.
+
+* `user_session` - which should return the current rails session object.
+* `current_user`  - which should return a user object that includes Blacklight::User
+* `new_user_session_path` - which should return the path for logging into your application
+* `destroy_user_session_path` - which should return the path for logging out of your application.
+
+SolrDocument is no longer a file in Blacklight, but rather a generated model in your application, in this way you can easily override and modify the behavior of individual documents. This is automatically created for you, I just wanted to draw you attention to it.

data/doc/User-Authentication.md

@@ -0,0 +1,54 @@
+After [[CODEBASE-325|http://jira.projectblacklight.org/jira/browse/CODEBASE-325]] is implemented, Blacklight does not require user authentication, however, if included, Blacklight can provide additional features for users ([[Bookmarks]], [[Saved Searches]], etc). Because of the wide range of institutional needs and capabilities, Blacklight does not require a specific user authentication provider.
+
+## Installing with Devise
+
+If you are rolling your own user authentication system, we highly recommend [[Devise|https://github.com/plataformatec/devise]], an extremely flexible authentication solution that is relatively straightforward. For directions to install the Blacklight gem using devise, see the [[Quickstart]].
+
+## Install and Use (with a custom user authentication system)
+
+Create a new rails 3 application
+```bash
+$ rails new my_app
+```
+
+Add blacklight to your gem file 
+```bash
+edit ./my_app/Gemfile
+```
+```ruby.
+# Append this line to the end of the file:
+gem 'blackight'
+```
+
+```bash
+$ bundle install
+```
+
+If you have a `User` model already, the Blacklight generator will connect to it automatically during installation.  However, you will need to make sure the following named routes are included in your /config/routes.rb file:
+
+```ruby
+  match 'your_login',          :to => 'Your User Session Controller # Log in action',       :as => 'new_user_session'
+  match 'your_logout',         :to => 'Your User Session Controller # Log Out action',      :as => 'destroy_user_session'
+  match 'your_account_page',   :to => 'Your User Session Controller # Account edit action', :as => 'edit_user_registration'
+```
+
+One blacklight view partial uses `#to_s` on your user model to get a user-displayable account name/identifier for the currently logged in account, so you probably want to have such a method. 
+
+Finally, you will need to make sure the following methods are available both on controllers and as helpers:
+
+* `current_user`   - Which should return a user object that include Blacklight::User
+* `user_session`   - Which are included in your /config/routes.rb file:
+
+Once these are in place, you can run the Blacklight Installation Generator:
+
+```bash
+$ rails generate blacklight [MODEL NAME]
+```
+Where model name is the name of your user model.
+
+Execute your migrations, and you should be good to go.
+```bash
+$ rake db:migrate
+```
+
+If you need to install Solr or the sample data, follow the directions from the see the [[Quickstart]].

data/doc/Using-a-custom-solr-uniquekey-field.md

@@ -0,0 +1,36 @@
+> The [[`uniqueKey`|http://wiki.apache.org/solr/UniqueKey]] encodes the identity semantics of a document. In database jargon, the primary key. 
+
+The default `uniqueKey` field in Blacklight is "id", however it is possible to configure Blacklight to use a different field. To configure the `uniqueKey` field to use, you must in Blacklight, you can update the Blacklight initializer in `./config/blacklight_initializer.rb`:
+
+```ruby
+Blacklight.configure(:shared) do |config|
+  config[:unique_key] = "my_custom_unique_key_field"
+```
+
+(You could also make this change "in code" by defining a `Class`-level `unique_key` method on `SolrDocument`, e.g.:
+```ruby
+class SolrDocument
+  def self.unique_key
+    "my_custom_unique_key_field"
+  end
+end
+```
+)
+
+You must also modify the `document` request handler in Solr to map the user parameter `id` to the Solr `uniqueKey` field, e.g.:
+
+```xml
+  <!-- for requests to get a single document; use id=666 instead of q=id:666 -->
+  <requestHandler name="document" class="solr.SearchHandler" >
+    <lst name="defaults">
+      <str name="echoParams">all</str>
+      <str name="fl">*</str>
+      <str name="rows">1</str>
+      <str name="q">{!raw f=my_custom_unique_key_field v=$id}</str> <!-- use id=666 instead of q=id:666 -->
+    </lst>
+  </requestHandler>
+```
+
+## Code Standards
+
+When writing code in Blacklight (or a dependent plugin or local app) that needs to look at the unique ID for a SolrDocument, you should always ask for someDocument.id and *not* someDocument['id'], in order for your code to work with configured unique_key, not hard-coded to a key named 'id'. 

metadata

@@ -1,10 +1,15 @@
---- !ruby/object:Gem::Specification
+--- !ruby/object:Gem::Specification 
 name: blacklight
-version: !ruby/object:Gem::Version
-  version: 3.1.1
+version: !ruby/object:Gem::Version 
+  hash: 7
   prerelease: 
+  segments: 
+  - 3
+  - 1
+  - 2
+  version: 3.1.2
 platform: ruby
-authors:
+authors: 
 - Jonathan Rochkind
 - Matt Mitchell
 - Chris Beer
@@ -16,96 +21,125 @@ authors:
 autorequire: 
 bindir: bin
 cert_chain: []
-date: 2011-10-12 00:00:00.000000000 Z
-dependencies:
-- !ruby/object:Gem::Dependency
-  name: rails
-  requirement: &2153500840 !ruby/object:Gem::Requirement
+
+date: 2011-12-06 00:00:00 Z
+dependencies: 
+- !ruby/object:Gem::Dependency 
+  requirement: &id001 !ruby/object:Gem::Requirement 
     none: false
-    requirements:
+    requirements: 
     - - ~>
-      - !ruby/object:Gem::Version
-        version: '3.0'
-  type: :runtime
+      - !ruby/object:Gem::Version 
+        hash: 7
+        segments: 
+        - 3
+        - 0
+        version: "3.0"
+  version_requirements: *id001
   prerelease: false
-  version_requirements: *2153500840
-- !ruby/object:Gem::Dependency
-  name: nokogiri
-  requirement: &2153500360 !ruby/object:Gem::Requirement
+  name: rails
+  type: :runtime
+- !ruby/object:Gem::Dependency 
+  requirement: &id002 !ruby/object:Gem::Requirement 
     none: false
-    requirements:
+    requirements: 
     - - ~>
-      - !ruby/object:Gem::Version
-        version: '1.5'
+      - !ruby/object:Gem::Version 
+        hash: 5
+        segments: 
+        - 1
+        - 5
+        version: "1.5"
+  version_requirements: *id002
+  prerelease: false
+  name: nokogiri
   type: :runtime
+- !ruby/object:Gem::Dependency 
+  requirement: &id003 !ruby/object:Gem::Requirement 
+    none: false
+    requirements: 
+    - - ">="
+      - !ruby/object:Gem::Version 
+        hash: 3
+        segments: 
+        - 0
+        version: "0"
+  version_requirements: *id003
   prerelease: false
-  version_requirements: *2153500360
-- !ruby/object:Gem::Dependency
   name: unicode
-  requirement: &2153499980 !ruby/object:Gem::Requirement
-    none: false
-    requirements:
-    - - ! '>='
-      - !ruby/object:Gem::Version
-        version: '0'
   type: :runtime
-  prerelease: false
-  version_requirements: *2153499980
-- !ruby/object:Gem::Dependency
-  name: marc
-  requirement: &2153499440 !ruby/object:Gem::Requirement
+- !ruby/object:Gem::Dependency 
+  requirement: &id004 !ruby/object:Gem::Requirement 
     none: false
-    requirements:
+    requirements: 
     - - ~>
-      - !ruby/object:Gem::Version
+      - !ruby/object:Gem::Version 
+        hash: 9
+        segments: 
+        - 0
+        - 4
+        - 3
         version: 0.4.3
+  version_requirements: *id004
+  prerelease: false
+  name: marc
   type: :runtime
+- !ruby/object:Gem::Dependency 
+  requirement: &id005 !ruby/object:Gem::Requirement 
+    none: false
+    requirements: 
+    - - "="
+      - !ruby/object:Gem::Version 
+        hash: 19
+        segments: 
+        - 1
+        - 0
+        - 2
+        version: 1.0.2
+  version_requirements: *id005
   prerelease: false
-  version_requirements: *2153499440
-- !ruby/object:Gem::Dependency
   name: rsolr
-  requirement: &2153498940 !ruby/object:Gem::Requirement
-    none: false
-    requirements:
-    - - ~>
-      - !ruby/object:Gem::Version
-        version: '1.0'
   type: :runtime
+- !ruby/object:Gem::Dependency 
+  requirement: &id006 !ruby/object:Gem::Requirement 
+    none: false
+    requirements: 
+    - - "="
+      - !ruby/object:Gem::Version 
+        hash: 17
+        segments: 
+        - 1
+        - 0
+        - 3
+        version: 1.0.3
+  version_requirements: *id006
   prerelease: false
-  version_requirements: *2153498940
-- !ruby/object:Gem::Dependency
   name: rsolr-ext
-  requirement: &2153498480 !ruby/object:Gem::Requirement
-    none: false
-    requirements:
-    - - ~>
-      - !ruby/object:Gem::Version
-        version: '1.0'
   type: :runtime
+- !ruby/object:Gem::Dependency 
+  requirement: &id007 !ruby/object:Gem::Requirement 
+    none: false
+    requirements: 
+    - - ">="
+      - !ruby/object:Gem::Version 
+        hash: 3
+        segments: 
+        - 0
+        version: "0"
+  version_requirements: *id007
   prerelease: false
-  version_requirements: *2153498480
-- !ruby/object:Gem::Dependency
   name: kaminari
-  requirement: &2153498100 !ruby/object:Gem::Requirement
-    none: false
-    requirements:
-    - - ! '>='
-      - !ruby/object:Gem::Version
-        version: '0'
   type: :runtime
-  prerelease: false
-  version_requirements: *2153498100
-description: Blacklight is a free and open source ruby-on-rails based discovery interface
-  (a.k.a. “next-generation catalog”) especially optimized for heterogeneous collections.
-  You can use it as a library catalog, as a front end for a digital repository, or
-  as a single-search interface to aggregate digital content that would otherwise be
-  siloed.
-email:
+description: "Blacklight is a free and open source ruby-on-rails based discovery interface (a.k.a. \xE2\x80\x9Cnext-generation catalog\xE2\x80\x9D) especially optimized for heterogeneous collections. You can use it as a library catalog, as a front end for a digital repository, or as a single-search interface to aggregate digital content that would otherwise be siloed."
+email: 
 - blacklight-development@googlegroups.com
 executables: []
+
 extensions: []
+
 extra_rdoc_files: []
-files:
+
+files: 
 - .gitignore
 - .gitmodules
 - .yardopts
@@ -231,6 +265,17 @@ files:
 - config/locales/kaminari.yml
 - config/routes.rb
 - db/seeds.rb
+- doc/Atom-Responses.md
+- doc/CUSTOMIZING.md
+- doc/Extending-blacklight-with-the-document-extension-framework.md
+- doc/Extending-or-Modifying-Blacklight-Search-Behavior.md
+- doc/Features.md
+- doc/Integration-with-Rails-Footnotes.md
+- doc/Pagination.md
+- doc/Quickstart.md
+- doc/Upgrading-Guide.md
+- doc/User-Authentication.md
+- doc/Using-a-custom-solr-uniquekey-field.md
 - install.rb
 - install/solr.yml
 - lib/blacklight.rb
@@ -365,32 +410,36 @@ files:
 - uninstall.rb
 homepage: http://projectblacklight.org/
 licenses: []
+
 post_install_message: 
 rdoc_options: []
-require_paths:
+
+require_paths: 
 - lib
-required_ruby_version: !ruby/object:Gem::Requirement
+required_ruby_version: !ruby/object:Gem::Requirement 
   none: false
-  requirements:
-  - - ! '>='
-    - !ruby/object:Gem::Version
-      version: '0'
-      segments:
+  requirements: 
+  - - ">="
+    - !ruby/object:Gem::Version 
+      hash: 3
+      segments: 
       - 0
-      hash: -4207963229405450438
-required_rubygems_version: !ruby/object:Gem::Requirement
+      version: "0"
+required_rubygems_version: !ruby/object:Gem::Requirement 
   none: false
-  requirements:
-  - - ! '>='
-    - !ruby/object:Gem::Version
-      version: '0'
-      segments:
+  requirements: 
+  - - ">="
+    - !ruby/object:Gem::Version 
+      hash: 3
+      segments: 
       - 0
-      hash: -4207963229405450438
+      version: "0"
 requirements: []
+
 rubyforge_project: blacklight
-rubygems_version: 1.8.10
+rubygems_version: 1.8.12
 signing_key: 
 specification_version: 3
 summary: A next-geration Library Catalag for Universities
 test_files: []
+