On 7/21/06, Mike Klaas <[EMAIL PROTECTED]> wrote:
I think there might be value in providing less explicit Highlighter configuration and instead provide a set of intuitive options form which we can construct various configurations.
Sounds good... if we do it well, pretty much no one will need a custom highlighter. In the very rare case they did, a custom query handler could always be a fallback.
For another point of configuration is the Scorer -- right now the default QueryScorer is used. But you can also specify an IndexReader+fieldName to the QueryScorer constructor to augment fragment scores with IDF values for the terms, which is necessary to see a difference in Gradient formatting. It would be nice to hide all those details from the user.
Agree.
Perhaps the formatter spec could just be a single string: formatter="simple" # use default pre/post formatter = "simple;<em>;</em>" formatter = "gradient;#FFFFFF;#FFFFFF;#FFFFFF;#FFFFFF"
That goes back to the different ways to specify config. This is a variant of having more complex query args with a secondary parse (and escaping rules, etc). I'm undecided on if this is better than separate properties. It is more compact at least, and works OK when the number of parameters is limited. -Yonik
