[
https://issues.apache.org/jira/browse/SOLR-225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509721
]
Ryan McKinley commented on SOLR-225:
------------------------------------
> perhaps be defined as
>
> protected boolean emptyArray(String[] arr) {
> return (arr == null || arr.length == 0 ||
> (arr.length == 1 && (arr[0] == null ||
> arr[0].trim().length() == 0)));
> }
seems good. This patch tried not to change any highlighting logic, it is just
moved it from the existing HighlightingUtils.java
I will add this change.
>
> + public static final String MAX_CHARS = PREFIX+"maxAnalyzedChars";
>
> similarly. Seems somewhat inelegant to define/hardcode the plugin-specific
> parameters here, though it is nice ot have them all in one place...
>
I'm torn on what is more/less elegant.
Should we have a new class in o.a.s.common.params for each plugin?
Since the number of 'core' plugins will be relatively small, having a single
HighlightParams class with sections for the core plugin options seems ok. But
I can easily be talked out of this...
> Allow pluggable Highlighting classes -- Formatters and Fragmenters
> ------------------------------------------------------------------
>
> Key: SOLR-225
> URL: https://issues.apache.org/jira/browse/SOLR-225
> Project: Solr
> Issue Type: Improvement
> Reporter: Brian Whitman
> Assignee: Ryan McKinley
> Attachments: SOLR-225+260-HighlightPlugins.patch,
> SOLR-225+260-HighlightPlugins.patch, SOLR-225-HighlightingConfig.patch,
> SOLR-225-HighlightingConfig.patch, SOLR-225-HighlightingConfig.patch,
> SOLR-225-HighlightingConfig.patch, SOLR-225-HighlightingConfig.patch
>
>
> Highlighting should support a pluggable architecture similar to what is seen
> with RequestHandlers, Fields, FieldTypes, etc
> '
> For more background:
> http://www.nabble.com/Custom-fragmenter-tf3681588.html#a10289335
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
