[Blacklight-development] blacklight questiosn

[Jonathan Rochkind]

Thanks, that's helpful! [And yes, can someone change the list to reply 
to list, not reply to sender? I didn't get this message previously]

MARC serial holdings handling is... a mess. But yeah, based on what's 
there, I think I see how one would add it. It would not neccesarily be 
easy--especially because serial holdings often make another layer of 
object in the object model. It's no longer just 'records' which hold 
items, it's title-level records that have a one-to-many with 'copy' 
level records, which in turn have a one to many with 'items'. But anyway.

Yeah, I get that flare isn't used for indexing, just search and display. 
I'll look at the unit tests, good advice. And thanks for warning me that 
the 'flare' in Blacklight is actually a forked version of an open source 
project. (What motivated THAT? Why not send your patches back to the 
real flare?).  If the existing blacklight developers wanted to do one 
thing to make blacklight easier for others to work wtih and 
adopt---document your fork of flare, please!   Just do it with rdoc-able 
comments. A couple lines about what each class represents, a sentance or 
two (if neccesary) for each method, and some examples.

Jonathan

Erik Hatcher wrote:
> (I noticed reply goes to the sender - I wonder if we can configure it  
> such that replies go to the list?   Bess?)
>
> I'll take a stab at replying....
>
> On Feb 11, 2008, at 11:02 AM, Jonathan Rochkind wrote:
>   
>> Hi all, I've started taking a look at the Blacklight code. Very nice
>> clean code, nice job. [ Although some more comments wouldn't have  
>> hurt! :) ]
>>     
>
> ha!
>
>   
>> I see you store the entire marc record in a field, and use that   
>> stored
>> MARC for display, the index fields are just used for indexing. Which
>> makes sense; I understand that right?
>>     
>
> Yup.
>
>   
>> I don't understand how the default_controller.rb comes into play.
>> Nothing I know about Rails says anything about a "default controller"
>> being part of rails--and I don't see any of the other controllers
>> extending or including it---so what is this file used for, if  
>> anything?
>> Is it leftover from a previous version, and should be deleted?
>>     
>
> Looks like a leftover to me also, and can be removed.
>
>   
>> I see that I don't think you've handled 'status' (checked out,
>> available, etc.) at all, true?
>>     
>
> Status is not currently handled - that is correct.
>
>   
>>   Do you handle serial holdings at all
>> (ie, showing what the ranges of coverage or individual volumes held  
>> are
>> for a serial, right in Blacklight?).
>>     
>
> No, that is not handled either.  If that info is in the MARC record,  
> and this is a display-only sort of need, it should be fairly  
> straightforward to address this.  I know nothing about that  
> particular corner of MARC though.
>
>   
>> Have you tried to tackle highlighting of _where_ in the record your
>> search matched, at all?  Do you know what I mean?
>>     
>
> Highlighting is possible, and in fact the underlying query made to  
> Solr is requesting highlighting (search keyword highlighting, I mean  
> here).   Any field could be selectively highlighted.  Highlighting is  
> not currently being rendered though - it was removed from my initial  
> prototype in its current incarnation.   You can see it commented out  
> in views/catalog/_record.rhtml partial.
>
>   
>> You don't support any kind of fielded search except for limiting by
>> facets right now, right? No way to enter a fielded keyword search?
>>     
>
> Not true.   The full Solr/Lucene QueryParser is at your disposal  
> because Solr's standard request handler is being used (it really  
> should be migrated to using DisMax for better relevancy tuning - a  
> related topic because that then eliminates user entered fielded  
> searches).
>
> But currently, if you know the field names, you can use them using  
> this syntax:
> <http://wiki.apache.org/solr/SolrQuerySyntax>
>
> Example: author_text:jonathan
>
> The field names are not the most intuitive for end users though, so  
> that is an issue.
>
>   
>> And in general, I'm having trouble understanding how the Flare code
>> works exactly, what is the heart of both the indexing and the display,
>> yes?  Any advice for understanding what's going on there? I admit I
>> haven't done much with SOLR; if I understand SOLR, will the Flare API
>> map pretty obviously to SOLR functions?
>>     
>
> The Flare code is not quite clear to me either :)   It was taken on  
> and morphed greatly after my departure, so it is it's own beast I'm  
> unfamiliar with.
>
> The heart of the indexing code is scripts/virgo_marc_map.rb - the  
> mapping from MARC to Solr.  Flare is not involved at all in indexing,  
> if that is what you're asking.
>
> Flare is used purely for searching/displaying results, and keep in  
> mind the "Flare" we speak of here is Blacklight's own forked and  
> highly customized version of what is in the open source codebase of  
> Solr's client/ruby/flare svn tree - no relationship at all at the  
> moment.
>
> Best advice for understanding what is going on in code is, as always,  
> with the unit tests :)   There appears to be a decent set of tests in  
> scripts/test/mapping_test.rb - though I haven't run it myself.
>
> Maybe we can get Matt, forker of Flare, to chime in on this topic too.
>
> 	Erik
>
> _______________________________________________
> Blacklight-development mailing list
> Blacklight-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/blacklight-development
>   

-- 
Jonathan Rochkind
Digital Services Software Engineer
The Sheridan Libraries
Johns Hopkins University
410.516.8886 
rochkind (at) jhu.edu