You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-dev@lucene.apache.org by Koji Sekiguchi <ko...@r.email.ne.jp> on 2010/01/01 07:24:08 UTC
highlighting setting in solrconfig.xml
I'd like to start working for SOLR-1268 (Incorporate Lucene's
FastVectorHighlighter). In the issue. I think I extend (modify)
DefaultSolrHighlighter to use FastVectorHighlighter, rather
than creating/introducing another SearchComponent and
request parameters. That is to say, I'd use hl=on and hl.fl=field1,
and if field1 is termVectors=on and termPositions=on and
termOffsets=on, DefaultSolrHighlighter.doHighlighting() switches
to use FVH unless f.field1.hl.useHighlighter parameter set to on.
If this design is ok, I need to introduce new sub tags like
<fragListBuilder/> and <fragmentsBuilder/> in <highlighting/>
in solrconfig.xml. But now I wonder why the highligher settings
are in such very original place rather than <searchComponent/>.
Do we have any reason to keep <highlighting/> tag?
Or can we move it into HighlightComponent?
Koji
--
http://www.rondhuit.com/en/
Re: highlighting setting in solrconfig.xml
Posted by Noble Paul നോബിള് नोब्ळ् <no...@corp.aol.com>.
new issue https://issues.apache.org/jira/browse/SOLR-1696
2010/1/4 noble.paul <no...@corp.aol.com>:
> Koji has a point. the <highlight> syntax has to be deprecated . All the configurations can be but into the HighlightComponent.
>
>
> I shall open an issue.
>
> On Mon, Jan 4, 2010 at 9:44 AM, Chris Hostetter <ho...@fucit.org> wrote:
>>
>> : If this design is ok, I need to introduce new sub tags like
>> : <fragListBuilder/> and <fragmentsBuilder/> in <highlighting/>
>> : in solrconfig.xml. But now I wonder why the highligher settings
>> : are in such very original place rather than <searchComponent/>.
>> :
>> : Do we have any reason to keep <highlighting/> tag?
>> : Or can we move it into HighlightComponent?
>>
>> I'm not all that aware of what all is involved in the existing
>> <highlighting/> config options, but i suspect it was introduced *before*
>> search components, as a way to configure the highlighting utils that were
>> used by multiple request handlers ... moving all of that into init/request
>> params for the HighlightingComponent seems like a good idea to me -- but i
>> wouldn't be suprised if there were some things that make sense to leave as
>> independently initialized objects that are then refrenced by name,
>> similar to the way QParserPlugins are initialized seperately from the
>> QueryComponent and then refered to by name at request time.
>>
>> but as i said: i know very little about highlighting.
>>
>>
>>
>> -Hoss
>>
>>
>
>
>
> --
> -----------------------------------------------------
> Noble Paul | Systems Architect| AOL | http://aol.com
>
>
--
-----------------------------------------------------
Noble Paul | Systems Architect| AOL | http://aol.com
Re: highlighting setting in solrconfig.xml
Posted by Noble Paul നോബിള് नोब्ळ् <no...@corp.aol.com>.
Koji has a point. the <highlight> syntax has to be deprecated . All
the configurations can be but into the HighlightComponent.
I shall open an issue.
On Mon, Jan 4, 2010 at 9:44 AM, Chris Hostetter
<ho...@fucit.org> wrote:
>
> : If this design is ok, I need to introduce new sub tags like
> : <fragListBuilder/> and <fragmentsBuilder/> in <highlighting/>
> : in solrconfig.xml. But now I wonder why the highligher settings
> : are in such very original place rather than <searchComponent/>.
> :
> : Do we have any reason to keep <highlighting/> tag?
> : Or can we move it into HighlightComponent?
>
> I'm not all that aware of what all is involved in the existing
> <highlighting/> config options, but i suspect it was introduced *before*
> search components, as a way to configure the highlighting utils that were
> used by multiple request handlers ... moving all of that into init/request
> params for the HighlightingComponent seems like a good idea to me -- but i
> wouldn't be suprised if there were some things that make sense to leave as
> independently initialized objects that are then refrenced by name,
> similar to the way QParserPlugins are initialized seperately from the
> QueryComponent and then refered to by name at request time.
>
> but as i said: i know very little about highlighting.
>
>
>
> -Hoss
>
>
--
-----------------------------------------------------
Noble Paul | Systems Architect| AOL | http://aol.com
Re: highlighting setting in solrconfig.xml
Posted by Chris Hostetter <ho...@fucit.org>.
: If this design is ok, I need to introduce new sub tags like
: <fragListBuilder/> and <fragmentsBuilder/> in <highlighting/>
: in solrconfig.xml. But now I wonder why the highligher settings
: are in such very original place rather than <searchComponent/>.
:
: Do we have any reason to keep <highlighting/> tag?
: Or can we move it into HighlightComponent?
I'm not all that aware of what all is involved in the existing
<highlighting/> config options, but i suspect it was introduced *before*
search components, as a way to configure the highlighting utils that were
used by multiple request handlers ... moving all of that into init/request
params for the HighlightingComponent seems like a good idea to me -- but i
wouldn't be suprised if there were some things that make sense to leave as
independently initialized objects that are then refrenced by name,
similar to the way QParserPlugins are initialized seperately from the
QueryComponent and then refered to by name at request time.
but as i said: i know very little about highlighting.
-Hoss