[
https://issues.apache.org/jira/browse/SOLR-3232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13227503#comment-13227503
]
Erik Hatcher commented on SOLR-3232:
------------------------------------
Stefan - /browse and search *are* SearchHandler's. Even with SOLR-3161, these
are legitimate request handlers to issue search requests to.
In your page you have this:
{code}
handlers[key]['class'] === 'org.apache.solr.handler.component.SearchHandler'
{code}
That simply isn't sufficient for determining a SearchHandler though.... and
this points out more about why doing this sort of stuff client-side is brittle.
You really need a Java-side "instanceof" check to be sure if a request
handler is *subclassed* from SearchHandler, not just directly but perhaps
indirectly (like StandardRequestHandler).
Again, I'll just toss this out there because I feel strongly about
HTML-inside-JavaScript-strings and everything coming from Ajax calls this way -
the VelocityResponseWriter allows for very simple server-side templating and
internal access to these sorts of things. It'd be easy to generate a drop-down
box (or JavaScript string array, whatever you'd like) using Solr's internal
state and instanceof kinda checks. An example from your patch on this is:
Also, in light of SOLR-3161, it's risky to add checks for acceptable request
handlers anywhere in a secondary manner as the logic may not match. It's
important to ensure that what's presented matches what is truly available, and
this be done using common server-side logic.
> Admin UI: query form should have a menu to pick a request handler
> -----------------------------------------------------------------
>
> Key: SOLR-3232
> URL: https://issues.apache.org/jira/browse/SOLR-3232
> Project: Solr
> Issue Type: Improvement
> Components: web gui
> Reporter: David Smiley
> Assignee: Stefan Matheis (steffkes)
> Fix For: 4.0
>
> Attachments: SOLR-3232.patch
>
>
> The query form in the admin UI could use an improvement regarding how the
> request handler is chosen; presently all there is is a text input for 'qt'.
> The first choice to make in the form above the query should really be the
> request handler since it actually handles the request before any other
> parameters do anything. It'd be great if it was a dynamically driven menu
> defaulting to "/select". Similar to how the DIH page finds DIH request
> handlers, this page could find the request handlers with a class of
> "SearchHandler". Their names would be added to a list, and if the name
> didn't start with a '/' then it would be prefixed with '/select?qt='.
> I did something similar (without the menu) to the old 3x UI in a patch to
> SOLR-3161 which will hopefully get committed.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
