blacklight 3.8.1 → 3.8.2

Sign up to get free protection for your applications and to get access to all the features.
Files changed (48) hide show
  1. data/.travis.yml +14 -0
  2. data/VERSION +1 -1
  3. data/app/controllers/bookmarks_controller.rb +2 -0
  4. data/app/models/solr_document.rb +5 -0
  5. data/app/views/_user_util_links.html.erb +2 -0
  6. data/app/views/catalog/_bookmark_control.html.erb +1 -1
  7. data/doc/Atom-Responses.md +90 -0
  8. data/doc/Blacklight-3.2-Release-Notes-and-Upgrade-Guide.md +191 -0
  9. data/doc/Blacklight-3.3-release-notes-and-upgrade-guide.md +37 -0
  10. data/doc/Blacklight-3.4-release-notes-and-upgrade-guide.md +27 -0
  11. data/doc/Blacklight-3.5-release-notes-and-upgrade-guide.md +44 -0
  12. data/doc/Blacklight-3.6-release-notes-and-upgrade-guide.md +25 -0
  13. data/doc/Blacklight-3.7-release-notes-and-upgrade-guide.md +78 -0
  14. data/doc/Blacklight-3.8-release-notes-and-upgrade-guide.md +11 -0
  15. data/doc/Blacklight-Add-ons.md +28 -0
  16. data/doc/Blacklight-configuration.md +301 -0
  17. data/doc/Blacklight-on-Heroku.md +135 -0
  18. data/doc/Community-principles.md +44 -0
  19. data/doc/Configuring-and-Customizing-Blacklight.md +271 -0
  20. data/doc/Contributing-to-Blacklight.md +25 -0
  21. data/doc/Examples.md +62 -0
  22. data/doc/Extending-or-Modifying-Blacklight-Search-Behavior.md +141 -0
  23. data/doc/Home.md +77 -0
  24. data/doc/How-to-release-a-version.md +37 -0
  25. data/doc/Indexing-your-data-into-solr.md +5 -0
  26. data/doc/Integration-with-Rails-Footnotes.md +20 -0
  27. data/doc/Pagination.md +38 -0
  28. data/doc/Providing-your-own-view-templates.md +109 -0
  29. data/doc/Quickstart.md +116 -0
  30. data/doc/README.md +77 -0
  31. data/doc/README_SOLR.md +245 -0
  32. data/doc/Release-Notes-And-Upgrade-Guides.md +14 -0
  33. data/doc/Sunspot-for-indexing.md +46 -0
  34. data/doc/User-Authentication.md +60 -0
  35. data/doc/testing.md +115 -0
  36. data/lib/blacklight/controller.rb +4 -1
  37. data/lib/generators/blacklight/blacklight_generator.rb +2 -1
  38. data/lib/solrmarc.log.1 +849 -0
  39. data/test_support/bin/test.sh +3 -1
  40. data/test_support/features/record_view.feature +0 -1
  41. data/test_support/features/search.feature +0 -1
  42. data/test_support/features/step_definitions/error_steps.rb +1 -1
  43. data/test_support/features/step_definitions/general_steps.rb +1 -1
  44. data/test_support/features/step_definitions/search_facets_steps.rb +7 -7
  45. data/test_support/features/step_definitions/search_steps.rb +2 -2
  46. data/test_support/spec/{requests → features}/alternate_controller_spec.rb +0 -0
  47. data/test_support/spec/helpers/blacklight_helper_spec.rb +5 -5
  48. metadata +37 -5
@@ -0,0 +1,135 @@
1
+ Blacklight can be deployed on [Heroku](http://heroku.com/), a Platform-as-a-Service (PaaS) provider that supports Ruby. This walkthrough assumes some familiarity with Heroku, that you have a Solr server running somewhere, and that you already have a Heroku account. For more information on working with Heroku, please see [Getting Started with Heroku](https://devcenter.heroku.com/articles/quickstart).
2
+
3
+ ## Create a new Blacklight app
4
+
5
+ * Use the Blacklight [[Quickstart]] to create a new Rails application:
6
+
7
+ ```bash
8
+ $ rails new blheroku
9
+ # create
10
+ # create README
11
+ # create Rakefile
12
+ # create config.ru
13
+ # create .gitignore
14
+ # create Gemfile
15
+ # [...]
16
+
17
+ $ cd blheroku
18
+ $ rm public/index.html
19
+
20
+ * Append this line to your application's `Gemfile`:
21
+
22
+ ```ruby
23
+ gem 'blacklight'
24
+ ```
25
+
26
+ * Install the gems using Bundler:
27
+
28
+ ```bash
29
+ $ bundle install
30
+ ```
31
+
32
+ * Call the Blacklight generator (in this case, without Devise for authentication):
33
+
34
+ ```bash
35
+ $ rails generate blacklight
36
+ ```
37
+
38
+ ## Change Gem dependencies for Heroku deployment
39
+
40
+ * Change the database-related gems in your `Gemfile` from:
41
+
42
+ ```ruby
43
+ gem 'sqlite3'
44
+ ```
45
+
46
+ * to the following:
47
+
48
+ ```ruby
49
+ gem 'sqlite3', :groups => [:development, :test]
50
+ gem 'pg', :group => :production
51
+ ```
52
+
53
+ * Move all gems in the asset block of `Gemfile` to the main block [see here for more info](http://stackoverflow.com/questions/9629620), changing from:
54
+
55
+ ```ruby
56
+ # Gems used only for assets and not required
57
+ # in production environments by default.
58
+ group :assets do
59
+ gem 'sass-rails', '~> 3.2.3'
60
+ gem 'coffee-rails', '~> 3.2.1'
61
+
62
+ # See https://github.com/sstephenson/execjs#readme for more supported runtimes
63
+ # gem 'therubyracer'
64
+
65
+ gem 'uglifier', '>= 1.0.3'
66
+ end
67
+
68
+ # ... probably at the bottom from here on out
69
+
70
+ gem "compass-rails", "~> 1.0.0", :group => :assets
71
+ gem "compass-susy-plugin", "~> 0.9.0", :group => :assets
72
+ ```
73
+
74
+ * to the following:
75
+
76
+ ```ruby
77
+ # Gems used only for assets and not required
78
+ # in production environments by default.
79
+ gem 'sass-rails', '~> 3.2.3'
80
+ gem 'coffee-rails', '~> 3.2.1'
81
+
82
+ # See https://github.com/sstephenson/execjs#readme for more supported runtimes
83
+ # gem 'therubyracer'
84
+
85
+ gem 'uglifier', '>= 1.0.3'
86
+
87
+ # ... probably at the bottom from here on out
88
+
89
+ gem "compass-rails", "~> 1.0.0"
90
+ gem "compass-susy-plugin", "~> 0.9.0"
91
+ ```
92
+
93
+
94
+ ## Configure Solr for your application
95
+
96
+ * While untested, you may want to look at [Websolr](http://websolr.com/), which provides Solr as a Service.
97
+ * Add a line `config/solr.yml` to point to your production instance of Solr:
98
+
99
+ ```yaml
100
+ production:
101
+ url: http://my.solr.host:8983/path/to/solr
102
+ ```
103
+
104
+ ## Index some test records
105
+
106
+ ```bash
107
+ $ RAILS_ENV=production rake solr:marc:index_test_data
108
+ ```
109
+ ## Set up Heroku
110
+
111
+ ```bash
112
+ $ git init
113
+ $ heroku create --stack cedar
114
+ Creating vivid-winter-2427... done, stack is cedar
115
+ http://vivid-winter-2427.herokuapp.com/ | git@heroku.com:vivid-winter-2427.git
116
+ Git remote heroku added
117
+ $ git add .
118
+ $ git commit -m"Initial import"
119
+ ```
120
+
121
+ * Take note of the URL reported back by Heroku (in this case, http://vivid-winter-2427.herokuapp.com/)
122
+
123
+ ## Deploy to Heroku
124
+
125
+ ```bash
126
+ $ git push heroku master
127
+ [...]
128
+ $ heroku run rake db:migrate
129
+ [...]
130
+ ```
131
+
132
+ ## Try opening up your app
133
+
134
+ * Go to URL reported by Heroku above (in this example, http://vivid-winter-2427.herokuapp.com/).
135
+ * Does it work? If it doesn't, try running `heroku logs` to see where problems are cropping up.
@@ -0,0 +1,44 @@
1
+ # Community Principles
2
+
3
+ ## Overview
4
+ * Blacklight is an open source application for libraries (and anyone else), built on top of SOLR, and meant to deliver excellent access to all classes of information resources.
5
+ * Blacklight can ultimately be successful and sustainable in the long run only if it is an open project; that is, it takes contributions from a community of developers across many institutions to enhance and support it
6
+ * We will work to balance progress on Blacklight’s codebase with open community discussion and transparent decision making as coequal goals
7
+ * Blacklight code is available through the Apache 2.0 open source license.
8
+
9
+ ## Technical Leadership
10
+ Technical leadership of the project will be through a small group of proven developers who have demonstrated commitment to Blacklight’s progress and success (and have commit rights to the source code)
11
+
12
+ Committers must be:
13
+
14
+ * technically adept
15
+ * constructive, positive members of the Blacklight software community
16
+ * committed to producing useful, practical code for the community
17
+
18
+ To become a committer, candidates must be…
19
+
20
+ * nominated by a current committer
21
+ * voted on and approved by a majority of the current committers
22
+ * committers may be voted out at any time by a (super?) majority of the other committers
23
+
24
+ Committers will have a regular meeting, usually in the form of a conference call, to coordinate development & direction.
25
+
26
+ Releases will be vetted and controlled by a designated lead or leads. These roles may shift from release to release.
27
+
28
+ ## Code Contributions & Principles
29
+ * the users of, interest in, resources, and talent pool of the Blacklight community will spread far beyond the developers on the committers list, and their institutions
30
+ * Blacklight encourages and will facilitate taking code from contributors from many sources
31
+ the structure of the source code management (soon GIT) will facilitate incorporating and using code from many sources
32
+ * Blacklight committers will actively take code contributions from non-committers and incorporate it into the code trunk
33
+ * Working code wins
34
+ * You get what you give
35
+ * All contributed code must have full test coverage before it is committed. The current testing infrastructure is RSpec for everything but Rails views, and Cucumber for for Rails views.
36
+ * Tests must be committed at the same time code is.
37
+ * All javascript features (where feasible) should be added using “progressive enhancement” or “unobtrusive javascript” styles. Meaning the basic feature should work without Javascript, and the JS should be added as a progressive enhancement, and added via externally linked js files, not in-line in html source as script tags, onclick attributes, etc.
38
+ * All bugs and development tasks will be tracked in GitHub Issues
39
+ * All code must be documented before it’s committed
40
+
41
+ ## Roadmap & Transparency
42
+ We will publish a roadmap to guide overall development. The items on this roadmap will be determined after an inclusive process of canvassing the wider Blacklight community, including code committers, contributors, users and a potential advisory board.
43
+
44
+ We envision regular/quarterly/semiannual/annual Blacklight convention of community members to help guide and galvanize new developments. These are likely to be appended to other community events, e.g., code4lib, for the sake of logistics.
@@ -0,0 +1,271 @@
1
+ # Configuring and Customizing Blacklight
2
+
3
+ There are lots of ways 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).
4
+
5
+ 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.
6
+
7
+ ## Configuration
8
+
9
+
10
+ Blacklight provides a Ruby on Rails -based interface to the Apache Solr Enterprise Search Server. More information about Solr is available at the [[Solr web site|http://lucene.apache.org/solr/]]. In order to fully understand this section, you should be familiar with Solr, ways to index data into Solr, how to configure request handlers, and how to change a Solr schema. Those topics are covered in the official [Apache Solr Tutorial](http://lucene.apache.org/solr/tutorial.html).
11
+
12
+ Although the out-of-the-box Blacklight application is configured to work with library MARC-based data, the configuration is easy to extend and modify to meet other needs. **All of these configurations for facet fields, index fields, solr search params logic, etc. go in your CatalogController**. By default, this will be located at *app/controllers/catalog_controller.rb*
13
+
14
+ **Note:** While it is sufficient to have just one CatalogController, You can actually create multiple variations of the catalog controller (ie. MusicCatalog, DvdCatalog), each with its own configuration settings and URL routing.
15
+
16
+ Once you have your Solr fields, you can then configure your Blacklight application to display arbitrary fields in different contexts
17
+
18
+ ### Choose which Fields to Display in Search Results
19
+
20
+ * Displayed fields and labels can be customized on both the search results and document views.
21
+ Note that these must be STORED fields in the Solr index.
22
+
23
+ ```ruby
24
+ # [from app/controllers/catalog_controller.rb]
25
+ # solr fields to be displayed in the index (search results) view
26
+ # The ordering of the field names is the order of the display
27
+ config.add_index_field 'title_display', :label => 'Title:'
28
+ config.add_index_field 'title_vern_display', :label => 'Title:'
29
+ config.add_index_field 'author_display', :label => 'Author:'
30
+ config.add_index_field 'author_vern_display', :label => 'Author:'
31
+ ```
32
+
33
+ ### Targeting Search Queries at Configurable Fields
34
+
35
+ * 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]]
36
+ [[https://github.com/projectblacklight/projectblacklight.github.com/raw/master/images/search_fields.png|frame|alt=Search fields in action]]
37
+
38
+ ```ruby
39
+ # [from app/controllers/catalog_controller.rb]
40
+ # Now we see how to over-ride Solr request handler defaults, in this
41
+ # case for a BL "search field", which is really a dismax aggregate
42
+ # of Solr search fields.
43
+
44
+ config.add_search_field('title') do |field|
45
+ # solr_parameters hash are sent to Solr as ordinary url query params.
46
+ field.solr_parameters = { :'spellcheck.dictionary' => 'title' }
47
+
48
+ # :solr_local_parameters will be sent using Solr LocalParams
49
+ # syntax, as eg {! qf=$title_qf }. This is neccesary to use
50
+ # Solr parameter de-referencing like $title_qf.
51
+ # See: http://wiki.apache.org/solr/LocalParams
52
+ field.solr_local_parameters = {
53
+ :qf => '$title_qf',
54
+ :pf => '$title_pf'
55
+ }
56
+ end
57
+ ```
58
+
59
+ ### Choosing & Configuring Facets
60
+
61
+ - Faceted search allows users to constrain searches by controlled vocabulary items
62
+ [[https://github.com/projectblacklight/projectblacklight.github.com/raw/master/images/search_facets.png|frame|alt=Search facets in action]]
63
+ Note that these must be INDEXED fields in the Solr index, and are generally a single token (e.g. a string).
64
+
65
+ ```ruby
66
+ # [from app/controllers/catalog_controller.rb]
67
+ # solr fields that will be treated as facets by the blacklight application
68
+ # The ordering of the field names is the order of the display
69
+ config.add_facet_field 'format', :label => 'Format'
70
+ config.add_facet_field 'pub_date', :label => 'Publication Year'
71
+ config.add_facet_field 'subject_topic_facet', :label => 'Topic', :limit => 20
72
+ config.add_facet_field 'language_facet', :label => 'Language', :limit => true
73
+ ```
74
+
75
+ Blacklight also supports Solr facet queries:
76
+
77
+ ```ruby
78
+ config.add_facet_field 'pub_date_query', :label => 'Publication Year', :query => {
79
+ :last_5_years => { :label => 'Last 5 Years', :fq => "[#{Time.now.year-5} TO *]"}
80
+ }
81
+ ```
82
+
83
+ You can also tell Solr how to sort facets (either by count or index):
84
+ Note: setting 'index' causes Blacklight to sort by count and then by index. If your data is strings, you can use this to perform an alphabetical sort of the facets.
85
+ ```ruby
86
+ config.add_facet_field :my_count_sorted_field, :sort => 'count'
87
+ config.add_facet_field :my_index_sorted_field, :sort => 'index'
88
+ ```
89
+
90
+
91
+ If you want Solr to add the configured facets and facet queries to the Solr query it sends, you should also add:
92
+
93
+ ```ruby
94
+ config.add_facet_fields_to_solr_request!
95
+ ```
96
+
97
+ If you have date facets in Solr, you should add a hint to the Blacklight configuration:
98
+
99
+ ```ruby
100
+ config.add_facet_field :my_date_field, :date => true
101
+ ```
102
+
103
+ This will trigger special date querying logic, and also use a localized date format when displaying the facet value. If you want to use a particular localization format, you can provide that as well:
104
+
105
+ ```ruby
106
+ config.add_facet_field :my_date_field, :date => { :format => :short }
107
+ ```
108
+
109
+ ### Map from User Queries to Solr Parameters
110
+
111
+ * Blacklight provides flexible mapping from user queries to solr parameters, which are easily overridden in local applications (see [[Extending or Modifying Blacklight Search Behavior]]).
112
+
113
+ ```ruby
114
+ # [from app/controllers/catalog_controller.rb]
115
+ # Each symbol identifies a _method_ that must be in
116
+ # this class, taking two parameters (solr_parameters, user_parameters)
117
+ # Can be changed in local apps or by plugins, eg:
118
+ # CatalogController.include ModuleDefiningNewMethod
119
+ # CatalogController.solr_search_params_logic << :new_method
120
+ # CatalogController.solr_search_params_logic.delete(:we_dont_want)
121
+ 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 ]
122
+ ```
123
+
124
+ > Source: [[./lib/blacklight/solr_helper.rb|https://github.com/projectblacklight/blacklight/blob/master/lib/blacklight/solr_helper.rb#L70]]
125
+
126
+ ### Document Extension Framework
127
+
128
+ The main use case for extensions is for transforming a Document to another
129
+ format. Either to another type of Ruby object, or to an exportable string in
130
+ a certain format.
131
+
132
+ An Blacklight::Solr::Document extension is simply a ruby module which is mixed
133
+ in to individual Document instances. The intended use case is for documents
134
+ containing some particular format of source material, such as Marc. An
135
+ extension can be registered with your document class, along with a block
136
+ containing custom logic for which documents to apply the extension to.
137
+
138
+ ```ruby
139
+ SolrDocument.use_extension(MyExtension) {|document| my_logic_on_document(document}
140
+ ```
141
+
142
+ MyExtension will be mixed-in (using ruby 'extend') only to those documents
143
+ where the block results in true.
144
+
145
+ Underlying metadata formats, or other alternative document views, are linked to from the HTML page <head>.
146
+
147
+ # Customizing the User Interface
148
+ ## Layouts
149
+
150
+ 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.
151
+
152
+ 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.
153
+
154
+ ```ruby
155
+ # [from app/controllers/application_controller.rb]
156
+ class ApplicationController < ActionController::Base
157
+ ...
158
+ def layout_name
159
+ "application"
160
+ end
161
+ ...
162
+ end
163
+ ```
164
+
165
+ When implementing 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.
166
+
167
+ * `render_head_content` renders content within the
168
+ html `<head>` tag, which includes document-specific alternative
169
+ formats as well as tags generated by plugins, etc.
170
+ * `sidebar_items` renders features including sidebar content, e.g. facet
171
+ lists.
172
+ * flash messages
173
+ * user util links
174
+
175
+ ## Overriding Views (templates and partials)
176
+ 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.
177
+
178
+ 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.
179
+
180
+ 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.
181
+
182
+ ## Overriding the CatalogController
183
+ Overriding the Blacklight `CatalogController` implementation is easy, and the skeleton of the `CatalogController` is generated into your application for you when you install Blacklight.
184
+
185
+ See the [[Extending or Modifying Blacklight Search Behavior]] for tips and approaches to customizing the catalog.
186
+
187
+ ## Overriding Other Controllers
188
+
189
+ 1. Find the controller you're interested in blacklight's app/controllers/ .
190
+ 2. Create a file with the same name in your local app/controllers.
191
+ 3. This file requires the original class, and then re-opens it to add more methods.
192
+
193
+ ```ruby
194
+ require "#{Blacklight.controllers_dir}/some_controller"
195
+
196
+ class SomeController < ApplicationController
197
+ # custom code goes here
198
+ end
199
+ ```
200
+
201
+ 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.
202
+
203
+ It's kind of hard to call 'super' to call original functionality:
204
+
205
+ * the ruby language features here make 'super' unavailable, although you can work around that confusingly with the rails #alias_method_chain method.
206
+ * 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.
207
+
208
+ 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.
209
+
210
+
211
+ ## Custom View Helpers
212
+
213
+ (This is accurate for Blacklight 3.1.1 and subsequent. Before that, things were messier).
214
+
215
+ 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.
216
+
217
+ 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).
218
+
219
+ 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.
220
+
221
+ 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:
222
+
223
+ ```ruby
224
+ module BlacklightHelper
225
+ include Blacklight::BlacklightHelperBehavior
226
+ end
227
+ ```
228
+
229
+ Now, the actual methods will be found in app/helpers/blacklight/blacklight_helper_behavior.rb instead.
230
+
231
+ 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 BlacklightHelperBehavior, and the other methods you don't over-ride will still have their default implementation.
232
+
233
+ YOUR `app/helpers/blacklight_helper.rb`
234
+
235
+ ```ruby
236
+ module BlacklightHelper
237
+ include Blacklight::BlacklightHelperBehavior
238
+
239
+ def application_name
240
+ "Bestest University Search"
241
+ end
242
+ end
243
+ ```
244
+
245
+ 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.
246
+
247
+ ## Adding in your own CSS or Javascript
248
+
249
+ Within your local application, you can use the [[Rails Asset Pipeline|http://guides.rubyonrails.org/asset_pipeline.html]] to manipulate javascript and css documents.
250
+
251
+ **todo??** better instructions for over-riding BL's built in CSS using SASS? (jrochkind thought jamesws wrote such already, but can't find them now)
252
+
253
+ The Blacklight generator added a file to your app at `./app/assets/stylesheets/blacklight_themes/standard.css.scss`, elements of the BL default theme can be customized or over-ridden there. If there's something you want to do but aren't sur e the best way, feel free to ask on the listserv.
254
+
255
+ ### jquery-ui
256
+
257
+ Blacklight by default uses [jquery-ui](http://jqueryui.com/) for some UI widgets.
258
+
259
+ The Blacklight gem provides it's own JQuery-UI theme, and makes it work with the rails asset pipeline even precompiled. (as of BL 3.3.1).
260
+
261
+ To disable Blacklight's provision of JQuery-UI theme:
262
+
263
+ * comment out `*= require 'jquery/ui-lightness/jquery-ui-1.8.1.custom.css'` from your `./app/assets/stylesheets/application.css`
264
+ * add `Blacklight::Engine.config.jquery_images=false` to your `./config/application.rb` or some other control point that happens before Rails initialization.
265
+
266
+ Then [create your own JQuery-UI theme](http://jqueryui.com/themeroller/), and set it up yourself to be included and used in the rails asset pipeline. This can be tricky, [here's a blog post on options](http://bibwild.wordpress.com/2011/12/08/jquery-ui-css-and-images-and-rails-asset-pipeline/).
267
+
268
+ ## See also
269
+
270
+ * [[Extending or Modifying Blacklight Search Behavior]]
271
+ * [[Pagination]]