[ http://issues.apache.org/jira/browse/SOLR-37?page=comments#action_12430503 ] Andrew May commented on SOLR-37: --------------------------------
Mike, 1) Was using SVN support in Eclipse and it doesn't let you control this - I've installed the command line version now. 2) If GapFragmenter just has a default constructor it's not possible to pass the fragsize (constructors not inherited)? 3) My mistake - I think this is a legacy of me originally confusing fragsize and GapFragmenter's increment threshold. 4) Perhaps - I wasn't sure what sensible defaults were, and I can't seem to get the gradient fragmenter to do anything useful - but I can't see an obvious bug in my code to construct it. 5) That was me being overly defensive, and I've changed it now. I considered adding methods like getFieldInt(), getFieldBool to SolrParams, so there were field versions of all the non-field methods - but decided against it. 6) I was wondering whether a hl.exact flag might be useful - if false (the default?) the QueryScorer wouldn't be created with the field/maxTermWeight. I'm not sure there's any point using the gradient formatter unless you supply the field name/maxTermWeight, so that might ignore this setting. 7) Sorry - will fix and add additional tests. One thing I don't like about HighlightingUtils as it stands is the lack of state. When highlighting multiple fields, getParams() is called many times, each time constructing a DefaultSolrParams (although I don't think there's a big overhead to doing this). If we're not specifying the field when creating the QueryScorer then this could be reused for multiple fields. We could possibly re-use the highlighter instance as well. > Add additional configuration options for Highlighting > ----------------------------------------------------- > > Key: SOLR-37 > URL: http://issues.apache.org/jira/browse/SOLR-37 > Project: Solr > Issue Type: Improvement > Components: search > Reporter: Andrew May > Attachments: patch, patch > > > As discussed in the mailing list, I've been looking at adding additional > configuration options for highlighting. > I've made quite a few changes to the properties for highlighting: > Properties that can be set on request, or in solrconfig.xml at the top level: > highlight (true/false) > highlightFields > Properties that can be set in solrconfig.xml at the top level or per-field > formatter (simple/gradient) > formatterPre (preTag for simple formatter) > formatterPost (postTag for simple formatter) > formatterMinFgCl (min foreground colour for gradient formatter) > formatterMaxFgCl (max foreground colour for gradient formatter) > formatterMinBgCl (min background colour for gradient formatter) > formatterMaxBgCl (max background colour for gradient formatter) > fragsize (if <=0 use NullFragmenter, otherwise use GapFragmenter with this > value) > I've added variables for these values to CommonParams, plus there's a fields > Map<String,CommonParams> that is parsed from nested NamedLists (i.e. a lst > named "fields", with a nested lst for each field). > Here's a sample of how you can mix and match properties in solrconfig.xml: > <requestHandler name="hl" class="solr.StandardRequestHandler" > > <str name="formatter">simple</str> > <str name="formatterPre"><i></str> > <str name="formatterPost"></i></str> > <str name="highlightFields">title,authors,journal</str> > <int name="fragsize">0</int> > <lst name="fields"> > <lst name="abstract"> > <str name="formatter">gradient</str> > <str name="formatterMinBgCl">#FFFF99</str> > <str name="formatterMaxBgCl">#FF9900</str> > <int name="fragsize">30</int> > <int name="maxSnippets">2</int> > </lst> > <lst name="authors"> > <str name="formatterPre"><strong></str> > <str name="formatterPost"></strong></str> > </lst> > </lst> > </requestHandler> > I've created HighlightingUtils to handle most of the parameter parsing, but > the hightlighting is still done in SolrPluginUtils and the > doStandardHighlighting() method still has the same signature, but the other > highlighting methods have had to be changed (because highlighters are now > created per highlighted field). > I'm not particularly happy with the code to pull parameters from > CommonParams, first checking the field then falling back, e.g.: > String pre = (params.fields.containsKey(fieldName) && > params.fields.get(fieldName).formatterPre != null) ? > params.fields.get(fieldName).formatterPre : > params.formatterPre != null ? params.formatterPre : "<em>"; > I've removed support for a custom formatter - just choosing between > simple/gradient. Probably that's a bad decision, but I wanted an easy way to > choose between the standard formatters without having to invent a generic way > of supplying arguments for the constructor. Perhaps there should be > formatterType=simple/gradient and formatterClass=... which overrides > formatterType if set at a lower level - with the formatterClass having to > have a zero-args constructor? Note: gradient is actually > SpanGradientFormatter. > I'm not sure I properly understand how Fragmenters work, so supplying > fragsize to GapFragmenter where >0 (instead of what was a default of 50) may > not make sense. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
