[ 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.