Thanks Andrew!
I still think that being able to configure how a field is highlighted
on a per-query basis is almost as basic as being able to ask for which
fields to highlight or which fields to return. Regardless, per-query
overriding can be added later, but I think it should be kept in mind
at least while designing the configuration.
A couple of points about the config interface:
I think the proliferation of parameter names may be confusing either
in solrconfig.xml or in query args.
I think we should be using a convention like namespaces, much like
java property files do (think what a property file would be like
without that).
Parameter names like "formatter" or "fields" are pretty confusing if
you don't know the context is highlighting.... people could easily
think formatter specifies the output format (XML, JSON, etc), and
could very easily think that "fields" were the stored fields to
return.
Also, parameters like formatterPre, formatterPost, formatterMinFgCl,
etc aren't global... they only apply to specific highlighter
formatters, and you have to understand a lot about those formatters to
understand which apply. Some hierarchy could be added to reflect that
also.
If we put more of this info into our parameter names, it would ease
the burden of understanding for new users (and experienced ones too
perhaps)
So query args could be:
hl.formatter=simple
hl.fragsize=100
hl.simple.pre=<em>
hl.simple.post=</em>
hl.color.minBg=#FFFF99
hl.color.maxBg=#FF9900
And solrconfig.xml config could be the simple form
<str name="hl.formatter">simple</str>
<int name="hl.fragsize">simple</str>
OR, maybe it could be more structured and put the hierarchy in the XML:
<lst name="hl>
<str name="formatter">simple</name>
<int name="fragsize">100</int>
<lst name="simple">
<str name="pre"><em></str>
<str name="post"></em></str>
</lst>
In either XML config schema, it makes sense to try and keep it easy to
figure out how to override it via a query param (simple name mapping).
Of course I've only addressed global defaults, not per-field defaults,
but the same style could be used.
After going through this exercise and thinking it through, I think I'm
coming back to the same preference that Mike Klass had from the list
of examples: field properties. That way, if any other parameters need
per-field config, someone doesn't end up re-inventing the wheel all
over again in a non-consistent manner. It's also relatively easy to
explain to someone.
http://www.nabble.com/Support-for-custom-Fragmenter-when-Highlighting-tf1962395.html#a5386994
: : #model things as properties on fields (with f. being the field namespace)
: :
: : f.foo.fragsize=0
: : f.bar.fragsize=1000
: : f.*.fragsize=100 #the default
:
: I like this option the best, though the wildcard specification might
get out of hand.
:
: There could be a top-level namespace:
: hl.fragsize = 100 #default
: And field-level overrides precisely matching the top-level general params:
: f.foo.hl.fragsize = 0
Plugins could then do something like: getFieldProperty("title","hl.formatter")
and get the built-in standard mechanism for checking a hierarchy of
places this property could be defined (handler defaults, handler field
specific config, query defaults, query field specific config).
-Yonik
On 7/21/06, Andrew May (JIRA) <[EMAIL PROTECTED]> wrote:
[ http://issues.apache.org/jira/browse/SOLR-37?page=all ]
Andrew May updated SOLR-37:
---------------------------
Attachment: patch
Changes to CommonParams, SolrPluginUtils, plus new HighlightingUtils
> 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
>
>
> 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
