[
https://issues.apache.org/jira/browse/SOLR-281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yonik Seeley updated SOLR-281:
------------------------------
Attachment: solr-281.patch
Here's a new (smaller) patch that utilizes pluggable query parsers, and
- removes DisMax specific modules since dismax specific logic is limited to
query construction
- DisMax request handler is now just the standard handler with defType=dismax
added as a default
- removed variable RequestBuilder class logic since it seems unnecessary... if
two non-standard components want to communicate something, they can use the
Context or the Response. (any reason I'm missing why it should stay?)
Thoughts on these changes?
We need to think through all the members of ResponseBuilder carefully and
decide what component sets/reads them in what phase (and if that makes the most
sense).
Should ResponseBuilder have methods instead of members? If so, that would
allow a component to perhaps even replace the ResponseBuilder and delegate to
the original.
How will a users custom component get configuration? Should components be a
full plugins with an init() for configuration?
> Search Components (plugins)
> ---------------------------
>
> Key: SOLR-281
> URL: https://issues.apache.org/jira/browse/SOLR-281
> Project: Solr
> Issue Type: New Feature
> Reporter: Ryan McKinley
> Attachments: SOLR-281-SearchComponents.patch,
> SOLR-281-SearchComponents.patch, SOLR-281-SearchComponents.patch,
> SOLR-281-SearchComponents.patch, SOLR-281-SearchComponents.patch,
> SOLR-281-SearchComponents.patch, solr-281.patch, solr-281.patch,
> solr-281.patch
>
>
> A request handler with pluggable search components for things like:
> - standard
> - dismax
> - more-like-this
> - highlighting
> - field collapsing
> For more discussion, see:
> http://www.nabble.com/search-components-%28plugins%29-tf3898040.html#a11050274
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
