On 7/21/06, Andrew May <[EMAIL PROTECTED]> wrote:
Mike Klaas wrote:
> [snip general config object constructor]
Sounds like a good idea. Do you think there's still value in being able to choose between simple/gradient with defined properties for the arguments? Unless someone wants to use a custom formatter that's going to be easier to configure without consulting the javadoc for those formatters (although I'm not sure I understand the Gradient formatter as it just seems to put out the same background colour for everything - which may be a bug or misunderstanding in what I've done).
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. 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. 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"
> Passing to the constructor makes sense, as it sets the fragmentSize of > the base SimpleFragmenter class (note the default is 100; 50 is the > position gap which indicates when to start a new fragment). > OK - I did mess this up then! Do you think the incrementThreshold in GapFragmenter (which is what I was actually setting) is something that needs to be configurable as well?
I don't think so. The most sensible thing to do if you are constructing a per-field Highlighter is to use the positionINcrementGap of the field's Analyzer. But the current default seems to do fine. -Mike
