Blacklight Plugin

Jonathan Rochkind added a comment - 15/Apr/10 6:16 PM Hmm, anyone know why this ticket doesn't show up in my JIRA lists of tickets assigned to me? But anyway, as we discussed, I can definitely do this, and I think it's useful for a variety of purposes. But Jessie, thinking about the advanced search stuff more --- is there any reason for the request handler used by the advanced search plugin to show up in the Blacklight URL _at all_? It seems to me it should just be hardcoded in your advanced search config, and used by the advanced search, without showing up in the Blacklight end-user URL at all. Are there any downsides to that?

Jessie Keck added a comment - 15/Apr/10 6:56 PM Are you looking at just JHU again? ( http://jira.projectblacklight.org/jira/secure/IssueNavigator.jspa?reset=true&assigneeSelect=specificuser&assignee=jrochkind ) Continuity with the rest of the entire application is why I want it to be in the URL. Think about sort, per_page, etc. Also, it just make it easier to tie in with the session search history w/o overriding tons of the search history code. Tying in with the search history is what makes all of the links back to the catalog and <prev | next> links work on the document page. I could a) override all of that code from my plugin to look for the config field or b) just use all of the excellent code already in Blacklight for generating these things and lessen the potential impact for the implementer. Right now, I can implement this w/o overriding much BL code at all, however it seems to me like any approach to make the Blacklight app aware of when we're doing an advanced search would require a lot of overriding. Basically, it seems like it would be a giant pain to do that and would make the plugin less flexible IMO.

Jonathan Rochkind added a comment - 15/Apr/10 8:50 PM Okay, cool, makes sense. Whatever leads to cleaner code with less over-riding of core, definitely the better! I was figuring you'd have to over-ride the solr params generation _anyway_, so could just throw setting the request handler to a "hard-coded" (Ie globally configured for advanced search thing) value there. But if it doesn't work out that way, then it doesn't, cool.

Jonathan Rochkind added a comment - 19/Apr/10 10:19 AM Complete. Param for search_field definition is actually called :include_in_simple_select, to match the API it effects better. Example: Blacklight[:config].search_fields << { :label => "Advanced Search", :key=>"advanced", :qt=>"extended", :include_in_simple_select => false }